Morgen und Übermorgen, also am 25.09. und 26.09., findet in Leipzig ein Jelly im Rahmen des Atoms & Bits Festivals statt. D.h. im Klartext das jeder eingeladen ist, an diesen beiden Tagen seinen Laptop ein zu packen und ins Kultiviert Anders zu kommen um dort zu arbeiten. Also endlich mal raus zu kommen aus dem langweiligen Homeoffice! Beim Arbeiten neue Kontakte knüpfen oder einfach das Gefühl haben “Ich bin nicht alleine”.

Alle Infos befinden sich auf dem Coworking-Leipzig Blog.

Also ich werde auf jeden Fall da sein!

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.