Block überschreiben

Deutsches Forum
21

Danke für den Hinweis mit der Datenbank. Wie in Punkt 1 von indianer3c erwähnt, scheint der Block bereits durch ein anderes Modul überschriben zu werden. Und zwar durch oxmodule → d3heidelpay .

Ich habe das bereits in der metadata.php von d3 auskommentiert aber das scheint noch immer hier zu greifen. Wie kann ich das korrigieren?
Ich habe Angst, das d3-Modul zu deaktivieren und wieder zu aktivieren - keine Ahnung was da im Hintergrund passiert. Ich habe bereits etliche Stunden an Zeit wegen dieser Banalität verloren und kann keine neuen Baustellen gebrauchen.
Wie stelle ich das nun richtig, mit allen Abhängigkeiten?

Danke vorab.

22

Naja, den Block von Heidelpay kannst in der DB-Tabelle testweise manuell deaktivieren (Views !!!). Oder such mal nach position in metadata. Damit kannst die Ladereihenfolge festlegen.

23

Ja, seit der 6.2 Serie haben Module 4 statt 2 Zustände. Jeder neuer Template Block muss entsprechend bekannt gemacht werden.

Jetzt ist es Falsch.

Richtig sollte sein:

'blocks' => array(
        array(
            'template' => 'email/html/order_cust.tpl',
            'block'    => 'email_html_order_cust_paymentinfo',
            'file'     => 'views/blocks/email_html_order_cust_paymentinfo.tpl'
        ),
),

Dafür gibt es noch die Position Einstellung:

'blocks' => array(
        array(
            'template' => 'email/html/order_cust.tpl',
            'block'    => 'email_html_order_cust_paymentinfo',
            'file'     => 'views/blocks/email_html_order_cust_paymentinfo.tpl',
            'position' => '0',
        ),
),

Genauso wie Deinen Block aus Deinem Modul bekannt machst darüber, dass die Moduländerung über Composer in der 1.yaml Datei bekannt machst und Deine Änderung in die Datenbank wandert Module installation and activation — OXID eShop developer documentation 6.2.0 documentation

Allerdings würde ich es vermeiden in Fremdmodulen Dinge zu ändern. Thema Gewährleistung und Updatefähigkeit. Dies wird ab der 7er Serie zum Glück bald nicht mehr so einfach gehen, weil dann auch die Module ins vendor Verzeichnis wechseln sollen.

Dies nicht gut. Dies liegt aber am Setup für den Entwicklungsprozess. In einem guten Entwicklungsprozess hat man keine Angst Dinge zu ändern. Da man Anpassungen Sorgenfrei in seiner Testumgebung testen kann. Das Theme DevOps gewinnt dort immer mehr an Bedeutung und verhindert genau dies, dass man keine Angst mehr haben muss.

Das hängt von Deinen Anforderungen ab. Wenn das Heidelpay Modul auch zum Einsatz kommt und die Blocküberladung also greift und dort keine Position in der metadata.php vermerkt ist, dann wird automatisch die Position = 1 gesetzt in der Datenbank. Jetzt müsstest gucken was, der Heidelpay Block macht und wie Dein Block mit dem Heidelpay Block kombinierst in Deinem Modul oder ob Du den Inhalt komplett tauschst, indem den Parent Verweis bewusst raus lässt.

1 Like
24

Wow!!! Vielen vielen Dank, für deine ausführlichen Erläuterungen.

Mein Fehler, das Array in der ersten Dimeinsion zu befüllen war die Ursache:

Ich finde es toll, dass jeder Fehler immer seine logische Ursache hat… nur bis man den erst einmal findet, könnte man manchmal verzweifeln.

Wo kann ich das nachlesen? Ich habe das Gefühl, vollkommen abgehängt zu sein und bei der Entwicklung nicht mehr hinterher zu kommen.
Ich denke, dass daher auch meine Angst kommt, Änderungen an Dingen vorzunehmen, die bereits funktionieren. Denn wenn etwas plötzlich nicht mehr funktioniert, bin ich hier in OXID total Kopflos und muss mühevoll den Fehler suchen, ohne die vielen Abläufe und Abhängigkeiten des OXID im Hintergund zu kennen. Das Grundhandwerkszeug, logisches Denken usw. habe ich aber wie bereits gesagt - bei OXID habe ich manchmal Berührungsängste weil ich viel im Hintergund nicht kenne.
Es gibt auch Tutorials und Beispiele im Netz und auf den OXID-Seiten, nur sind viele von denen auch schon veraltet. - Wo kann ich mich generell noch einmal in diea aktuelle Terminilogie und Modulentwicklung von OXID einlesen?

Das mit der Auskommentierung im D3-Modul war eine Verzweiflungstat bei der Fehlersuche.
Die möglichen Folgen sind mir klar. Ich habe auch die Anlassung zuerst untersucht - diesen Block aus dem D3-Modul brauche ich hier nicht weil der Kunde die Geldeingänge bei Vorkasse selbst managen will, deshalb kommt dieser Block auch nicht zum Tragen.

1 Like
25

Gerne dafür ein Forum da.

Im April 2020 habe ich an einen kostenlosen Webinar der OXID eSales teilgenommen mit dem Titel “Bessere Modulentwicklung: OXID eShop 6.2 Update für Entwickler”. Ggfs. für Newsletter bei OXID eSales registrieren, als Entwickler ggfs. auch für OXID Savvy Programm registrieren und/oder gucken ob es neue Webinare gibt unter Webinare zu aktuellen Themen im E-Commerce - OXID Academy • OXID eSales AG

Die Aufzeichnung leider nicht mehr Online.

Update: Ansonsten erste Anlaufstelle immer die Entwickler Dokumentation für die Serie 6.2 unter Module — OXID eShop developer documentation 6.2.0 documentation dort wird bisschen erläutern was sich in Modulentwicklung getan hat. Zusätzlich das mit 4 Zuständen in oben bereits verlinkten Dokumentationseintrag bildlich dargestellt unter Module installation and activation — OXID eShop developer documentation 6.2.0 documentation

4 Zustände (genau genommen 5 Zustände wenn Modul noch nicht bekannt ist)

  • Modul nicht bekannt, wird nicht im Admin angezeigt (nicht bekannt)
  • Modul bekannt machen, damit es im Admin erscheint (Installation)
  • Modul konfigurieren, damit Modulüberladungen und Einstellungen etc. in Datenbank bekannt gemacht werden (Konfiguration)
  • Modul aktivieren (Aktivierung)
  • Modul deaktivieren (Deaktivierung)

Ergänzend ist eine Auffrischung über Udemy Videos für Basis Modulentwicklung sicherlich wieder guter Einstieg um up-to-date zu bleiben die findest unter https://www.udemy.com/course/oxid-eshop-entwicklerschulung-basis/