Planet OXID

marmalade.de: Reaktivieren der Lieferantenliste (oxvendor) in OXID eShop

Fri, 11 May 2012 12:09:13 +0000

Für ein aktuelles Projekt (aktuelle Version der OXID 4.5-Branch) wird die Lieferantenliste im Frontend benötigt. Diese wurde aus Performancegründen vom OXID Team per default deaktiviert, die Vendor-Funktionen sind jedoch noch vorhanden, da nur die Config-Variable entfernt wurde. Durch ein einfaches Modul für die oxcmp_categories-Klasse lässt sich die Funktionalität der Lieferantenliste und der zugehörigen Funktionen schnell wieder herstellen.

<?php
class marm_oxcmp_categories extends marm_oxcmp_categories_parent{
public function init()
{
$myConfig = $this->getConfig();
$myConfig->setConfigParam( ‘bl_perfLoadVendorTree’, 1 );
parent::init();
}
}

Anschließend können auf die Funktionen wieder im Template zurückgeriffen werden um die Lieferantenliste wieder anzuzeigen. Man kann sich dazu an der Herstellerliste orientieren.

e-Commerce Developer Blog: WBL Konzept ist nun OXID Certified Solution Partner

Thu, 10 May 2012 16:29:36 +0000

Mal wieder eine erfreuliche Meldung in eigener Sache.

Vielleicht hat es einen von Euch über meine Vorstellung zu meinem XING-Profil geführt und dort ein paar Qualifikationen gesehen, ansonsten ist mein Arbeitgeber die WBL Konzept nun auch OXID Certified Solution Partner.

Wir freuen uns auf eine erfolgreiche Partnerschaft!

: WBL Konzept ist ab heute OXID Certified Solution Partner

e-Commerce Developer Blog: Datenbank-Master/Slave Vorbereitung in OXID 4.6.0

Thu, 10 May 2012 06:38:28 +0000

Lastverteilung ist bei großen Internetseiten ein sensitives Thema. Bei gut besuchten Shops natürlich sowieso, denn jeder von uns möchte in Geschäften an der Kasse nicht lange anstehen und sofort bedient werden. Aktuell ist für viele Shops eine Hochlastzeit, denn Muttertag steht vor der Tür und Muttertagsgrüße möchten verschickt und Geschenke verteilt werden.

Bei typischen Webanwendungen gibt es mehrere Möglichkeiten und Schichten der Lastverteilung. Eine Schicht ist auf der Datenbankseite einer Webanwendung zu finden. Und mit OXID 4.6.0 hat sich hier anscheinend einiges getan.

Lastverteilung der Datenbankanfragen im OXID Core

OXID unterstützt im Shop-Core bisher noch keine Lastverteilung für Datenbankanfragen. Hier hat man vollkommen legitim die Entscheidung getroffen, dass der Shop gar nicht im Detail wissen kann, wie die Serverlandschaft des Betreibers aussieht. Man überlässt die Lastverteilung ähnlich zu anderen Web-Anwendungen dann konsequenterweise auch direkt dem Betreiber des Shops, aber dazu unten mehr.
Auf dem wunderbaren eCommerce-Breakfast in Düsseldorf am Montag habe ich dann aber mit einem TOP OXID-Hoster über dieses Thema gesprochen, und erfahren, diese Einstellung hätte sich mit der OXID 4.6.0 geändert. Wir wollen jetzt einmal schauen, wie weit OXID da jetzt ist.

MySQLi Treiber im OXID-Core

Also was auf jeden Fall feststeht, OXID 4.6.0 bringt nun einen Datenbanktreiber für MySQLi, dem “verbesserten” MySQL-Treiber von PHP, mit.

Und jetzt zu zwei Nachrichten, und ganz klassisch kommt die schlechte zu erst:

Leider ist für mich im Core noch keine direkte Lastverteilung für Datenbank-Abfragen zu erkennen. Wie bisher muss man sich auf andere Techniken verlassen, die außerhalb des OXID-Systems liegen. Welche Techniken das sind, habe ich weiter unten etwas näher erklärt.

ABER, es ist ein großes Update am Datenbank-Adapter “oxDB” erkennbar und bisher “schwer” erreichbare Strukturen sind zugänglicher gemacht worden. Hier fallen mir besonders zwei Dinge auf:

1. Die Datenbank-Module, wie z.B. das Datenbank-Admin-Log, werden jetzt nicht mehr hart gekoppelt im “Fließtext” einer Methode delegiert, sondern über eine gekapselte Methode oxDb::__getModules() angewiesen. Jetzt wird es deutlich einfacher – ohne größere Codeblöcke zu kopieren – eigene Datenbank-Erweiterung zu implementieren.

2. Das Laden der Datenbankverbindung selbst, wurde jetzt auch tiefer in eine Methode gekapselt.
[crayon-4fb1806d8d939/]
Und der Parameter der Methode lässt hoffen, dass wir bald ein OXID-Release erhalten werden, in dem der OXID-Core seine Queries selbst auf verschiedene Server verteilen kann ohne auf weitere Software setzen zu müssen. Und für Jemanden, der bis dahin nicht warten möchte: Findige Partner, wie wir bei der WBL Konzept, könnten aber auch jetzt schon bei diesem Thema weiterhelfen ;)

Master/Slave Replikation

Aber nun einmal zur genauen Technik, wie es nun meistens gemacht wird und was dann möglich wäre. Hier möchte ich nur auf MySQL eingehen, da dies das Standard-System von OXID darstellt. Die am häufigsten zu findende Verteilungsart im MySQL-Umfeld wird eine Master/Slave – Replikation sein.

Bei einer Webanwendung kann davon ausgegangen werden, dass es viel mehr lesende als schreibende Datenbankabfragen gibt. Die “wenigen” schreibenden Zugriffe verursachen also im Prinzip nicht die Last, sondern die abertausenden lesenden Zugriffe, die sich zur Abarbeitung in die Warteschlange einreihen, und diese vielleicht “verstopfen”. Daher versucht man, die lesenden Zugriffe auf sogenannte Slaves zu verteilen, die nichts anderes tun, als lesende Zugriffe abzuarbeiten.

Ein Master-Server wird dann aber weiterhin genutzt um Daten in die Datenbank zu schreiben. Damit seine Sklaven wissen, welche Daten auszuliefern sind, schreibt der Master seine “Daten” in eine Logdatei, über die sich die Slaves dann in definierten Intervallen aktualisieren, die sogenannte Replikation. Vereinfacht gesagt, wird der Performancevorteil dadurch erzeugt, dass die Datenbankabfragen von mehreren Server abgearbeitet werden können und die Replikation meist nicht sofort, sondern etwas zeitversetzt und dann gesammelt passiert.

OXID muss wie oben beschrieben für solche Dinge bisher auf andere Software setzen.

Ein MySQL-Cluster, der transparent als ein Server auftritt und die Abfragen intern verteilt.
Ein Proxy-Script, welches sich quasi zwischen Shop und Datenbank-Server schaltet um gemäß Abfrage-Format unterschiedliche Server anzuwählen.
Oder ein Shop-Modul.
In “großer” Ausfertigung, müsste der gesamte Shop erweitert werden um jede Datenbank-Operation so zu manipulieren, dass Ihr von Außen zugewiesen wird, welche Datenbank-Server sie zur Auswahl hat.
Oder man kann das Datenbankmodul mit vermutlich weniger Aufwand so gestalten, dass es intern wie das Proxy-Script aus Punkt zwei arbeitet, bloß direkt aus dem Shop heraus.

Punkt zwei (und drei) könnten mit PHP 5.3 mittlerweile vom MySQL-Treiber (MySQLnd) selbst erledigt werden.

Ich bevorzuge eine Datenbankschicht, bei der man für jeden Query zumindestens sagen kann, ob es ein Query ist, der unbedingt an den Master geschickt werden muss, oder ob er auch von Slaves bedient werden kann. Dies wäre die große Ausfertigung von Punkt drei. So ist schon von der Applikation her klar, wie die Abfragen grob aufgeteilt werden und reduziert den Aufwand von anderer ergänzender Software neben dem Shop. Genau dieses Vorgehen scheint jetzt auch bei OXID Einzug zu halten.

Happy Hacking!

Björn

top concepts: Kleines Howto: Aus einer OXID CE eine OXID PE machen

Mon, 07 May 2012 13:29:05 +0000

In letzter Zeit haben wir aus immer mehr OXID Community Editions unserer Kunden nachträglich eine Professional Edition gemacht, um somit von der kostenlosen Open Source Version zur kommerziellen Lizenz zu wechseln. Natürlich wäre es mühsam, jetzt jedes mal den kompletten Shop neu zu installieren, daher haben wir hier eine kurze Übersicht erstellt, wie man aus einer OXID CE nachträglich eine OXID PE machen kann. Beide Versionen sind ja zu über 90 % deckungsgleich, daher ist das gar nicht so schwierig.

alle PHP Dateien der CE-Version durch die PHP dateien der PE-Version ersetzen (diese sind im Gegensatz zur Open Source Version verschlüsselt)
In der Datenbank Tabelle oxshops den Inhalt des Feldes OXEDITION von ‘CE’ auf ‘PE’ setzen
Ein zusätzliches Feld OXSERIAL in der Datenbank Tabelle oxshops ergänzen.
Im OXID Shop-Admin unter Service -> Tools die “VIEWS jetzt updaten”
Den gültigen Lizenz-Key von der OXID eSales AG im Shop-Admin eintragen und speichern
Die CSS Datei /out/admin/src/colors.css der OXID CE durch die entsprechende Datei aus dem OXID PE Installations-Paket ersetzen.

Hier noch die SQL-Befehle, die Sie durchführen müssen, um den Wert für OXEDITION (siehe 2.) zu ändern bzw. um das Feld OXSERIAL (siehe 3.) hinzuzufügen:

UPDATE `oxshops` SET `OXEDITION`='PE' WHERE `OXEDITION`='CE';

ALTER TABLE `oxshops` ADD `OXSERIAL` VARCHAR( 255 ) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL AFTER `OXSMTPPWD` ;

Bitte führen Sie vorher in jedem Fall wie bei allen größeren Umstellungen unbedingt ein Backup Ihrer Datenbank und Ihres Shop-Verzeichnisses durch.

Unterstützung und Support rund um Ihren OXID eShop erhalten Sie auch bei top concepts, E-Commerce Beratungshaus und OXID Certified Premium Solution Partner aus Hamburg.

e-Commerce Developer Blog: WBL Autoloader und OXID 4.6.0

Sun, 06 May 2012 08:36:31 +0000

Falsche Modulansicht

Vor OXID 4.6.0 musste man sich seine Modulketten im Backend selbst zusammenstellen. Nun hilft einem das Backend dabei. Unser Autoloader durchkreuzte da ein bisschen die Pläne seitens OXID. Er funktionierte weiterhin wunderbar, aber die Aussage im Backend waren für den Benutzer nicht einleuchtend.

Module werden unter unserem Kürzel in der Liste gruppiert.
Warnmeldung im unteren Frame zur Deaktivierung.

Diese “Probleme” haben wir nun behoben:

Wir haben die metadata.php für den WBL_Modules -Ordner angelegt.
Das Modul WBL_Modules_ModuleList sorgt dafür, dass der Autoloader in der Liste als aktiv angezeigt wird und die “Entfernen”-Warnmeldung im unteren Frame nicht mehr erscheint. (Leider auf den ersten Blick n kleineren OXID-Bug gefunden.)
Und die vendormetadata.php im WBL-Ordner sorgt dafür, dass der WBL-Ordner nicht mehr als direkter Modulordner verstanden wird. OXID schachtelt jetzt noch eine Ebene tiefer und versteht den WBL-Ordner nur noch als Hersteller-Ordner. Dies muss für alle “Hersteller”-Ordner gemacht werden, wobei die vendormetadata.php dabei noch leer sein darf.
Unittests sind auch aktualisiert worden. Unser Modul für die oxModuleList schließt natürlich auch mit 100% Codeabdeckung ab.

Korrekte Moduldarstellung nach 4.6.0 Update

>> Unseren Autoloader downloaden

e-Commerce Developer Blog: Datenbankverbindung beim Unittesting reloaded

Sun, 06 May 2012 07:57:33 +0000

Ich musste in meinem Posting Datenbankprobleme beim OXID-Unit-Testing ja bereits von kleinen Komplikationen mit meiner Testumgebung berichten. Bei OXID 4.6.0 ist es nach Tagen ohne Probleme hier plötzlich auch aufgetreten. Irgendwo verschluckt sich meine VMWare.

Mein alter oxDB::getDb() – Fix ist bei OXID 4.6.0 tot und führt zu einer Endlosschleife, daher sieht meine Empfehlung für OXID 4.6.0 diesmal so aus:
[crayon-4fb1806d99129/]
Bestr Grüße
Björn

top concepts: top concepts auf der „OXID Commons 2012“

Fri, 04 May 2012 14:44:10 +0000

OXID eSales lädt am Donnerstag, den 24. Mai 2012 ein weiteres Mal zu der Fachmesse für E-Commerce-Lösungen „OXID Commons“ nach Freiburg im Breisgau ein. Mit der „OXID Commons“ findet somit wieder ein E-Commerce Event der ganz besonderen Art statt. Bereits zum vierten Mal heißt OXID eSales alle Shopbetreiber, Partner, Entwickler, E-Commerce Experten und Interessenten auf der Messe Freiburg willkommen. Bei der Veranstaltung rund um das Thema E-Commerce erwarten die Besucher an zwei Tagen spannende Vorträge und Diskussionen zu den Trends im E-Commerce, Mobile Commerce, Multi-Touchpoint-Strategien, Best Practise Cases oder Entwicklungs-Know-How.

Auch Henrik Steffen von top concepts wird auf der diesjährigen „OXID Commons“ dabei sein. Er hat ein Vortragsthema eingereicht über das neue OXID Modul „CleverReach“, welches von uns entwickelt wurde. Ob der Vortrag den Weg in die Agenda geschafft hat, erfahren Sie in Kürze.

Seien Sie außerdem gespannt auf die diesjährige Preisverleihung für den OXID Best Solution Award. top concepts hat mehrere Kandidaten ins Rennen geschickt, um diese Auszeichnung für seine Kunden zu sichern.

Nähere Infos zu dem Programm und zu den Referenten finden Sie hier:
http://www.oxid-esales.com/de/news/oxid-commons/oxid-commons-2012.html

Melden Sie sich gerne unter diesem Link für die OXID Commons an:
http://www.oxid-esales.com/de/news/oxid-commons/anmeldung.html

top concepts: Neues OXID Modul von top concepts verfügbar

Fri, 04 May 2012 14:43:39 +0000

CleverReach E-Mail Marketing Connector: Mehr Umsatz durch den Einsatz von E-Mail Marketing!
top concepts hat ein weiteres OXID Modul programmiert, welches ab sofort im OXID eXchange Store verfügbar ist.

Mit dem neuen Modul „CleverReach E-Mail Marketing Connector“ lassen sich Kunden- und Bestelldaten vom OXID eShop schnell und einfach zu CleverReach übertragen, damit Sie zielgruppenspezifisches E-Mail Marketing betreiben können. Streuverluste werden somit drastisch reduziert. CleverReach bietet Ihnen eine leistungsstarke E-Mail Marketing-Software, mit der Sie professionelle E-Mails online erstellen, sicher versenden, Erfolge messen und Empfänger verwalten können. Die durch das Modul übertragenen Daten ermöglichen zielgruppengenaue Ansprachen Ihrer Kunden.

Erzeugen Sie durch regelmäßige E-Mail Kampagnen zusätzliche Bestellungen
Starten Sie zielgerichtete E-Mail Marketing Kampagnen
Informieren Sie Ihre Zielgruppen in kürzester Zeit per Klick über Neuigkeiten & Angebote
Umfangreiche Analysen zeigen den Erfolg in Echtzeit
Sprechen Sie Ihre Empfänger persönlich an, um mehr Aufmerksamkeit & Akzeptanz zu finden

Das CleverReach Modul finden Sie im eXchange Bereich unter:
http://exchange.oxid-esales.com/startseite/

Voraussetzung ist ein Kundenkonto bei CleverReach:
Anmeldung unter: http://bit.ly/GVOBVk

top concepts: Relaunch des Gatapex Online-Shops veröffentlicht

Fri, 04 May 2012 14:43:03 +0000

Mithilfe der OXID eShop Professional Edition 4.5.8 und entsprechender Individualprogrammierung in unserem Hause wurden diese Anforderungen von Gatapex erfolgreich umgesetzt:

Optimierung der Suchfunktion
Höhere Leistungsfähigkeit und Geschwindigkeit
Verbesserung der Filterfunktionen
Mehr Auswahl an Produktvarianten
Farbenfrohes Design
Übersichtliches, strukturiertes Layout
Kurze Bestellprozesse
uvm.

Gatapex bietet den Kunden einen Online-Shop für Kinesio-Tapes, Sport- und Gesundheitsbandagen sowie Akupunkturpflaster und Zubehör für Sportmedizin bzw. Physiotherapie. Für nahezu jede Sportart finden Sie dort die richtige Auswahl an Funktionsbandagen und Material. Übersichtlich und sauber strukturiert wird den Shop-Besuchern bei der Suche nach den passenden Artikeln geholfen.

Unter www.gatapex.de können Sie das breite Spektrum an Bandagen, Tapes und Zubehör durchstöbern.

top concepts: top concepts entwickelt App für Zajadacz

Fri, 04 May 2012 14:42:25 +0000

„EVI“ To Go – App für iPhone & Android im Elektro-Großhandel

Nach dem erfolgreichen Roll-Out des Zajadacz Onlineshops haben wir für unseren Kunden eine App programmiert, mit der nun einfach, schnell und bequem Ware aus dem Onlineshop bestellt werden kann. Die App lößt bereits sowohl bei iPhone- als auch bei Android-Nutzern große Begeisterung aus. Lesen Sie hier unsere Case Study zur Zajadacz App!

Mehr erfahren:
Case Study download

Weitere Infos und App-Download auf:
www.zajadacz.de

e-Commerce Developer Blog: Facebook Shop Modul

Fri, 04 May 2012 11:10:43 +0000

Ich habe es in der Vorstellung angedroht, ab und zu kommt auch ein bißchen Werbung. Ich habe euch das Autoloader 4.6.0 Posting versprochen. Ja, der Autoloader wird gerade mit “oxModule” verknüpft und zwar im 4.6.0 Update unseres Facebook-Shop-Moduls, daher braucht das Posting noch ein bißchen.

WBL Facebook Shop: OXID eShop Modul

Unser WBL Facebook Shop Modul ermöglicht euch die Implementierung eures Shops im Facebook-Kontext ohne weitere Schnittstelle. Das gleiche Backend, der gleiche Artikelbestand, die gleichen User-Daten und mit OXID 4.6.0 funktioniert hoffentlich der Facebook Connect auch wieder besser.

php rookie: OXID eShop CE 4.6.0

Mon, 30 Apr 2012 16:48:39 +0000

In OXID eShop from a different point of view I described how to run OXID eShop Community Edition without database views. The obstacles of a cheap webpack Time for an update, as OXID Community Edition 4.6.0 is out now. Info … Continue reading →

e-Commerce Developer Blog: Unser OXID Autoloader

Mon, 30 Apr 2012 09:54:58 +0000

Jeder von uns Programmierern ist eigentlich bestrebt, wenig zu wiederholen und viel wiederzuverwenden. Wir überlegen uns meistens möglichst schöne Klassenstrukturen in denen wir unsere Logiken so kapseln, dass wir sie hoffentlich wiederverwenden können. In letzter Zeit springe ich zwischen einigen OXID Todos und stehe gefühlt jedes Mal vor dem Schritt bestehende Strukturen zu kombinieren oder Strukturen auf der grünen Wiese neu zu pflanzen. Und jedes Mal ist der OXID-Autoloader auch wieder ein Thema.

In “älteren” Strukturen, musste man sich meist “selbst” darum kümmern wie Strukturen geladen werden und hat dementsprechend die Quellcodes händisch nach bestem Wissen und Gewissen mit Includes versehen. Die Ausgabe 3.2012 des PHP-Magazins hat dafür z.B. Phing genannt, wobei manche Dinge trotz Deklaration noch händisch inkludiert werden müssen.

Zitat der Phing-Doku:

Always include/require all the classes needed for this task in full written notation. Furthermore you should always include phing/Task.php at the very top of your include block. Then include all other required system or proprietary classes.

Diese händischen Includes sind aber alles harte Aufrufe und schränken die Wiederverwendbarkeit etwas ein indem sie wahrscheinlich saubere Quellcodes “verschmutzen”. Und jedes Mal macht man sich Gedanken um die Verfügbarkeit von Logiken. Steigt man in ein Projekt neu ein, erhöht dies auch die Lernkurve denn man weiß nicht auf Anhieb ob und wo man mal eben eine Klassenkonstante aufrufen kann.

Die PHP-Community hat dies erkannt und steuert mit einem Autoloader seit PHP5 nach. Zusätzlich dazu kann mit der SPL der PHP-Autoloader nützlich erweitert werden, indem der einzelne Standard-Autoloader __autoload() durch einen ganzen Stapel von Autoloadern erweitert werden kann. Ein Autoloader wird beim Aufrufen von bisher nicht inkludierten Klassen und Interfaces automatisch mit dem entsprechenden voll qualifizierten Interface- oder Klassennamen aufgerufen und erlaubt dem Entwickler so, fehlende Logiken erst on Demand nachzuladen.

Ein weiterer Vorteil eines Autoloaders ist meiner Meinung nach auch, dass autoloadbare Strukturen meistens selbsterklärender sind.

Autoloadbare Strukturen zeigen sich heutzutage eigentlich in allen großen Frameworks. Im Zend Framework werden zum Beispiel alle Klassen und Interfaces mit dem Präfix Zend als oberster Namespace eingeleitet. Der Klassennamen wird dann automatisch in den Ordnernnamen umgemünzt, indem man vom Zend-Ordner ausgehend alle Namespace-Trenner nutzt um damit Ordner und Dateien zu identifizieren.

Oft wird ein Software-Core wie der des Zend Frameworks in großen Projekten nicht direkt genutzt sondern an bestimmten Stellen erweitert.

Um dann Namenskonflikte zwischen Originallogik und Erweiterung zu vermeiden, hat es sich als Best Practice erwiesen, die Erweiterungen in einen eigenen Namespace, bzw. Ordner im Autoloader-Kontext, zu kapseln.

Magento als Kind vom Zend Framework kann hierfür als Beispiel dienen.

[crayon-4fb1806d9dac9/]
Im Core des OXID Shopsystems sind solche Strukturen vorhanden. Geht es dann aber an die tiefe Modulentwicklung, fehlt es an manchen Details.

Mittlerweile denkt man bei OXID an Version 4.6, wenn nicht sogar Version 5, aber die grobe Ordnerstruktur für Logiken hat sich API-safe schon länger nicht mehr verändert. Seit mindestens Version 2 von OXID lässt sich fast jede Core-Klasse über “oxNew” und entsprechenden Strukturen im “modules” Ordner erweitern (Mehr dazu bei OXID selbst). ”oxNew” sorgt für eine lose Kopplung des eigentlichen “new” Aufrufs und erlaubt über das Backend für fast jede Core-Klassen eine Vererbungshierachie zu bestimmen. Genau diese Struktur kann heutzutage von einem Autoloader beeinflusst werden.

Die entsprechende Moduleinstellung wird seit Jahren von OXID so ausgewertet, dass der entsprechende Entrag im “modules”-Ordner gesucht wird. Im Backend kann für jede Datei ein Pfad und ein Klassenname eingetragen werden. Der Klassenname sollte aber gemäß Core-Logik auch dem Dateinamen entsprechen. Mit OXID 4 ist zwar ein Autoloader eingeführt worden, ist aber vom jeweiligen Integrationspartner noch nicht wirklich direkt beeinflussbar gewesen, denn es wurde ausschließlich der Standard-Autoloader deklariert.

Man musste also seit Jahren Redundanzen in saubere Kapselungen einführen.
Zum Einen hat man zur sauberen Kapselungen selbstverständlich die Dateien in Ordner gepackt. Man hatte aber – und musste natürlich sogar - auch die Klassen so zu benennen, dass sie einzigartig waren.

[crayon-4fb1806d9db56/]

Hier tritt bereits die erste Redundanz auf, muss dann diese Redundanz aber auch noch zusätzlich im Backend von OXID spiegeln.

Zitat von OXID:

There we enter in the modules form field „oxarticle => ourmodule/extendedarticlerating“ and save that entry. Now the module is registered and loaded.

Mit OXID 4.3.0 hat man sich hier deutlich geöffnet und den erweiterbaren SPL Stack eingeführt. Ab jetzt war es über die functions.php möglich einfach eigene Autoloader einzuführen und so die oben beschriebene Redundanz aufzulösen.

[crayon-4fb1806d9dbb7/]

Folgenden Autoloader, den ich immer für meine Freizeit-Projekte und nun für meine Firma WBL-Konzept verwende, möchte ich euch unter der MIT Lizenz öffentlich freigeben.

[crayon-4fb1806d9dc01/]
Alternativ könnt Ihr ihn mit Unittests auch hier runterladen.

Unser Autoloader sucht ausgehend von “modules” Ordner im Zend Framework Stil die Interface- und Klassendateien, indem er den PHP-Namespace-Trenner “\” oder den Unterstrich “_” nutzt um eine Ordnerhierarchie aufzubauen.

[crayon-4fb1806d9dc66/]

Damit dieser Modulautoloader die OXID-Core-Logik nicht beeinflusst und wir somit möglichst Upate-Safe weil API-sicher bleiben, versucht er Klassen nur zu laden, wenn ihm mitgeteilt wird, für welche Namespaces er gilt.

Der Autoloader geht von einer Standarddateiendung “.php” aus. Jedoch hat mein Agenturalltag gezeigt, dass trotz harmonisierter Strukturen eigene, spezielle Stilmittel beibehalten werden. So findet man zum Beispiel Ordnerstrukturen, bei denen Klassendateien mit “.class.php” oder Interfaces mit “iface.php” enden. Um dies abzudecken erlaubt der Setter, dass der Autoloader auch andere Dateiendungen beachten kann.

[crayon-4fb1806d9dcb5/]

Hierbei ist zu beachten, dass die Endungen die im Array vorne stehen, auch als erstes bearbeitet werden, denn die Iteration über die Dateiendungen erfolgt mit einer foreach-Schleife. Intern hätte man dies mit einem glob-Aufruf vielleicht eleganter lösen können, aber meine Benchmarks haben gezeigt, dass dies keinen Unterschied macht.

Eigene Klassen außerhalb der Modulchain

Geht es an eigene Klassen die mit “oxNew” geladen werden sollen, scheitert dieser Autoloader. “oxNew” wandelt mit strtolower die Klassennamen intern zu Kleinbuchstaben um und deaktiviert somit das direkte Mapping von Klassennamen zu Dateinamen. Jeder folgende Autoloader-Aufruf erhält dann nur noch kleingeschriebene Klassennamen.
[crayon-4fb1806d9dd00/]
Unser Autoloader versucht dies auszugleichen, indem er “wblNew” bietet. Ein einfacher Wrapper für “oxNew”.
[crayon-4fb1806d9dd48/]

“aModuleFiles” bei OXID 4.6.0

Mit OXID 4.6.0 ist ein weiterer Hook in den Autoloader eingebunden worden. Deklariert man in seiner metadata.php eines Moduls ein “files”-Array, werden diese Dateien vom Autoloader beachtet.
[crayon-4fb1806d9dd92/]

Ich möchte diese Technik nicht einsetzen, da sie meiner Ansicht nach eine weitere Redundanz darstellt, aber eines meiner nächsten Postings wird sicher sein, wie sich dieser OXID-Autoloader im OXID 4.6.0 Kontext verhält. Ich empfehle in der neuen Moduleinstellung jetzt einmal auf ”nein” zu klicken ;). Dazu aber später mehr.

Ausblick auf nächstes Posting(oxblocks, OXID 4.6.0)

Bis OXID 4.6.0 gab es eigentlich nur eine weitere Logik die wirklich abhängig von dem Modulordner war. Und das ist das Feature der “oxblocks”. Über die Datenbanktabelle “oxtplblocks” konnten Templates überlagert werden, indem man einen Speicherort und ein Modul eines anderen Templates angegeben hat. Die einfachste Möglichkeit war dann, den entsprechenden Modulordner als Ganzes anzugeben. Nun hat sich das Verhalten in Abhängigkeit zur neuen OXID-Modulverwaltung aber etwas geändert. Dazu wie gesagt aber ein anderes Mal mehr.

UPDATE 06.05.12

Unser Autoloader nach dem Upate auf OXID 4.6.0

D3 OXIDmodule Blog: OXID Version 4.6.0 (Revision 44406) ist da.

nospam@example.com (Daniel Seifert) — Thu, 26 Apr 2012 15:00:00 +0000

OXID veröffentlicht die nächste Shopversion: 4.6.0.

Die Liste der Änderungen steht hier zur Verfügung. Zu beachten sind jedoch auch die Änderungsprotokolle zu den vorangegangenen Beta- und RC-Versionen auf dieser Seite.

Die CE-Version kann hier bezogen werden. Alle Kunden mit PE- oder EE-Version erhalten von OXID separat eine Mail.

Beachten Sie bitte auch unbedingt unsere Hinweise zur Verwendung des Modul-Connectors mit der neuen Shopversion.

D3 OXIDmodule Blog: OXID Version 4.5.10 (Revision 44222) ist da.

nospam@example.com (Daniela Biewald) — Tue, 24 Apr 2012 11:20:42 +0000

OXID veröffentlicht die nächste Shopversion: 4.5.10.

Die Liste der Änderungen steht hier zur Verfügung.

Die CE-Version kann hier bezogen werden. Alle Kunden mit PE- oder EE-Version erhalten von OXID separat eine Mail.

php rookie: Book: Online Shops with OXID eShop

Sat, 21 Apr 2012 18:23:42 +0000

Finally decided to get my hands on one ‘the book’ about OXID eShop. According to the description, this book is meant for newbies wanting to have a first look into what you can do with OXID eShop. And as I’ve … Continue reading →

marmalade.de: .gitignore für die Entwicklung mit OXID

Fri, 20 Apr 2012 10:24:03 +0000

Wir versionieren unsere Projekte mit Git. Komplett! Und auch die OXID Forge ist zu GitHub gewechselt. Freut uns sehr. Und weil wir uns so freuen, ein kleiner Helfer für alle Einsteiger.

Wenn man entwickelt, macht man das meist in einem kompletten Shop, vermutlich auf dem lokalen Server – man will ja gleich alles sehen und testen. Im Git Repository möchte man jedoch nur die Dateien haben, welche wirklich auch zum Modul oder Projekt gehören und nicht unbedingt den OXID Standard Shop oder das tmp-Verzeichnis.

Hierzu kann man einfach eine .gitignore-Datei einrichten, welche diese Dateien ausblendet. So tauchen die beim adden und comitten nicht mehr auf.

Sieht bei uns dann so aus:

/admin/*
!/admin/marm*
/core/*
!/core/marm*
/export/*
/log/*
/modules/*
!/modules/marm*
/out/admin/*
/out/azure/*
/out/basic/*
/out/de/*
/out/en/*
/out/media/*
/out/pictures/*
/tmp/*
/views/*
!/views/marm*
/.htaccess
/COPYING
/config.inc.php
/favicon.ico
/index.php
/offline.html
/oxid.php
/oxseo.php
/pkg.rev
/robots.txt
/xd_receiver.htm
.tmp*
/.project
/.settings/org.eclipse.core.resources.prefs
*.*~

Erik Kort: OXID eShop: Update Cycles and Maintenance Releases

Wed, 18 Apr 2012 14:47:32 +0000

In a couple of weeks we will release OXID eShop version 4.6.0. Thanks to our proven Open Source development and beta testing process this release will be in time and built to highest quality standards.

However, starting with the release of version 4.6.0 we will introduce some slight changes in the update cycles. This will make the update process easier and clearer for everybody. We will also expand our maintenance activities for previous versions of OXID eShop.

Terminology

There will be three different kinds of releases:

Major releases: Upgrades OXID eShop to a new version number, e.g. 4.0 or 5.0
Minor releases: Updates the current major release, e.g. 4.6 or 5.1
Patch: Indicates the stage of development for current minor release, e.g. 4.6.1 or 4.5.8

Maintenance

As with previous version of OXID eShop you will continue to get a monthly patch that fixes known bugs for the current minor release. Extending our maintenance activities, from now on we will also supply patches for the previous version (X.X-1). But patches for previous versions will be released only when needed and not a regular basis. They will not contain any new or additional features.

As usual, you will have two possibilities to update: You can either download the full release or you can generate a cumulative package here. Just pick your current version and you will get one package that will automatically do a complete update to the newest version of OXID eShop for you.

Keep your system up to date

Every release will be compatible with PHP 5.2 and PHP 5.3.

For optimal functionality of OXID eShop and its extensions we recommend regular updates and always using the latest versions. We also recommend working with a test and staging system at all times.

e-Commerce Developer Blog: Datenbankprobleme beim OXID-Unit-Testing

Tue, 17 Apr 2012 14:28:20 +0000

Mensch, eine Stunde verbraucht mit der Fehlersuche.

Ich stolpere grad über Datenbank-Probleme beim Unit-Testing einer aktuellen OXID-Version und bin auch mit einer ausgiebigen Google-Recherche und dem Wühlen in der OXID-Mailingliste nicht fündig geworden. Da die Testumgebung von OXID zur Modulzertifizierung leicht veraltet ist, teste ich meine Module gegen ein halbwegs aktuelles Debian 6 mit PHP 5.3 auf dem neuesten VMWare Player und irgendwann, wirklich irgendwann im Testlauf, ist plötzlich in der Connection-ID des Datenbankobjekts keine Resource mehr zu finden, sondern nur noch ein Integer-Wert. Ab dem Moment als das Problem auftrat, trat es ab da immer an der gleichen Stelle auf. Cacheleeren, Views neu generieren, neues Deployment … nichts hat geholfen. Ich hab in meinen Modulen gewühlt, aber einfach kein Grund für das Problem gefunden.
[crayon-4fb1806dc753f/]
Im Core gibt es auch nicht wirklich eine Stelle, die die Connection-ID überschreibt also wird es vermutlich irgendein Seiteneffekt mit dem Setup sein, welches PHPUnit forciert.

Also flott mal einen Core-Unit-Test von OXID ausgeführt und siehe da, auch hier tritt der Fehler auf. Damit kann ich meine Logik ausschließen und schiebe es auf andere Ursachen.

Wer rein zufällig auch auf dieses Problem stolpert und kein Interesse hat den vermutlichen Seiteneffekt im Core zu fixen, hier ein schneller Workaround:
[crayon-4fb1806dc75a4/]
Dieser Fix führt dazu, dass jedes Mal eine neue Verbindung aufgebaut wird, wenn die Verbindung über die ConnectionID nicht mehr identifiziert werden kann. Der Fix ist natürlich nur für Entwicklungssysteme gedacht!

Happing Coding!

Björn

web-haeppchen.de: Neueste Artikel im OXID Shop präsentieren (frisch eingetroffen)

Fri, 13 Apr 2012 11:50:55 +0000

OXID bringt von Hause aus verschiedene Marketing-Funktionalitäten mit, die Sie bei der Präsentation Ihrer Produkte unterstützen. Eine davon ist “Frisch eingetroffen”, die Liste neuester Artikel, die Sie nach der Installation auf der Startseite des Online-Shops finden.

Sie haben zwei Möglichkeiten, neue Artikel auf der Startseite aufzulisten: Sie lassen von OXID automatisch die neuesten Artikel ermitteln, oder Sie stellen die Liste von Hand zusammen.

Sie finden die entsprechende Einstellung unter Stammdaten → Grundeinstellungen auf dem Tab “Perform.”.

Setzen Sie dort “Liste der neusten Artikel (Frisch eingetroffen!)” auf “automatisch“, wenn Oxid die neuesten Artikel für Sie ermitteln soll, auf “manuell“, wenn Sie sie selbst auswählen wollen (mehr dazu weiter unten).

Automatisch – Oxid findet neueste Artikel selbst

Haben Sie “automatisch” ausgewählt, sucht Oxid die jeweils neuesten Produkte selbständig und sortiert sie auch – die allerneuesten der neuen Produkte stehen immer ganz oben.

Dabei gibt es noch eine Unterscheidung: Entweder erkennt Oxid nur ganz neue Produkte als neu, oder es werden auch geänderte Produkte in dieser Liste angezeigt. Die zugehörige Option ist etwas versteckt, unter Stammdaten → Grundeinstellungen, Tab “Einstell.”. Öffnen Sie die Gruppe “Artikel“, dort finden Sie die Checkbox “Neueste Artikel nach dem Erstellungsdatum berechnen. (Ansonsten nach Datum der letzten Änderung)“, die eigentlich selbsterklärend ist, man muss nur wissen, wo man sie findet.

Hier stellen Sie übrigens auch (etwas weiter oben) ein, wieviele Artikel in dieser Rubrik angezeigt werden sollen: “Anzahl der Artikel, die bei “Frisch eingetroffen!” (neuste Artikel) angezeigt werden“.

Manuell – selbst bestimmen, was auf der Startseite steht

Wenn Sie lieber selbst bestimmen möchten, welche Produkte auf der Startseite Ihres Shops präsentiert werden, stellen Sie die oben genannte Option auf “manuell“.

Das ist übrigens auch die Voreinstellung.

Sie können nun unter Kundeninformation → Aktionen verwalten den Eintrag “Frisch eingetroffen” editieren.

Klicken Sie auf „Artikel zuordnen“ und ziehen Sie die gewünschten Artikel von links in die Liste rechts.

Achtung! Die Artikel werden nun nicht mehr nach Erstellungsdatum sortiert, sondern in der Reihenfolge, in der Sie sie in die rechte Liste ziehen. Zuerst der Liste hinzugefügte Produkte werden auch in der Liste zuerst dargestellt. Daher kann es nötig sein, bei jeder Aktualisierung die Liste komplett zu löschen und die Artikel dann erneut in der gewünschten neuen Reihenfolge der Liste hinzuzufügen.

Die manuelle Liste können Sie auch schnell mal eben ausblenden oder wieder einblenden, indem Sie “Frisch eingetroffen” in den Aktionen aktivieren oder deaktivieren. So haben Sie die volle Kontrolle und können die Liste auch für andere Verkaufs-Aktionen verwenden (Die Überschrift “Frisch eingetroffen” sollten Sie dann natürlich ändern. Das erfolgt in der jeweiligen lang.php Ihres Themes).

Performance

Wenn Sie die Liste „Neueste Artikel“ nicht nutzen, sollten Sie sie aus Performance-Gründen ganz deaktivieren. Stellen Sie unter Stammdaten → Grundeinstellungen, Tab „Perform.“ die Option “Frisch eingetroffen” aus.