Der Beitrag, geschriebem am 26. November 2017, ist schon etwas älter und könnte womöglich nicht mehr aktuell sein
In einem Fall bei dem der Divi-Page-Builder dazu verleitet hatte, den redaktionellen Aufwand zu unterschätzen, wollte ich einer Design-Kundin ersparen, Änderungen an einem Projekt an x anderen Stellen nachziehen zu müssen. Ich hatte dafür die Idee, ein benutzerdefiniertes Divi-Modul einzusetzen, das Daten aus Projekten anhand der ID übernahm. Als Ergebnis bekam ich auch recht schnell ein Modul das ich dann zwar auswählen konnte, doch meine Felder waren nirgendwo zu finden.
1. Local Storage löschen
Den Browsercache zu leeren brachte gar nichts. Untersuchungen mit Browsertools zeigten unter anderem, dass Divi massenhaft Cookies hinterlegt. Doch nicht nur das, es zeigt sich auch, dass Divi die JavaScript Local Storage API nutzt, die man ebenfalls löschen muss, wenn man wirklich eine aktuelle Version seines Moduls sehen will. Den Storage zu löschen brachte die richtigen Felder an die erwartete Position.
Frontend zeig Inhalt, Modul verschwindet aus dem Editor
Anschließend speicherte ich meine Auswahl im benutzerdefinierten Modul, sah mir die Seite an, und fand vor was ich erhoffte. Doch aus dem Divi-Editor war mein Modul verschwunden.
2. Slug mit et_pb_ präfixen
Die Änderung in der function init() von $this->slug = 'my_custom_module'; auf $this->slug = 'et_pb_my_custom_module'; (entsprechend auch Änderung des registrierten Shortcodes) löste das Problem.
Es stellte sich heraus, dass im Divi-Builder Shortcode-Slugs tatsächlich an mehreren Stellen mit nach et_pg untersucht werden (und bei Fehlen desselben übergangen). Der Artikel Building your own Divi Builder Modules weist ebenfalls auf das Erfordernis hin.
Nachtrag: Divi kommt in keinem Projekt mehr vor, mit dem ich zu tun habe, und ich werde mich damit auch nicht mehr weiter rumquälen ;).
Schreibe einen Kommentar