Dass sich mit dem Release des OXID eShop 4.7/5.0 auch ein Großteil der Verzeichnisstruktur geändert hat, dürfte mittlerweile ja bekannt sein.

Anfangs war es gar nicht möglich eigene Sprachdateien unterhalb von /modules/ zu nutzen. Dies wurde vor längerer Zeit schon geändert, sodass man diese unter

/modules/mymodule/out/admin/de/mymodule_lang.php

ablegen konnte. Dies war identisch zur Oxid-Standard-Struktur (out/admin/de). In OXID 4.7/5.0 liegen die template-spezifischen Sprachdateien nun in folgenden Verzeichnissen: Weiterlesen »

Da die SEO-Funktionalität in OXID nicht unbedingt selbsterklärend ist, hier ein kurzer technischer Einblick in die Erzeugung und “Archivierung” von SEO-URLs am Beispiel von Kategorie-URLs im Shop

OXID SEO-URLs werden in der Tabelle “oxseo” gespeichert. Kategorie-URLs werden aus dem Titel (OXTITLE) der Kategorie generiert, wobei Umlaute und Sonderzeichen natürlich ersetzt bzw. entfernt werden (Details dazu hier). Blättert man in Kategorien, werden für jede Seite eigene Einträge in “oxseo” geschrieben.

Die jeweilige Seitenzahl wird hier im Feld “OXPARAMS” gespeichert. Wird der Titel einer Kategorie geändert, muss natürlich sinnvollerweise auch die SEO-URL dieser Kategorie geändert werden (plus die URLs aller Unterkategorien sowie die URLs der Artikel in diesen Kategorien – siehe oxcategory::_update() sowie oxseoencodercategory::markRelatedAsExpired()). Weiterlesen »

Immer mehr Provider gehen dazu über, aus Sicherheitsgründen auf den Webservern den sog. suhosin-Patch für PHP zu installieren. An sich eine nette Sache, nur hat dieser manchmal unerwünschte und meist erst einmal auch undurchschaubare Nebenwirkungen – Module funktionieren plötzlich nicht mehr, Uploads klappen nicht o.ä., ohne dass es einen sichtbaren Fehler oder Hinweis geben würde.

Der Grund dafür sind meist die zum Teil sehr restriktiven Einstellungen, die der Patch mit sich bringt, u.a. werden die Länge von GET- oder POST-Parametern beschränkt usw. Uns erreichen dann immer wieder Support-Anfragen, dass nach einem Server-Wechsel/-Update plötzlich Modul XY nicht mehr funktionieren würde. Hier hilft dann ein Blick in das System-Log des Servers, auf das man hoffentlich Zugriff hat – normalerweise schreibt der Patch Log-Einträge in die Datei “/var/log/syslog“, dort stehen dann Einträge wie z.B.

… suhosin[14020]: ALERT – configured POST variable limit exceeded – dropped variable ‘sExportMinStock’ …

Abhilfe schafft man, indem man entweder in die php.ini oder in eine eigene suhosin.ini Datei (am besten mit phpinfo() ausgeben lassen, welche Konfigurationsdateien für PHP/suhosin verwendet werden bzw. im OXID-Shop-Admin unter “Service / Systeminfo” nachsehen) die gewünschten Werte einträgt, z.B. für die Limits der GET-/POST-/REQUEST-Variablen:

suhosin.get.max_value_length = 4096

suhosin.post.max_array_index_length = 1000
suhosin.post.max_name_length = 1000
suhosin.post.max_totalname_length = 1000
suhosin.post.max_value_length = 900000
suhosin.post.max_vars = 10000
suhosin.request.max_array_depth = 1000
suhosin.request.max_array_index_length = 1000
suhosin.request.max_totalname_length = 1000
suhosin.request.max_value_length = 900000
suhosin.request.max_vars = 9000

Danach den Webserver neu starten und das betroffene Modul sollte wieder funktionieren … wenn nicht, noch einmal einen Blick in die Log-Datei riskieren