Updating the translation platform for OXID eShop

Tuesday, March 18, 2014 Posted by

The last weekend I spent in Herdecke, Germany on invitation of my mate Daniel Schlichtholz, the main coder of the translation center oTranCe. oTranCe was originally invented for localizing and managing the language keys of Daniel’s other pet project, MySQLDumper, and is used as a localisation center for OXID eShop as well. So me and Daniel spent a plenty of time with updating the software oTranCe as well as the OXID eShop language keys, oTranCe manages. This is more or less a note to myself for documentary purposes.

The manual software update of oTranCe (there’s no new version yet, just wanted to get up-to-date) basically consists of three steps:

  1. Clone the original GitHub repository of the oTranCe project to your local machine and copy the following folders to your installation: application/, library/Msd/ and modules/
  2. Find the necessary database changes in docs/database/ and run the appropriate SQL files (best using MySQLDumper ^^). In this case I had to run the update SQL files 4, 5 and 6; it is not tragic if you use a SQL file that was already executed.
  3. The file application/configs/config.dist.ini may contain new database tables. Merge this information to your existing config.ini in the same folder.

Done – the software is up-to-date again. Please note again that this is not an official tutorial for updating oTranCe. When publishing the next version, oTranCe most likely will provide an own update script that takes over the steps described above.

With this update, the OXID’s translator community gets a couple of very cool new features as are:

  • Git integration: besides an existing version control with SVN it is now possible to use Git and GitHub with it. The parameters can be set by an administrator. Every user with the right of exporting language files will now be able to hit the button for sending an update to your own repository on GitHub.Git integration in oTrance
  • In the past it was possible to use the Google translation API for suggested translations as an external service, we just never used it at OXID. Now the external service MyMemory is additionally available in oTranCe and switched on by default in the translation center of OXID eShop.MyMemory
  • Thanks to the contribution of Josef Roth to oTranCe, it is now possible to flag when a key in the default language was changed.
    detect changed language keys
  • Last not least it is possible now to change the order of the entries when clicking on the table headers in the overview (Home) and in statistics.Screenshot from 2014-03-18 16:30:46

Hope you guys have fun with the new features. With the official update of oTranCe we will describe this new features more precisely incl. screenshots etc. on the oTranCe project’s home page.


As announced on OXIDforge, the language handling in OXID eShop was streamlined, and the new version came with a lot of changes in language keys at least for the store front that couldn’t be sorted out manually. For updating this language keys, I did the following steps:

  1. Export the language files (all languages) without replacement by the main language (English) in oTranCe
  2. Flush the oTranCe tables keys and translations
  3. Import the new language files for the main OXID eShop version 4.8 languages German and English with an admin user with the permission to add new language keys
  4. Switch off the permission to add new language keys for this admin user
  5. Import all other languages file by file
  6. Tag a new version 4.7 in GitHub and clean up the master repository with git rm
  7. Copy all other files belonging to the languages (flags, maps, transliteration lists etc.) to the export directory of the oTranCe installation and git add/git push them to origin master

That’s it. I will now inform the translator community about this update. Also I’ll  have to adapt the tutorials about the language handling, and to think about how to maintain the language files of the modules delivered with the standard OXID eShop setup.

Setting up OXID eShop on a LAMP system on LinuxMint

Thursday, December 5, 2013 Posted by

This is more or less a notice to myself. I switched to LinuxMint recently and tried to setup a LAMP system including all modules in order to run OXID eShop on it (I basically need it for my daily work). This became fairly different to the Ubuntu installations I ran before, and I found some dodgy tricks that I want to document here.

First off, this is the exact Linux version I run, found with $ cat /etc/*-release

DISTRIB_ID=LinuxMint
DISTRIB_RELEASE=1
DISTRIB_CODENAME=debian
DISTRIB_DESCRIPTION="LMDE Cinnamon Edition"
PRETTY_NAME="Linux Mint LMDE"
NAME="Linux Mint LMDE"
ID=linuxmint

Open your terminal client to install Apache2 (web server), MySQL (data base server + client) and PHP version 5 (interpreter language) on your machine. This is possible in a single step; please note that you’ll be asked for the root password during the installation:

$ sudo aptitude install apache2 mysql-server mysql-client php5

This command will install Apache/2.4.6 (Debian), PHP version 5.5.1-2 and MySQL version 5.5.31 to your machine at the present date.

After that, download OXID eShop, make a new directory oxideshop_ce in /var/www/ and unzip the package to it. Fire up your browser and enter http://localhost. Now the setup routine of OXID eShop shall appear and will complain diverse PHP extensions as not installed: “Your system doesn’t fit the requirement. The OXID eShop will not work without it and cannot be installed.” (sorry I didn’t take a screen shot).

In my case, the following modules had to be installed separately:

  • JSON
  • MySQL client connector for MySQL 5
  • GDlib v2 [v1] incl. JPEG support
  • cURL

Please use this command to install all of this extensions just in one piece:
$ sudo aptitude install php5-json php5-mysql php5-gd php5-curl

Now restart your apache service:
$ /etc/init.d/apache2 reload

Reload the web page in your browser at http://localhost and you’ll see that the error messages at least for the PHP extensions will have turned from this little red crosses into green hooks. Two things left over: “Apache mod_rewrite module” and “Files/folders access rights”. Let’s fix it quickly:

$ a2enmod rewrite
for enabling the mod_rewrite module in apache. Additionally, you’d have to alter (caution, this is different to any other location I’ve seen yet!) AllowOverride None to AllowOverride All in /etc/apache2/apache2.conf this block:

Options Indexes FollowSymLinks
AllowOverride All
Require all granted

Restart your apache service once again to see that this issue is resolved. If you run your own local machine, maybe just for testing, it shall be okay to change the rights for the entire folder oxideshop_ce to 0777. If this is your development or staging environment, be careful and go closed to the instructions given at http://wiki.oxidforge.org/Installation#Files_.26_Folder_Permission_Setup. Please don’t forget the -R command for recursive to all folders and files.

You’re done and can now start to install OXID eShop on your own localhost!

A Concert for Holger Hempel, Fighting on Cancer

Friday, November 22, 2013 Posted by

A Concert for Holger Hempel, Fighting on CancerHolger, one of Leipzig’s most empathetic saxophone and keyboarder players, and a good mate of mine is suffering from cancer quite recently. In a spectacular campaign on Facebook, his friends are about to organize a concert

on December 8th

at the club Anker Leipzig

The revenue from the entry fees (8 EUR) will help to pay for the raising costs for his therapy. In the mean time, the concert twists into a kind of Woodstock festival, as the bands (mostly Leipzig) have that vibe, plus special guests.

Here’s a list of the bands participating:

Save the date and get your musical boogie buttocks off of your couch! Help save Holger’s arse as well (literally & not funny), and experience the magic of the still existing East German Rock/Blues scene.

If you can’t afford to come to this event, @Knorri set up a special bank account for donations. Thanks for being openly generous!

Account holder: Thomas Renker (@Knorri)
Account# (IBAN): DE33860800000700777200
Bank code (BIC): DRESDEFF860 (Commerzbank Leipzig)

(Should work for all money transfers in and outside Germany and the EU.)

Looking forward to the concert, also being optimistic about Holger’s recuperation through his therapy.

Distributed Installations with Different URLs for Languages

Wednesday, July 17, 2013 Posted by

Google and other search engines decide from the location of your server IP address how your site will rank in their search results.

This might become a problem, especially for e-commerce sites, if you want to target another market, as these kind of sites usually change their content incessantly, like the stock display etc.

Let’s start over with an example to state the case more clearly. Let’s say Hans is an online merchant who started with just a small budget, delivering only within his homeland of Germany. When he started, he decided a) for OXID eShop as his shopping cart software, b) for a German hosting provider (to make sure that he has somebody trustworthy within easy reach, and c) he registered hans-products.de as a domain for his e-business. Later he learned that this choice was on the button: he got a German IP address, and because he sells extraordinary products, his store ranked on one of the first places.

A couple of years later Hans on his holidays visits Madrid. He talks to some people and recognizes that the interest in his products in Spain seems to be immense. So he decides to expand his online business to Spain.

The first thing Hans has to do now is to translate his OXID eShop into Spanish, not only the language files but also all information in the database like product items etc. He activates his new language, sits back and waits for his Spanish customers. But nothing happens, and for good reason: he runs a German domain – why should a search engine display his information in Spain although his site is translated?

language dependent base URL in OXID eShopHans comes across this nice little feature in OXID eShop: a language dependent base URL. “Brilliant!” he thinks – and off he goes talking to his hosting provider, additionally booking the domain name hans-productos.es. He enters his new domain name and look, it works perfectly: when he changes the language, the shop magically switches the URL – back and forth and vice versa. Now Hans sits back again waiting for his Spanish customers and this time he seems to be more successful! He gets some orders per week, but he is still far away from the point where he could talk about bringing home the bacon. What’s the reason for it?

Like I stated at the beginning, one criteria for the global search engines seems to be the location of the server, and this location can be determined by it’s IP address. Although Hans translated his entire website and registered a Spanish domain name, his site will still poorly rank against his competitors in Spain. If he wants to win the contest, he has to think about an additional hosting at least of the content of his e-commerce website in the country where he wants to be successful, doesn’t he?

And shall I tell you what? It is possible with OXID eShop in any edition :-)

It doesn’t make sense to have two complete installations for both countries, Spain and Germany, because the databases would have to be synchronized. Instead, Hans sets up a copy of his online store at a Spanish hosting provider, moves his Spanish domain name to it and links this installation to the German database via a VPN tunnel. This is what we’d call a “distributed shop installation”.

distributed OXID eShop installations

Hans is happy and it was so easy. Well, it works in general but it wouldn’t be IT if there were no pitfalls, would it?

There are a lot of criteria that could influence the performance of such a system. For example, the hosting providers’ connection to the Internet backbones and the setup of the VPN tunnel could be a crucial issue, as well as the distance between both instances. At a distributed server in Brazil or in China the little bits and byte creatures would have to take a much longer way to run to Germany, right? And this effect gets more and more critical the more simultaneous visitors you have on your websites. That’s why, for high load scenarios, OXID offers a special package with master/slave database configurations to intercept such effects even in multi stores.

Of course, distributed installations will not resolve the entire palette of issues if you are considering selling international. There are lots of other points one shall have in mind, just thinking of the legal stuff… Also, for this SEO related topic, I am not really sure if this will work in languages that do not use the Romanic based alphabet.

Finally I must admit that I only had the chance to check distributed installations under “ideal conditions” on servers based in Germany, simply because I don’t have web space in Brazil or elsewhere. Would be glad if you’d let me know about your experience with this.

How to Write a Module for OXID eShop: Round the Price on Product Details Page to a Fiver

Monday, June 10, 2013 Posted by

For my next tutorial about writing modules for OXID eShop I chose a very simple example. The aim is to round up the display of the price on the product details page to the next five cent (or any other currency of your choice). This is because there are countries where it doesn’t make sense to display prices like 7.99 EUR because the value doesn’t even impact on your money bag and the tax authorities deal with it in a gentler way.

The idea for this module was born in OXID forums, my mate @vanilla-thunder helped me to get it running :-)

Let’s have a look at the code now.  First we have to find the getter for the value of the price. A good starting point for searching for it is the OXID eShop source code documentation. Move into the OXID eShop version you are using and search for getPrice here to find the getPrice() method in the oxArticle function. Hint: getPrice() will return all prices, no matter whether you use prices including or without tax, so it’s brilliant for our purpose.

Move to /core/oxarticle.php now and find the method definition that we want to overwrite on line 178:

getPrice() method

Click to zoom

Next: copy the entire method and paste it into a new file which we call mst_oxprice_ch_highfive.php in our example. Place this file into /modules/mst/ch_highfive/core/.

Make the necessary changes to this file, i.e.: add <?php at the beginning, followed by the mandatory statement class mst_ch_highfive extends mst_ch_highfive_parent to make the module work. Then replace the value to your own calculations and you’re almost done. The content of the file should look like this now:

content of ch_highfive

Click to zoom

 

The only thing left is to add the metadata for your module and for your vendor information, maybe an additional icon for it. I described this in more detail in my former blog post “How to Write a Module for OXID eShop: Display “You will save x %” on the Product Details Page“.

I put this ready-to-use extension under the open source license GPLv3 on GitHub again. Please feel free to contribute any additions or changes if needed:
https://github.com/kermie/ch_highfive/

How to Write a Module for OXID eShop: Display “You will save x %” on the Product Details Page

Monday, June 3, 2013 Posted by

Upfront: although I probably have a good technical understanding I am not a software developer. So it’s a pleasure to thank my mates @tabsl, @vanilla_thunder, @jkrug @l3k, @stasiukaitis-saulius and especially @DSB for the patient, almost friendly help while writing this OXID eShop module sample, and letting me understand what each line of code does. My thanks also goes to my mate @stew who usually corrects my English :-)

This example is based on the German blog post “Ersparnisanzeige Artikelpreis und UVP”, and I thought it was a brilliant idea to write a more comprehensive tutorial in a workshop style, showing how to develop a rather simple functional extension for OXID eShop version 4.7 and 5.0 in English. Also, some tutorials about this topic we’ve already had, became a bit dated in the meantime as the module system in OXID eShop is about to be consistently improved.

Alright, let’s start getting some practice in :-)

Create your vendor directory
First off, go to your OXID eShop installation, find the folder /modules/ and add another folder with your initials inside, in my case I used /mst/ (for Marco Steinhäuser). Of course you can also use your company name or something else – just try to be unique in the OXID sphere. From now on, you can place all of your self-made modules into this folder.

Meta data for your modules
Inside this folder, generate the file vendormetadata.php. As it is not used yet (but will be in one of the next OXID eShop versions) you can leave it empty for now.

Besides this file, inside your vendor folder, create a directory with the name of your extension (I chose /mysaving/ in my example) and move it into it. Please note that the folder name must be the same as your module’s ID.

Optionally generate a thumbnail image that describes your module visually and upload it into the module’s root folder; you may name it thumb.png. Take care, you already resized this thumbnail into the right size – it will be shown in the administration panel of your module’s users.

Let’s generate a metadata.php file now and insert some basic information. Please note that there has to be some mandatory variables like id (must be the same like the module’s folder name we generated before), title and extend so the program knows which class you want to extend and where to find your own code. But of course, you can also have other variables inside the array of this plain PHP file.

writing OXID modules saving metadata.php

Click to zoom

 

On this Wiki page you’ll find all information about the meta data file and the variables that you can use:
http://wiki.oxidforge.org/Features/Extension_metadata_file

Implementing the program logic (functionality)
Depending on the method or class you want to overwrite, build the directory tree for your module following the conventions of the shop itself. In my example I want to overload the class oxarticle (which can be found in /application/controllers/ in the shop directory) by my own class mst_mysaving_oxarticle. That’s why I generated the file mst_mysaving_oxarticle.php in /modules/mst/mysaving/application/controllers/, BTW: it is recommended and best practice to use a naming convention like yournameabbreviation_yourclassname_originalclassname for trace-ability.

The rest is a bit of programming magic. I presume you’re familiar with writing object oriented PHP code and I will not explain every single step here. Anyways, I left some comments and hints in the code that may give you some orientation.

Writing OXID modules saving functionality

Click to zoom

 

Working with blocks for the output
Alright, the functionality part is done, let’s now move to the output. Our aim is to influence the view of your template from inside the module structure, without needing to touch the template itself. Hence, you can deliver your module, including the functionality plus the display part completely encapsulated. Hooray updatability!

The template we want to alter is located in /application/views/azure/tpl/page/details/inc/ and is named productmain.tpl. Now try to find a predefined block close to where you want to place your output. In our example this block is named details_productmain_tprice. (Hint: if you cannot determine an appropriate block close to the place where you want to have your information displayed, please simply define a new block in your installation and send us a pull request on GitHub so we can implement it into the standard.) I now defined a new file details_productmain_tprice.tpl in /application/views/blocks/.
All of the information mentioned in the chapter above I had to declare in an array in the variable ‘blocks’ in metadata.php.

Again, I presume you are familiar with the Smarty template engine and left some (hopefully helpful) comments in the file:

Writing OXID modules saving block

Click to zoom

 

Embedding your own CSS
Often it is useful to encapsulate your own CSS or even JavaScript in your module. As you can see from the example above, I placed the mysaving.css (for my very own font and a yellow background colour) into the folder /out/azure/src/css/.

Making your module multilingual
You probably already saw how to display multilingual descriptions of your module in the admin panel via meta data variables for your module.

But in the module itself – in case it is created for international use – you can set language keys in the block file like shown above. The single language key in my example is MST_MYSAVING_PERCENTSAVED and can be defined in the /translations/ folder of your module root. Please use folder names for the translations of your choosing according to the locales you defined in your OXID eShop. In my example, I translated into English (en), German (de) and Russian (ru).

The language file itself must be named something like *lang.php. So if you have to split your language files, it shall not be a problem for the shop magic to assemble these files into an array and display it properly.

Have a look at the content of these language files now. In the Smarty block template, we already assigned the $saving variable as an argument. This argument can be placed into the language files as %s. This is important as you can have a different word order in different translations. For example, Master Yoda would express himself like “You 24% have saved – harrharr”. In this case simply replace the “24” by the %s argument.

If you’d place the percent sign directly, unfortunately nothing would be displayed. This is why the program expects an argument (like %s) here. Try the entity &#37; instead to get the percent sign to show up properly.

Install your module in OXID eShop
Of course you will know how it works already but for the sake of completeness:

  1. Copy the /mst/ folder including all sub folders into the /modules/ directory of your OXID eShop. Please preserve the given directory structure.
  2. Go to your admin panel -> Extensions -> Modules. You shall see the name of your module in the list. If not, you might have a problem with the rights on your server – set the appropriate rights according to your operating system so the web server at least can read your module directory and the metadata.php.
  3. Check the thumbnail picture, your description and title given etc. Make the necessary changes to your metadata.php if needed. If you’re okay, activate your module.
  4. In the store front, check if your module works like expected.
Writing OXID eShop modules saving frontend

Click to zoom

 

Looks alright, doesn’t it? By the way, you can download and contribute to this extension example by forking this working module from:
https://github.com/kermie/mysaving

Here are some additional hints to avoid common pitfalls:

  • Clear your /tmp/ folder (Smarty cache) after every template change.
  • You probably have to install and uninstall your own module more than once. Please make sure you confirm that previous entries shall be deleted from the database or use https://github.com/OXIDprojects/vt-devutils for cleaning up the database entries.
  • If you need help with your module, please refer to the forums.
  • If you want to publish your module under an open source license, upload it to your GitHub account and let know about it so we can fork it to https://github.com/OXIDprojects. This, might attract other users to help with the maintenance of your module.
  • If you chose a commercial license and/or have the feeling that many people would be interested in your functional extension, publish it on OXID eXchange.

That’s it for today. I’ll probably publish some more tutorials/workshops about basic module writing soon(ish), stay tuned! I’d appreciate if you left a comment whether you like it or not, what to improve, which information is missing, which is too much etc.

Romanization and Transliteration of Special Characters in the URL – the Right Way to go for International SEO?

Monday, May 6, 2013 Posted by

Let me say this upfront: I am neither a specialist in linguistics nor in international SEO (search engine optimization). But there’s one thing that has been keeping my brain busy for some time: what is the right method of rewriting a URL if you want to stand amongst a foreign market, on maybe alternative search engines, that uses different characters than simple Latin?

You might know that I am working as a Community Guide for OXID eSales, dealing very close to the product management of OXID eShop, and we feel completely responsible in a SEO-optimized shopping cart platform delivery, not only to the domestic (German) market but beyond.

In OXID eShop, we use transliteration lists for several languages: for example, the German special character “ü” becomes an “ue” in the URL. As far as I know, this works really well, the search for a word with a “ü” on Google would lead you to the transliterated version. If you don’t use any transliteration list in OXID eShop, this character will simply be left out in the URL and for example becomes “Grtel” (blt) in your URL instead of “Guertel” (belt) as it should.

The same goes for some Slavic languages, where they use a “Š” for the voiced “Z”. This could be transliterated to a “sh” in the URL but will search engine users still find “shunka” (Czech for bacon)?

It gets even more complicated when having a look at non-romanized writings like in Russian, where Cyrillic letters are used. Looking up “агрегат бензина” (gas-driven power supply) will lead you to totally different search results on Google then in it’s transliteration “agregat benzina”.

Now that we know that Google is not the true north of the world, I recognized that a search result for “агрегат бензина” could be totally different when related to yandex.ru, in all probability the most-used search engine in the eastern (from us) world, isn’t it.

Also, when searching on Google for the cyrillic version, Wikipedia comes up on the first page with a hybrid, but looks really down and dirty when sharing this link:
http://ru.wikipedia.org/wiki/%D0%90%D0%91_(%D1%8D%D0%BB%D0%B5%D0%BA%D1%82%D1%80%D0%BE%D0%B0%D0%B3%D1%80%D0%B5%D0%B3%D0%B0%D1%82%D1%8B)

Now what is better, use Cyrillic or Latin transliterations for a search? And how do we design the rewritten URLs in a standard software like OXID eShop?

Merry Christmas and a Happy New Year 2013!

Friday, December 21, 2012 Posted by

Dear friends,

actually I wanted to manually send signed Christmas cards to the most distinguished community members and friends. But they took a very long way from our headquarters in Freiburg to the office in Halle and only arrived yesterday. Not enough time left to give them the time to arrive punctually, especially thinking of foreign addressees.

So here they are:

Merry Christmas and a Happy New Year 2013 from OXID

Merry Christmas and a Happy New Year 2013 from OXID

Merry Christmas and a Happy New Year!

Have a nice and relaxing holiday season after this very hectic Christmas trade. A lot of really fascinating things happened in 2012 in the community, just thinking of the OXID user group NRW. May 2013 will be as successful as 2012 was and even more so.

Connecting a HP Deskjet 3050A J611 to a DD-WRT Router when using Ubuntu

Saturday, November 3, 2012 Posted by

Today, we bought a new all-in-one device for home use, a HP Deskjet 3050A J611 series, that was told to be capable for WiFi connections. The delivered software on a CD is available for Windows and Mac OS machines only. Now I run Ubuntu which shall not be a problem as all HP devices are supported by default on this operating system.

And right: I got it working very simply. Connect the USB cable and the driver will be installed even without a click, just use it.

Connecting the printer to your router brings up some more problems. Usually, if you have network-compatible hardware, you can adjust at least a network configuration on it. Not so on the printer we bought: by default, it uses WPS, the so called “Wireless Protection Setup” where you have to enter a PIN to your router. Of course, it doesn’t work if your router software doesn’t support WPS for a good reason: WPS was cracked via brute force attacks a while ago, just wondering why hardware with this software flaw is still delivered by HP…

Anyway, I found a workaround:

I couldn’t bring up running the HP software setup via wine what actually was a good thing: HP doesn’t only bring the drivers but also a lot of bloatware with it onto your machine.

So I fired up my (for emergency cases) still existing Windows installation and went to the entire setup process of the all-in-one device “drivers”. Interestingly, the setup routine asked me if I wanted to use the device via my WiFi network and I agreed. (Sorry that the Windows screen shots are in German.)

Windows installer asks for WiFi configuration

During the next steps, the WiFi configuration was read out and wrote to the device configuration (WTF?). But from this point on, the new device was connected to my home WiFi and got a proper IP address.

drivers are properly installed

Once you finished the installation successfully you can completely delete the HP software from your machine. Start over to Ubuntu again and install a network printer with the given IP address that you can find even on the display of your all-in-one device now.

install the network printer on ubuntu

Printing with CUPS via WiFi works smooth for all Ubuntu machines now. Alone I couldn’t get running the scanner via WiFi but actually I can live with that ;)

Display a Diff as a Webpage using diff2html

Wednesday, September 26, 2012 Posted by

Sometimes, especially for documentation purposes, it might be necessary to show a unified diff as a HTML page.

As we will ditch Basic theme in OXID eShop version 4.7/5.0, we had to document how to convert a customized theme based on Basic if you want to update. Included, we wanted to deliver a visual diff of the categorylist.tpl file to show how the category tree was loaded before and how it will be loaded from the new version on.

I found out that neither my IDE nor any other diff tools I knew could export directly to HTML. After a while of searching I found this great bash script: diff2html

Unpack it and you will find just one single file. On Linux, it is pretty easy to use:

~$ ./diff2html file1.txt file2.txt > differences.html

There are several options as well as an own style sheet that can be used (open this file and have a look at it). But even the default results are looking absolutely suitable.