Im Zuge des 4.3 er Updates habe ich heute mal alle unsere veröffentlichten Module angefasst und geprüft ob sie auch mit der aktuellen eShop Version laufen. Dabei ist mir aufgefallen das ich auch gleich einen kleine Überblick geben könnte welche Erweiterungen der Musterdenker zur Zeit im eXchange zu finden sind. In eckiger Klammer noch eine kurze Notiz ob und was geändert werden musste um die Erweiterung 4.3 kompatibel zu machen:

1. Delete_tmp (Open Source) [kein Änderung für 4.3 notwendig]
   Diese winzige Modul mach das Entwickeln mit dem eShop ein bisschen einfacher. Das Problem das nach Änderungen an der Datenbank, der Übersetzungsdateien oder anderer Elemente die gecached werden der “tmp” Ordner geleert werden muss kostet viel zu oft Nerven. Dieses Modul übernimmt das für uns, bei jedem Request auf den Shop wird der gesamte cache geleert. Aber bloß nicht vergessen das Modul vorm Going-Live zu entfernen.
2. Mude_Avatar (Open Source) [kein Änderung für 4.3 notwendig - jedoch habe ich die Tempaltes auf den neusten Stand gebracht]
   Erweitert das Nutzerkonto um die Möglichkeit ein Avatarbild hoch zu laden oder sein Gravatar Icon zu hinterlegen. Dieses Avatarbild wird dann neben den Kommentaren des Benutzers angezeigt. Sieht nett aus und gibt den Benutzerbewertung noch mehr Glaubwürdigkeit.
3. Prepayment Reminder (Open Source) [Admin Templates mussten angepasst werden]
   Dieses Admin Modul hilft dem Shopbetreiber einen schnellen Überblick über offene Vorkassebestellungen zu erhalten. In der neuen Liste im Admin werden alle offenen Vorkassebestellungen angezeigt und gleichzeitig besteht die Möglichkeit den einzelen Kunden direkt eine Mail zu schicken um sie ans Bezahlen zu erinnern.
4. TinyMCE für Admin (Open Source) [keine Änderungen notwendig, jedoch habe ich die neuste TinyMCE Version (3.3.2) eingebaut ]
   Die OXID Community Edition (CE) kommt ja ohne einen WYSIWYG Editor. Wer den Tiny MCE Editor nutznen möchte für Artikellangtext, Kategoriebeschreibung, CSM, etc. sollte dieses Modul installieren.
5. Preorder / Reorder (90,00€) [Admin Templates mussten angepasst werden - neuste Version kommt in wenigen Tagen]
   Wenn ein Artikel ausverkauft ist kann er nicht bestellt werden und es gehen Umsätze verloren. Auch braucht der Shopbetreiber eine Möglichkeit Informationen zu sammeln um zu entscheiden ob es sich noch lohnt ein bereits ausverkauftes Produkt nach zu bestellen. Beide Probleme löst dieses Extension. Der Shopbetreiber kann einzelne Produkte nachbestellbar machen wodurch der Kunde bei einem ausverkauften Artikel angeben können ob und wieviel dieses Artikels er vorbestellen möchte. Diese Information wird im Shopbackend zusammengefasst und aus dieser Liste herraus können die Kunden auch per Mail informiert werden sobald die Artikel wieder auf Lager sind.
6. Saferpay eCommerce (290,00€) [keine Änderungen notwendig - neuste Version kommt in wenigen Tagen]
   Mit diesem Modul bindet man das Saferpay eCommerce Packet an seinen OXID eShop an. Die Zahlung wird entweder direkt auf der Seite von Saferpay vorgenommen wohin der Kunde im Schritt 3 geleitet wird oder in einem iFrame ohne das der Kunde den Shop verlassen muss. Abgebucht wird der Betrag natürlich erst nach einer erfolgten Bestellung.
7. Mude Translate (Open Source) [funktioniert noch nicht mit Version 4.3. aufgrund dieses Bugs]
   Der jüngste Nachwuchs unter den Musterdenker OXID Modulen wurde bereits hier auführlich beschrieben. Kurz zusammengefasst ermöglicht diese Erweiterung eine Editieren aller Sprachkonstanten innerhalb des Shop Frontends. Egal ob neue Sprache oder nur Anpassung des Wordings, werden dabei alle Änderungen in eine *.po Datei geschrieben. Diese Modul ermöglicht also auch die Verwendung von *.po Dateien. Dieser Standart kann genutzt werden um mit externen Übersetzungsagenturen Dateien aus zu tauschen.

Das Update der Module auf 4.3 wurde nur durch 2 Dinge getrübt. Zum einen die notwendigen Änderungen in den Admintemplates :

in the new eShop version 4.3.0, the internal links in admin tool are changed from [{$shop->selflink}]?[{ $editurl }] to [{$shop->selflink}]&[{ $editurl }]. This allows to add parameters to the selflink not only in templates, but also in the admin php classes. Also, this may affect some modules, which uses admin interface templates with custom [{$shop->selflink}]?[{ $editurl }] urls for e.g. frameset definitions. The ‘?‘ character in these urls should be replaced by the ‘&‘.

Sowie durch den Bug beim Erweitern der Klasse “oxlang” welches auch andere Module betreffen dürfte.

Today is the release of a new open source module for OXID eShop. The module enables inline translation of all text not stored in the database. Creating a new language is very easy. The translator can simple click through the shop and translate the text directly in the context. Another good use for this module in real projects is the fixation of the wording. Because it’s always the same. In the final phase of a project there are a lot requests like “I want this button labled ‘basket’ and not ’shopping cart’ …”. With this inline editor the shop owner can make this changes himself. Another nice point about this module is that it comes along with gettext support. So it uses *.po files to store all translations. This po files are much better to handle that the default lang.php arrays, especially when you work together with external translators.

Download it here(mude_translate_V_0_6) or go to the OXID eXchange.

A few screenshots:

The original descriptions as written in exchange:

With this extension an small icon is displayed next to each translated string directly in the shop frontend. Clicking on this icons opens a window where you can enter the new translation for this language constant. That’s it! In order to work this module includes gettext support for the shop. So if you want to use *.po files you can also use this module. Inline editing is only visible for shop admin. Please leave a comment or make improvements to the code. After all it’s open source

Together with the last year release of the OXID eShop open source (GPL V3) version, the OXID eXchange open its doors to the public. The OXID eXchange is similar to the Apple App Store or the Magento connect a central place where developers can put their applications or in terms of OXID eShop extensions (modules, language packs and themes) in order to distribute and sell them. In the eXchange we find a description by the creator of the extension as well as reviews written by customers. But as most of the reviews are more like comments and tend to be quite short it may be hard to determine the quality of the extensions. That’s why we’ll start a series of objective reviews in order to help people in the jungle of OXID extensions. For the start we’ll mainly cover open source extensions but we plan to cover paid extensions as well.

Number one in our series will be the “fck editor” (link to eXchange) extension by top concepts a german OXID partner located in Hambug.

All testing take place with the newest version of the OXID eShop CE (4.2) in UTF-8 mode, installed on my local Mac OSX 10.5.7 with an old PHP 5.2.5.

Description:
This extension adds the open source fck editor, which is today known as the CKEditor, as default WYSIWYG editor in the eShop. Remark: The OXID eShop CE ships without an WYSIWYG editor so you’ll need to install this or the TinyMCE editor in order to use full WYSIWYG features.

Documentation:
There is a small install.txt file in english and german. All you need to know about installing can be found there, but don’t expect any additional information. A new user might have a problem with the term “add the following lines to the ‘Modules’ section”. It would be better to describe where to find the text box in admin area (Master Settings -> Core Settings -> System -> Modules), especially as WYSIWYG usually is the first think installed when someone tries the eShop for the first time.

Installation:
Following the instructions it takes me 20 seconds and FCK Editor is installed an working. No problems at all.

Good:

• Easy and fast installation and applies to all OXID eShop text boxes that are capable of html text.
• The FCK Editor is a very good editor including adding / uploading of pictures.

Bad:

• The FCK Editor interface switches language according to the text language and not based on the admin interface language. So if an english admin edits the german translation of an article the FCK editor’s interface is in german too.
• Maximizing the editor can’t be used as the OXID “save” button disappears, although this is mostly a problem of the admin templates.

Conclusion:
Use it! You might also think about replacing the build in editor of PE and EE versions by the FCK editor if you like it more.

Please feel free to comment or recomment other extensions…

Nach dem positiven Feedback auf meinen ersten Artikel über CMS Erweiterungen für den OXID eShop, möchte ich den Artikel nun vervollständigen. Erfreulicherweise gibt es nämlich noch mehr

OXID2CON
Das Offenbacher Unternehmen four for business wird in naher Zukunft eine Schnittstelle (OXID2CON) veröffentlichen zwischen dem OXID eShop und dem CMS Contentido. Letzteres war mir bisher leider unbekannt. Ich habe es aber etwas unter die Lupe genommen und bin positiv überrascht. Contentido ist ein kleines aber feines CMS veröffentlicht unter der GPL Lizenz mit sehr einfach zu erweiterten HTML Templates. Die aktuelle Versionsnummer 4.8 , ein aktives Communityforum und sehr viele Referenzen im Web lassen auf ein ausgereiftes und vielgenutztes CMS schließen. Schlimm genug das ich es bisher nicht kannte … In einem zukünftigen Projekt werde ich es mal ausprobieren und mir dann noch ein genaueres Bild machen.
Aber zurück zu der OXID Schnittstelle. Da ich freundlicherweise einen Testzugang zu dem Entwicklungssystem bekommen hatte konnte ich OXID2CON testen. Das erste das auffällt ist das der eShop der “Master” ist. Also die gesamte Webseite wird durch den Shop gesteuert und CMS Inhalte werden aus Contentido geladen. Die Lösung ist elegant und einfach. Wie schon im letzten Artikel erwähnt werden die eShop Kategorien genutzt und um den CMS Inhalt erweitert. Dazu kann man im Admin aus einer normalen Kategorie eine “Contentido-Kategorie” machen und den Inhalt auswählen der dynamisch aus Contentido geladen werden soll. Das bedeutet die Inhaltspflege findet im Contentido Backend statt und im Shop Backend wird dann festgelegt wo der entsprechende Inhalt auftauchen soll. Links zwischen CMS Inhalten machen keine Probleme und auch dynamische Inhalte aus dem Shop (wie Artikellisten) sollen sich darstellen lassen. Ein kleiner Wermutstropfen: Momentan wird nur eine Sprache unterstützt. Aber da CMS wie auch eShop mehrsprachig sind,  wäre eine entsprechende Erweiterung, so wurde mir versichert, kein größeres Problem. Den angezielten Preis kenne ich noch nicht, werde ich aber nachreichen.

TOXID
Beim Thema Preis noch eine kleine Ergänzung zu TOXID aus dem letzten Artikel. Die Version für den OXID CE und soll auf jeden Fall Open Source veröffentlicht werden. Daumen hoch dafür!

DIY (Do it yourself)
Abschließend möchte ich noch auf ein Tutorial von Andreas Ziehten (Anzido GmbH) zum Thema “PHP Modul Programming with OXID eShop CE” verweisen. Denn das gewählte Beispiel ist eine Erweiterung des eingebauten CMS um die Möglichkeit CMS Artikel zu verschachteln. Sofern man den Shop also selbst erweitern möchte ist dieses Tutorial ein perfekter Startpunkt.

Gerade finde ich in meinem Postfach eine Mail die mich informiert das top concepts ihre Integration vom OXID eShop in das hauseigene CMS abgeschlossen ist. Für mich anlass genug ein bisschen etwas über das Thema OXID und CMS zu schreiben.

OXID CMS – Status quo:

• Der eShopbesitzt CMS Seiten die an beliebiger Stelle eingebunden werden können: als Link oder im Kategoriebaum
• Jede CMS Seite besteht aus einem großen Textblock der per WYSIWYG Editor befüllt wird, einen Titel und außerdem kann die SEO-Url angepasst werden.
• Natürlich unterstützen die CMS Seiten genauso wie der Rest des eShops beliebig viele Sprachen

Mit dieser Basisausstattung kommt man, wie ich aus eigener Erfahrung weiss recht weit. So gibt es sogar “nicht”-Shops die mit mit eShop umgesetzt wurden und den Shop als CMS nutzen (z.b. Anzido Akademie). Dennoch stößt man natürlich bei sehr inhaltslastigen Angeboten schnell an die Grenzen. So z.B.:

OXID CMS – das fehlt…

• CMS Seiten sind nicht durchsuchbar
• alle CMS Seiten haben das gleiche Template
• CMS Seite können nicht beliebig verschachtelt werden (so wie z.B. Artikel in Kategorien)
• das Rechte & Rollen System der EE (OXID eShop Enterprise) greift nicht auf einzelnen CMS Bereiche / CMS Seiten
• es gibt nur eine Textbox pro Seite
• …

top concepts CMS

Schon seit dem 4er Release gab es immer mal wieder Bemühungen diesem Problem Abhilfe zu schaffen und jetzt scheint eine weitere Lösung fertig zu sein. Was top concepts in ihrem Blog schreiben klingt vielversprechend. So wurde der eShop in das bestehende CMS eingebunden wobei das CMS der Master ist und jede benötigte eShop Funktionalität einzeln lädt/aufruft. Da das CMS eine SaaS Lösung ist kann man den Code leider nicht begutachten, muss sich als Nutzer bzw. Reseller aber auch keine Gedanken darüber machen gut zu hören ist das der Shop weiterhin getrennt vom CMS läuft und auch voll updatefähig bleibt. Auch wenn ich das top concepts CMS nicht bis ins Detail kenne scheint es mir ein erwachsener Vertreter seiner Zunft zu sein. Um als externen Entwickler / Agentur in den Genuss dieser CMS eShop Kombi zu kommen wird es ein Resellerprogramm geben. Ich bin schon jetzt sehr gespannt darauf.

TOXID

Doch top concepts sind nicht allein. Ein weiterer Ansatz an dem auch schon lange gearbeitet wird scheint sich auch der Fertigstellung zu nähern:
“TOXID” Was sich giftig anhört ist das Projekt von Joscha Krug (aka. Marmalade.de) mit dem Ziel Typo3 mit dem OXID eShop zu verheiraten. In dem letzten Blogpost zu dem Thema hört es sich so an als ob die Fertigstellung in nicht all zu weiter Ferne liegt. Anders als bim voherigen Beispiel soll hier der OXID Shop der Master sein und Typo3 dem Shop also seine CMS Features zur Verfügung stellt. Vergleicht man den Umfang beider Programme so scheint es als ob David hier über Goliath befiehlt. Mir gefällt dieser Ansatz jedoch sehr gut, denn bei einem eCommerce Projekt sollte der eShop im Vordergrund stehen. Auch soll es vielleicht eine Open Source Version geben, was angesichts der Tatsache das Typo3 wie auch OXID Open Source sind natürlich wunderbar wäre. Leider gibt es noch keinenkonkreten Veröffentlichungstermin. Aber ich schließe mich dem Kommentar von “TypoTom” auf o.g. Blogbeitrag an und biete gerne meine Hilfe an sofern es sich um ein Open Source Projekt handelt.

Fatchip OXID CMD Modul

Neben diesen beiden “Verschmelzungen” gibt es auch noch eine eigenständige Extension zum OXID eShop welche die bestehenden CMS Funktionen aufbohren soll. Das von Fatchip angebotenen Modul. Leider ist die Beschreibung recht mager aber es scheint so als ob viele von meinen oben aufgeführten Problemen gelöst werden. Es gibt eine Rechteverwaltung, seperates Tempaltes und ein dynamisches Menü (was genau das auch immer ist). Ich werde mal schauen ob ich eine Version bekommen kann um sie ausführlich zu testen und dann hier an dieser Stelle mehr Details zu berichten.

DIY – Do it yourself

Zu guterletzt kann man auch selbst Hand an legen und mit ein paar einfachen Tricks das bordeigene CMS aufbohren. So kann man auch Artikel und Kategorien als CMS Seiten nutzen. Beiden kann man eigene Tempaltes zuweisen und beide besitzen ein WYSIWYG Textfeld. Damit haben wir dann die Möglichkeit CMS Seiten beliebig zu verschachteln (mit Hilfe der Kategorien) und können für jede CMS Seite eigene Templates vergeben (mit Hilfe des Template Feldes für Artikel und Kategorien). Auch werden dies CMS “Artikel” ohne weiteres durch die Suche gefunden. Ein bisschen sollte man den eShop jedoch durch eine Extension anpassen um z.B.

• zu verhindern das diese “Artikel” gekauft werden können
• die CMS Artikel in der Suche gesondert dar zu stellen
• ein gesonderte Darstellung im Admin um die Pflege zu erleichtern
• …

Also auch hier kann man viel Zeit investieren, aber wem die bestehenden Lösungen nicht gefallen hat hiermit einen guten Ansatz es selbst zu machen.

Ich hoffe ich konnte den ein oder anderen Einblick hinterlassen und wer noch weitere OXID – CMS kennt möge doch bitte einen Kommentar hinterlassen.

Mathias Krieck recently publish an easy way to change scope of methods and variables.

The main use is for unit testing (e.g PHPUnit) when you need to access protected or private variables / methods. With his “Super Proxy” you do:

$oInstance = SuperProxy::getInstance("CLASSNAME", $aParams);

Whereas “$aParams” is an optional parameter. The return value “$oInstance” is an instance of the given class where everything is public. So you can access everything from outside.

Stop!!!
Do you want to post a comment like “bad coding style” or something similar? First you should be aware that this helper is intended to be only used for unit testing or other meta programming, but NEVER in productive code.

I myself think that’s fine And of course it’s open source!

So please help Matze to win the “Innovation Award” by voting for him here.

I recently did an update from an old OXID eShop Version PE 3.0.4 to the newest Version of PE 4.1.5.

Although most of the things went well I ran into several problems. Sharing the solutions here might help you and will for sure help me for the next update

1. no cumulative updates: As there are no cumulative updates you are forced to do each update step separately from Version 4.0.0.0 to 4.1.5. As there is only an updatescript from 3.0.4. to 4.0.0.0 you are forced to do all 9! updates afterwards. OXID promised that there will be cumulative updates in the future so you’ll be able to say “give me a patch from 4.0.0.0 to 4.1.X and you’ll get a single file. But as we are not living in the future (yet) here is a simple list of 9 SQL scripts you have to execute to come from freshly updated 4.0.0.0 to version 4.1.5. Be aware that there are also 2 PHP files you have to copy to doc root and execute after the according SQL has been executed.
Download all OXID update SQLs at once.

2. OXACTIVE > 1 in oxarticles table: The oxactive field in oxarticle table is responsible to activate/deactivate an article. Allowed values are 0 and 1. But after update it may happen that you have a lot of “2″s as values, leading to “half active” articles. I can tell you, thats quite confusing . Here is the accorind note by OXID and with the following SQL you can fix it:

3. Old orders have sum of 0 and all articles of an old order have thr price of 0. Nearly all entries in the order overview in admin might become “0″ after an update. The reasons are new fields in oxorder and oxorderarticles tables. These fields might not be filled. Thats why you’ll need the following SQL:

An according note by OXID about the third of these SQLs. The first two I build myself.

Of course all the files and SQLs are without ANY warranty and you use them at your own risk! Don’t forget a backup before you do anything!

Please leave feedback

The OXID eShop has a really cool lazy loading mechanism implemented in oxBase class. Its mainly used to save memory and avoid overloaded objects. Usually this is not needed for “small” classes like e.g. oxvendor oxcategory. Thats why it is deactivated per default in oxBase class:

$_blUseLazyLoading = false;

But sometimes it makes sense to activate lazy loading. One example are the categories. When a category list (oxCategoryList) is loaded somewhere in the shop only a selection of data fields are loaded into the single oxcategorxy object. This can cause some porblems if u want to access own fields or e.g. the oxthumb of the category within a category list.

In practice I wanted to show the thumb picture in a category list but I could not access the field, cause it was not loaded per default.

One solution would be to extend the field list in the “_getSelectString” method of oxcategory list. But a much simplier and more elegant solution is to activate lazy loading for the categories. Thereby it will be possible to access all fields of oxcategory!

There is s slight disadvantage of this solution: Every (first) access to a not loaded field of each object will fire a SQL query. Accessing a huge amount of not loaded fields on a long category list could thereby kill the performance of your shop …

I attached a small module activating lazy loading. Just put the file to your modules folder and add a line in admin module entries like this:
“oxcategory => mude_lazyloading” for each class you want to activate lazy loading.

Download here

Have fun and pleas give me feedback …

EDIT: It’s always the same, on first version there is always a bug The first version only works without caching. The new Version 0.2  has one more line:

“self::$_blDisableFieldCaching[get_class($this)] = true;” to disable field caching for our class in order to make lazy loading work also with caching.

Das Modul “mude_avatar” ist jetzt in Version 0.9 verfügbar.

Das Modul versieht alle Userkommentare zu Lieblingslisten und Produkten mit einem User Avatarbild das der Nutzer in dem “mein Konto” Bereich hochladen kann.

Für die Bugfixes bedanke ich mich bei: Hano und Henry von http://conceptmarketing.de/

Eingesetzt wird das Module bei http://www.hairpoint.de z.B. hier (http://www.hairpoint.de/Haar/Haarpflege/Frisiermittel/Haarpomade/Hairgum-Pomade-Vanille-100g.html)

Download und weiter Infos hier im Blog, bei google code und im OXID eXchange.

Das Modul Avatarbilder für OXID eShop (mude_avatar) ist heute soweit fertig das wir es hier und bei google code veröffentlichen. Das Modul ist Open Source (GPL V3) und erweitert den OXID eShop (> 4.0.1.0) um Nutzerbilder neben den Kommentaren/Lieblingslisten. Jeder angemeldete Nutzer kann sein eigenes Avatarbild hochladen oder seinen Gravatar Account nutzen. Alles weitere auf der Projektseite.