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

Usually I’m not in blogging about a software release, especially if it’s not a major release. But this time I’ll make an exception.

On 29th of October OXID eSales released the version 4.2 of OXID eShop and as readers of my blog know I’m working a lot with this shop software. Also I was never overpraising the shop, although it’s a good piece of software there are still some quite ugly parts in it.

That’s why I was surprised twice by the current update:
- First it only contains things I was missing a lot (usually when there are updates of any piece of software there is always some uninteresting new stuff …)
- Second the way the new things are done is in a nice and even DRY way

Let me give you an example:
- Adding new languages automatically just feels so much better then having to edit the database yourself
- The template overriding system is so neat But why can’t I choose the template dir from admin? (a config file entry is necessary)
- The new “Help Popups” in admin you can add with just one call:  [{ oxinputhelp ident="HELP_SHOP_MAIN_PRODUCTIVE" }]

Finally the multidimensional variants: YEAH! The way it was implemented is really clean and performant! One small downside: The handling in admin could have been better (it’s really not comfortable) . But there are more versions to come and if the quality of further releases will be like the 4.2.  I’m looking forward ….

Ahhh, one more thing: Oxid set up a “uservoice” where you can vote for new features. Have a look here and don’t forget to vote for my latest wish.

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

I just wrote a small module for OXID eShop that automatically deletes the “tmp/” folder at the beginning of each call. The module does nothing when shop is in productive mode.

Background: The OXID eShop does its smarty and its object caching in the folder “tmp/”. Even when productive mode ist off some caching mechanism still work which sometimes causes funny behaviour during development: “Why can’t I see a change, I just changed the whole function/database/template …” In the past you had to delete all files from”tmp/” manually, now you have this small module doing the work

Of course this module is open Source (GPL V3) and can be downloaded directly here(mude_dev) or you can have a look at OXID exchange and don’t forget to vote for us