OXID Dev-Tipps

Die OXID Dev-Tipps sind eine Sammlung nützlicher Tipps & Tricks aus dem ProudCommerce OXID Entwickler-Team.

Durch Änderungen in der OXID Packageverwaltung (Satis) kann es zu folgenedem Fehler beim install/update kommen.

Failed to download oxid-esales/oxideshop-pe from dist: The checksum verification of the file failed

Die sichere Lösung ist die Checksum in der aktuellen composer.lock neu zu erzeugen.

composer update oxid-esales/oxideshop-pe oxid-esales/oxideshop-demodata-pe ddoe/visualcms-module oxid-esales/oxideshop-metapackage-pe --no-dev -n --ignore-platform-reqs --no-install

(Quelle: OXID Dev-Slack – danke Noel)

Downloadprobleme Composer OXID PE/EE06.03.23

Je nach Datenbank-Einstellungen kann es passieren, dass früher oder später im OXID Shop Probleme auftreten, wann immer auf die „oxorder“-Tabelle zugegriffen wird, z.B. beim Laden der Bezahlarten im Checkout oder auch in der Kontoübersicht der Bestellungen. Wir hatten neulich bei einem Kunden mit gut 300.000 Bestellungen im Shop den Fall, dass es plötzlich zu merklichen Verzögerungen im Checkout und im Kundenkonto kam.

Die Ursache war mit Tideways schnell zu finden und zum Glück war auch das Problem relativ leicht zu beheben.  Ein problematisches SQL war z.B. diese einfache Abfrage im Checkout:

select oxorder.oxpaymenttype from oxorder where oxorder.oxshopid = ‚1‘ and oxorder.oxuserid = ?  order by oxorder.oxorderdate desc

Hier fehlte dem Shop einfach nur ein Index auf die OXUSERID, um die Relation performant aufzulösen. Sobald dieser hinzugefügt wurde, gingen die Abfragezeiten von teilweise 8 Sekunden und mehr wieder unter 1 Sekunde zurück:

ALTER TABLE `oxorder` ADD INDEX(`OXUSERID`);
ALTER TABLE `oxorder` ADD INDEX(`OXORDERNR`);

Auch ein Index auf OXORDERNR schadet hier sicher nichts, daher haben wir diesen ebenso ergänzt.

Langsamer OXID Checkout bei vielen Bestellungen05.05.22

Leider ist OXID 6 inkl. der aktuellsten Version 6.4 nicht mehr kompatibel mit Composer >= 2.3. Hier gibt es konkret eine Inkompatibilität bzgl. verwendeter Symfony-Versionen, die zu folgendem Fehler führen wenn man ein Composer-Kommando in OXID ausführen will:

Call to undefined method Symfony\Component\Console\Question\Question::getAutocompleterCallback()

Um das Problem zu umgehen, muss man auf der letzten 2.2 Version von Composer bleiben. Ein Downgrade ist z.B. wie folgt möglich:

composer self-update 2.2.10

OXID Composer 2.3+ Symfony Fehler19.04.2022

Ab OXID 6.2 werden für Moduleinstellungen zusätzlich YAML-Files genutzt und diese mit den Moduleinstellungen in der Datenbank synchronisiert. Soweit nichts neues. ;-) Jedoch bleibt der Inhalt von aModuleVersions davon unberührt, auch bei einem apply-config. Dies führt dazu, dass in aModuleVersions und aModules verschiedene Modulstände vorhanden sind. Erst nach dem „Säubern“ der Moduleinträge wird auch aModuleVersions entsprechend aktualisiert. Die Werte aus aModuleVersions werden z. B. in oxViewConfig verwendet, um zu prüfen ob ein Modul aktiv ist oder nicht.

Problem bei Shop-Migration und aModuleVersions21.03.22

Abhängig von der MySQL-Konfiguration kann es beim Hinzufügen einer weiteren Spalte zu folgender Fehlermeldung führen: Row size too large. The maximum row size for the used table type, not counting BLOBs, is 8126. This includes storage overhead, check the manual. You have to change some columns to TEXT or BLOBs Am einfachsten lässt sich dieses Problem mit dem Ändern des row_format auf dynamic beheben.

Fehler beim Hinzufügen eines Datenbankfeldes22.07.21

Im OXID Core 6.5.0 (OXID Metapackage 6.2.0) wurden das Rendern von eMail-Nachrichten (Smarty) geändert. Als deprecated waren die Methoden bereits seit einiger Zeit markiert. ;-) Ersetzt wurden diese durch das TemplateRendererBridgeInterface. Je nach Inhalt der eMail konnten die Nachrichten jedoch verschickt werden. Daher ist es in unserem Fall auch erst später aufgefallen, was genau das Problem ist.

Smarty Rendering in eMails06.07.21

Standardmäßig ist es nicht möglich Admin-Templates anzupassen bzw. zu individualisieren. Dies wird jedoch manchmal benötigt, wenn keine Blöcke an den gewünschten Stellen vorhanden sind.

Rückblick: Es war April 2018, da hatten wir einen Bugeintrag gemacht. ;-) Bis heute ist dieser leider noch nicht behoben, jedoch hat Benjamin nun dazu einen Blogpost mit Workaround (composer patch) veröffentlicht.

Admin-Templates anpassen26.01.20

Ist das Shop-System noch nicht mindestens auf OXID 6.2.0 kann es bei einer Kombination aus MariaDB >= 10.2.* und älteren Doctrine-Version (2.5.*) zum Problem kommen dass alle Spalten welche mit einem Default-Wert “ definiert sind, nun ein doppeltes Anführungszeichen enthalten (Bugeintrag).

Dies führt vor allem bei oxorder und oxarticles zu Problemen. Beheben kann man dies indem man den entsprechenden Patch direkt per composer einbindet. Wie das geht ist im Blogpost Applying patches to OXID eShop projects with composer (en) beschrieben.

Alternativ kann man auch den entsprechenden Default-Wert ändern, z. B.: ALTER TABLE oxorder MODIFY OXBILLCITY INT NULL; ALTER TABLE oxorder ALTER OXBILLCITY DROP DEFAULT;

Doppelte Anführungszeichen anstatt Leerwert25.05.21

Fügt man der Tabelle „oxcategories“ zusätzliche Felder hinzu und will diese im Frontend ausgeben, benötigt man ein kleines Modul dafür. Man muss für das Model „lazy loading“ aktivieren und auch dem Cache-System das neue Feld bekanntmachen (sonst funktioniert der Zugriff auf das Feld nur einmalig nach dem Cache-Leeren). Dazu überschreibt man den Konstruktur des Category-Models per Modul:

class Category extends Category_parent
{
public function __construct()
{
$this->_blUseLazyLoading = true;
// for caching, add this
$this->_aFieldNames['pc_cat_not_clickable'] = 0;
parent::__construct();
}
}

Näheres dazu z.B. auch im OXID Forum.

Eigene Kategorie-Felder verwenden und ausgeben22.03.21

Standardmäßig wird im OXID Metapackage der Summernote WYSIWYG Editor ausgeliefert. Leider ist es mit diesem nicht (zuverlässig) möglich script und style Tags zu bearbeiten. Stattdessen nutzen wir in einigen Projekten den „alten“ TinyMCE Editor. In den Moduleinstellungen müssen folgende TinyMCE-Plugins aktiviert werden.

extended_valid_elements => 'script[src|async|defer|type|charset],style'
custom_elements => 'style'

OXID WYSIWYG Editoren05.02.21

Übersetzungen werden in mehreren Sprachdateien gespeichert. Diese können entweder unter source/Application/views/MY_THEME/de/NAME_lang.php , oder innerhalb eines Moduls, abgelegt werden. Beim Zusammenführen aller Sprachdateien wir die cust_lang.php (gleiches Verzeichnis) zum Schluss geladen. Somit ist es auch möglich Sprachvariablen aus Modulen zu überschreiben.

Reihenfolge Sprachdateien14.12.20

Vor Kurzem hatte uns folgende Fehlermeldung etwas beschäftigt: [uncaught error] [type E_ERROR] [file /home/html/vendor/oxid-esales/oxideshop-ce/source/Core/DatabaseProvider.php] [line 200] [code ] [message Class 'Doctrine\DBAL\Connection' not found] Der Grund hierfür: CLI hat mal wieder eine andere PHP-Version verwendet als der Webserver. ;-)

Fehler DoctrineDBALConnection not found24.11.20

Durch eine Dateninkonsistenz kann es beim Aktivieren eines beliebigen Moduls (in OXID 6) zu folgendem Fehler führen: Smarty plugin directory does not exist /Core/Smarty/Plugin/ Grund hierfür ist eine falsche Konfiguration des Eintrags moduleSmartyPluginDirectories in der Datenbank (oxconfig-Tabelle). Um das Problem zu lösen muss der entsprechende Datensatz sowie Inhalt des tmp-Verzeichnis gelöscht werden. Alternativ kann auch der Eintrag in der Datenbank bearbeitet und das Smarty-Verzeichnis entfernt werden.

Smarty-Fehlermeldung bei Modulaktivierung06.11.20

Informationen zu installierten Modulen werden derzeit noch in der Datenbank (oxconfig [aModules, aModuleEvents, aModuleFiles, aDisabledModules, aModuleVersions, aModuleTemplates]) gespeichert. Diese sind jedoch verschlüsselt abgelegt, sodass man sie weder einsehen noch ändern kann. Unser kleines oxConfig Modulsettings-Script (Github) macht dies aber möglich. ;-) Hinweis: Mit OXID 6.2 wurde die primäre Datenhaltung von Modulsettings in yaml-Files ausgelagert, zusätzlich zur Datenbank. Ab OXID 7 werden vermutlich nur noch die Konfigurationsdateien benötigt.

oxConfig Modulsettings bearbeiten20.10.20

Mit OXID 6 wurde das Feld oxuser.oxusername durch einen Primary Key ergänzt. Somit ist es nicht mehr möglich mehrere eMail-Adressen, bei gleicher Shop-ID, in die Tabelle oxuser einzutragen. Dies führt immer wieder zu folgendem Fehler: OXID Logger.ERROR: Duplicate entry '[email protected]' for key 'OXEMAIL' ["[object] (OxidEsales\\Eshop\\Core\\Exception\\DatabaseErrorException(code: 1062): Duplicate entry

Duplicate entry in oxuser Tabelle29.09.20

Regelmäßig gibt es das Problem im Forum, oder aktuell im OXID Dev-Slack, dass keine Versandarten im Checkout angezeigt werden. Meistens liegt es an einer fehlerhaften Versandarten-Konfiguration. ;-) Nachfolgend drei Tipps hierfür: 1.) Debuglevel (5) in der config.inc.php einschalten, 2.) Prüfen ob Fallback-Zahlart oxempty aktiv ist und 3). Debuggen in basket::_calcDeliveryCost()

Versandarten werden nicht angezeigt22.09.20

SQL-Snippet um doppelte Artikelnummern (oxarticles.oxartnum) herauszufinden: SELECT oxartnum, COUNT(*) FROM oxarticles GROUP BY oxartnum HAVING COUNT(*) > 1;

Doppelte Artikelnummern finden11.09.20

Bereits zweimal ist es vorgekommen dass nach dem Ausführen aller Migrationsskripte von OXID 4/5 auf OXID 6 trotzdem in der Tabelle oxuser noch die alte Shop-ID (oxbaseshop) vorhanden war. Dies führt dann natürlich dazu dass bereits registrierte Benutzer nicht mehr gefunden werden. Daher auf jeden Fall nochmal manuell prüfen ob (alle) Shop-IDs entsprechend aktualisiert wurden (oxbaseshop -> 1).

Alte Shop-ID nach Relaunch auf OXID 625.08.20

Sofern in einem Template keine Blöcke vorhanden sind bleibt bei Shop- als auch Modultemplates oft nichts anderes übrig als das entsprechende Template zu überschreiben. Dazu muss eine gleichnamige Template-Datei (inkl. Pfad) im aktuellen Shop-Theme erstellt werden. Beispiel: Das Modultemplate mit dem Key page/details/inc/mythemefile.tpl muss unter application/views/mytheme/tpl/page/
details/inc/mythemefile.tpl
neu erstellt werden.

OXID Modul-Template überschreiben18.08.20

Vielleicht hatte der ein oder andere auch schon das Problem dass nach dem Aktivieren eines Moduls die Modul-Settings aus der Tabelle oxconfig verschwunden sind. Nutzt man in einem OXID-Modul die Standardmöglichkeit um Modul-Einstellungen zu speichern (saveShopConfVar() und getShopConfVar()) müssen die Variablen auch in der metadata.php im Abschnitt settings definiert sein. Ist dies nicht  der Fall werden beim erneuten Aktivieren alle Einstellungen gelöscht.

OXID Modul-Settings verschwunden24.07.20

Standardmäßig ist die Sessionzeit im OXID Admin sehr kurz gehalten (ca. eine Stunde). Anschließend muss man sich erneut anmelden. Um dies, ohne PHP-Änderungen, zu umgehen kann man einfach den Block admin_header_links mit einem kleinen Javascript erweitern. Solange der Browser-Tab geöffnet ist wird der Header im Admin-Frame regelmäßig neu geladen und somit bleibt man im Shop-Admin eingeloggt. Danke an Marat für den Hinweis.
https://gist.github.com/proudcommerce/d9ac559ff1282b200cd2b2c79741413c

OXID Admin-Logout verhindern20.07.20

Im OXID Admin hat man die Möglichkeit die Reihenfolge, der durch Module erweiterten Klassen, festzulegen. Normalerweise muss hier keine Änderung vorgenommen werden. Jedoch kann es, z. B. beim Überschreiben von kompletten Methoden, zwingend notwendig sein. In OXID 6.2 ist dies aufgrund eines Javascript-Fehlers aktuell nicht möglich. Der Bug wurde bereits gemeldet, eine Lösung steht aktuell auf Github zur Verfügung und wird im nächsten OXID eShop Release behoben.

OXID 6.2 Bug Modulsortierung17.06.20

eMails im OXID eShop werden normalerweise per SMTP (phpMailer) versendet. Jedoch gibt es aktuell einen Bug der ein & im Passwort zu einem & konvertiert. Ein Pull Request haben wir bei OXID heute eingereicht.

OXID SMTP Passwort Encoding Problem09.06.20

Durch Verkettung ungünstiger Umstände ;-) kann es zu folgendem Fehler (Fatal Error) kommen Circular reference detected for service "Psr\Log\LoggerInterface", path: "Psr\Log\LoggerInterface -> Psr\Log\LoggerInterface" und der ist der Shop nicht mehr aufrufbar. Mit einem kleinen Workaround, danke an Alfred, kann das Problem behoben werden.
https://gist.github.com/proudcommerce/602ab33c23a1546588266812ed72ac30

OXID 6.2 Circular Reference Exception27.05.20

Auf Github sammeln wir bereits seit einigen Jahren hilfreiche Code- und MySQL-Snippets (gists), vor allem im Bereich OXID eShop. NEU DABEI: OXID Hersteller (oxmanufacturer) und Lieferanten (oxvendor) tauschen.
https://gist.github.com/proudcommerce

ProudCommerce OXID Gists24.01.20

Noch mehr zum Thema findest du unter OXID Open Source oder unseren OXID Modulen.