Zurich Hackathon March 2013

You always hear about this event. Since one month, everybody is tweeting, facebooking, googling plusing, blogging, chatting but for what the hell reasons should you come! They pushed you against the wall and told you: « You MUST go in Zürich on 8-10th March 2013! That’s the Magento Developer event of the year in Switzerland. ». Sad isn’t it! Find here some arguments to NOT come:

  1. Magento, what is it? I’ve never heard about that. I’m still using the dark side of the ecommerce solution, osCommerce, the best ever Open Source solution!
  2. I’m the best coder of the world. I need no friend, no tips, no network, no fun. I don’t want to share my knowledge with no one because I prefer to work alone, I’m more efficient. PHP is the bottleneck for Magento, I don’t want to improve it.
  3. I prefer to do a world tour. It’s more interesting. Where the hell is Matt?
  4. Achmed – The Dead Terrorist ( didn’t allow me to go. He said if I go: « I kill you! »
  5. The last time I came, it was in Berlin, a Dutch opened all people’s beers with my shiny MacBook Air. It doesn’t work anymore. I’m shocked for all of my life.
  6. I’m not the sponsor. I’m sad and sulking!
  7. I still didn’t digest the sweets of the Munich Hackathon in last october. I cannot move anymore, sorry!

If unfortunately, after all these reasons, you still didn’t find yours. It seems you have no reason to not coming. ;-)

Visit the event website to enjoy with us and get some surprises in Zürich on 8-10 March 2013:

PS: if you have better, funnier or others arguments, please comment them :-)


The problematic

You have SugarCRM as a CRM and you wish for example, export only some users’ information (lastname, firstname and email) to import them to your favorite/shiny newsletter system. By using the export function of SugarCRM, you get a CSV file with all users’ fields and which could be theoretically imported into Excel to remove the columns that you don’t need for your newsletter system importation. Unfortunately, a user field « description » has line breaks which prevent a clean import into Excel because each lines is recognized as a new row/entry which is wrong.


Use Talend Open Studio for Data Integration. A free ETL (Extract Tool) provided by Talend and which will help you to extract exactly the source data wished and export it to any target (example: csv file, database, other web service, etc).

It’s an eclipse-like which works with a Job Designer. You create a job, add input component (file, database, webservice, else), output component (files, database, webservice or else) and other interactions (data filtering, data sorting, etc).

Talend applied to our SugarCRM Scenario

The procedure is quite easy to do and accessible to non-developers (see screenshots below):

  1. Download Talend Open Studio for Data Integration if not already done.
  2. Open it
  3. Create a new project
  4. Create a new job and give a name
  5. On the Palette side panel, select Business > SugarCRM > tSugarCRMInput as Input component and drag’n drop it into the main window (Job Designer)
  6. Double click on the newly created component, it should display in the Component Panel at the bottom of the software the Basic Settings
  7. In the Basic Settings, provide the SOAP URL of your SugarCRM installation. Exple:
  8. Fill in the Username/Password (administrator account)
  9. Important: let all values between double quote  » as it is provided in the default value, otherwise errors occur while running the job
  10. Choose which SugarCRM data module to export. Exple: Contacts
  11. You can take a look of the schema by clicking on the button « Edit Schema ‘…’« . You will see a list of all predefined fields recognized by this component. You can edit it but you don’t really need it. The output component will do the job for you
  12. You can also set a Query Condition if you want only a set of result. Exple: « lastname=’smith’ »
  13. On the Palette side panel, select File > Output > tFileOutputDelimited as Output component and drag’n drop it into the main window (Job Designer)
  14. Right-click on the component tSugarCRMInput and choose the menu « Row > Main » and move the line until the tFileOutputDelimited component. You linked both components.
  15. Double click on the newly created component, it should display in the Component Panel at the bottom of the software the Basic Settings
  16. Provide the file where to output the result. In my case, the file must already exist otherwise the job doesn’t create it
  17. Fill in the options as you wish for the separator, break lines for the row, etc.
  18. If you wish only some columns/fields, click on the button « Edit Schema …« , a new window will appear with the schema of the input  on the left side and the schema of the output on the right side. The output schema should be similar to the one on the left side. Remove all unnecessary fields/columns. In our example, we juts keep « lastname, firstname and email« 
  19. You can also fill in the Advanced settings tab if you wish to set CSV options or delimited characters
  20. When you are finished, select the tab « Run » and click on the button « Run »
  21. You could get an error message that the schema are not the same. Don’t care, keep going.
  22. You should find the result of your exportation into the target file you defined.
Magento Hackathon Logo

Magento Plugin Install

I discovered few weeks ago an interesting tool to develop Magento modules with Eclipse PDT or Zend Studio: the Magento Eclpise plugin. I use it personnaly with Zend Studio 8 and it works pretty well, so we are going to see the different feature you can get from this module. With this module you can:

  • Find two wizards to help you to extend or create Magento modules
  • Code completion for core class or method even when you use Mage::getModel() or Mage::getSingleton() and so on.

Install the plugin

In Zend Studio, click on Help menu > Install Software. A new window will open, click  « Add« , set a name like « Magento plugin » then paste the url of the plugin « » into the location field. After to have submitted the changes, you should see in the list the plugin. Select it and follow the wizard by clicking on « Next« .
Magento Plugin Install
After the installation process, you will have in the dialog box of the menu New > Other …, a new directory Magento and you will see the two wizards available to start or extend a module.
For your Magento projects, you will have to enable the plugin features for the code completion. Just show on your project folder in your Navigator or PHP Explorer, the contextual menu. You should see the Magento Plugin menu item and sub-item « Add Magento Nature« . Select it to enable the feature for your project.
The code completion seems to work only for core modules of Magento, not for the modules which are in the community or local folder in app/code/ of your Magento installation.

Wizard to create module

To create a module in an easy way. Nothing better than the wizard of the Magento plugin for Ecipse. It makes your life easier because you can directly generate the basic structure folders and configuration xml files. Maybe some of you, will prefer to get more generated files like controllers, block grid for the backend, a model and its resource to get access to the database, you can use instead Module Creator from Netz98 at this address The counterpart of this last solution is that it won’t feet all of your needs and you should have to remove some part of the codes or files.
Let’s come back on the Magento plugin for Eclipse. To start the wizard, choose in the menu New > Other …, in the new dialog box, search the folder Magento and choose the wizard « Magento Module« . The wizard will start with the informaion to fill in about the module:
  • project
  • name
  • code pool
  • version
  • dependencies
  • namespace

After you have clicked on « Finish« , your module will have some predefined folder and files in different place in your project. Here is the skeleton:

  • app / code / CODE_POOL / NAMESPACE / MODULE_NAME / Block
  • app / code / CODE_POOL / NAMESPACE / MODULE_NAME / controllers
  • app / code / CODE_POOL / NAMESPACE / MODULE_NAME / Helper / Data.php which is usefull to help you to translate the string of your module
  • app / code / CODE_POOL / NAMESPACE / MODULE_NAME / Model
  • app / code / CODE_POOL / NAMESPACE / MODULE_NAME / sql and a sub-folder to set your database script for installation and upgrade
  • app / etc / modules / MODULE_NAME.xml which is the file to enable or not your module and define the dependencies

Wizard to extend module

The wizard is very similar to the one of the creation module. The difference is that after to have fill in your module information, you will have an additional step to select the module to overwrite and select the classes to overwrite. I could not see completely the result because there were a bug while finishing the wizard. The module was correctly created but didn’t create neither the overwritten class nor updated the config.xml. An issue has been submitted. I will update this article when it will be resolved.


It is with a great pleasure that the Magento Core Team published a public version of the development Magento 2 and information about it. This new version is still in development and will be available when stability, code quality, features and documentation will be finished. It is expected in one year (end 2012). Lots of lack blamed for version < Magento 2 are going to be history (we hope).

The target of this new version is to provide a better documentation (a complete wiki for store owner, developer, system administrator or designer target public is available and still in progress), an improvement of the performance / security / scalability (EAV still exists), PHPUnit Tests and Automatic Static Code Analysis Tests (including PHP Detector Copy/Paste, PHP Code Sniffer, PHP Mess Detector), easier and better support of multilanguage, etc.

But don’t worry dear Magento 1.x developers, not everything has been changed. At the program,  refactoring of some classes, naming convention and templating and skin folders restructuration have been done at the moment. We will see some changes in this first article and how to handle it to upgrade your extensions. Remember, it’s still in development, so the information are there just to keep you informed. I will try to prvovide you up to date information until the official release on this website.

If you are a third party developer, you should follow the recommandations and best practises based on Zend Framework Best Practises and Magento Best Practises (Licenses and category/package/author tags in the docblock of class’ header) to migrate your extensions.

You will find all necessary links about the Magento 2 development version (documentation, svn, tools) at the bottom of this article. But first, I did for you, a resume of the significant changes done between Magento 1.x and 2.x based on the documenation available in the Magento 2 Wiki.


New folders:

/dev internal tools and tests. Previously: /shell, /tests, /tools to /dev/shell, /dev/tests, /dev/tools
/pub All public content: /pub/images, /pub/jslib, /pub/skin, /pub/error – Fallback/Materialized files are stored in this folder

Removed folders:

/includes Compiler feature is removed
/downloader Folder removed but the Magento Connect feature is moved to /app/code/core/Mage/Connect/

Template / Layout folders

One of the main changes is that base theme files and folders (layout, template) are moved to each module folder in a folder named « view ». It means you will get for your module the following structure  app / code / code_pool / Namespace / Module / view / area / *

  • Namespace = your company name or else
  • Module = module name ;-)
  • code pool = core, local or community
  • area = frontend or backend
  • package
  • theme

Here are some examples of the migrated folders:

  • for emails template, FROM app / locale / en_US / emails / * .html TO app / code / code_pool / Namespace / Module / view / *.html
  • for skin files of a specific module in adminhtml area (js, css, skin images),  FROM skin / adminhtml / default / default / * TO app / code / code_pool / Namespace / Module / skin / adminhtml /
  • for skin files of a specific module in frontend area (js, css, skin images), FROM skin / frontend / default / default / * TO app / code / code_pool / Namespace / Module / skin / frontend / *
  • for layout and template files (*.phtml), FROM app / design / frontend / default / default / layout (or template) / * TO app / code / code_pool / Namespace / Module / view / layout.xml as a convention (or path/to/file/*.phtml)

And non-base theme files (confer Magento wiki: theme files that overlap base files in modules) are structured as follow:

  • An overwritten template file, FROM app / design / frontend / package / theme / template / module_alias / path_to / template.phtml TO app / design / frontend / package / theme / Namespace_Module / path_to / template.phtml

A Module directory structure will lookt at this:

| |-- Sample.php
| |__/adminhtml
| |__/frontend
| | |-- layout.xml
| | |-- sample.phtml
| |__/install
| |-- contact_email.html
| |-- image.jpg
|-- favicon.ico

Source Magento Wiki Module View

Fallback/Materialization mechanism

The fallback mechanism still exists and if you want to overwrite a template or layout file, you still need to use the folder structure app / design / area / package / theme / Namespace_Module / layout.xml (or path_to / template.phtml). Layout and template folders doesn’t anymore exist but you will notice that you need to use the combination Namespace and Module as a folder name for the layout and template files.

All public content are stored in the folder /pub, it contains static files like images, javascript or css and are copied from the module skin folder. They will be automatically redundantly saved once or after an update, following its folder structure in the module view folder, to the /pub folder to keep only this folder visible to public and make skin modular too.

You will get the following structure for the static files:

  • / pub / skin / area / package / theme / *
  • / pub / skin / area / package / theme / Namespace_Module / *
For the fallback mechanism, you can still use a design package folder structure:
| |__/skinName
|   |__/css
|   |__/images
|   | |--image.jpg
|   |__/locale
|     |__/localeCode
|       |--translate.csv
For a more information about module view, you can check the Magento Wiki Module View

Skin File Duplication Option

This option, if enabled, creates automatically a copy of static files which is not locale dependant to all other locale store View. For example, you have a file logo.png for the locale en_US, the file be copied automatically to the fr_FR locale folder of the / pub / skin / area / package / theme / default / locale folder.
To enabled it, you have to edit the file app / code / code_pool / Namespace / Module / etc / config.xmland provide this xml code:


Source Magento Wiki Skin Duplication


Here were some few examples of the new features and way how will go our preferred open source commerce. And it will stay like that, Open Source, even if Magento has been bought by eBay. I don’t know yet what will be exactly the next steps but I make a new article about the framework and his new behaviour and coding practises. If your impatient, well, you can still visit the links below to show you more information and detailed explanation of what we see here.

Magento 2 links (some are working in progress):