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)
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.
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
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.
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.
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.
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.
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;
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.
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'
Ü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.
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. ;-)
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.
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.
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
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()
SQL-Snippet um doppelte Artikelnummern (oxarticles.oxartnum) herauszufinden: SELECT oxartnum, COUNT(*) FROM oxarticles GROUP BY oxartnum HAVING COUNT(*) > 1;
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).
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/ neu erstellt werden.
details/inc/mythemefile.tpl
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.
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
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.
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.
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
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
Noch mehr zum Thema findest du unter OXID Open Source oder unseren OXID Modulen.