Over the last two weeks I had the "pleasure" of upgrading two Magento shops to version 1.9 of the Enterprise Edition. I would like to summarize some of my experiences here.
The new version no longer contains the encrypted code introduced in version 1.8. This means there is no longer any need to install an IonCube Encoder module on every platform. So Varien (or Magento Inc., as it is now called) has realized that the path it had taken was a bad one and had simply annoyed developers and administrators.
Magento keeps struggling with performance. For medium-sized systems, the performance of a simple dedicated server may still be sufficient. In the enterprise world, where terms such as clustering, load balancing, etc. come into play, you simply have to say that Magento is too slow. For this reason, the new version introduces a full-page cache. Not a real one, though, because there is still a lot of dynamic content on the page. The new cache divides the website into dynamic and non-dynamic areas. A cache.xml file in each module tells Magento how to handle a block in the layout. Each block can be assigned its own cache model, because a category, for example, needs to be handled differently from a personalized greeting. At first glance, that sounds good. In practice, however, it turns out that you now understand even less of what is happening in the system. The block itself might also still be cached by the standard block caching. As always, there is no documentation. You have to gain the knowledge by looking through the code. That is not acceptable. A system with >1 million lines of code cannot be reviewed from scratch every time.
Another new addition is a manager for customer and customer address attributes. You can now create attributes directly through a GUI, much like the familiar process for products, for example. Again, that sounds nice. The downside (and once again not mentioned in a single line) is that attributes previously created through Magento's API are not migrated correctly. The attributes do appear in the new manager. But you cannot save them. And what is even better... if attributes have been integrated into the checkout, for example, they are no longer saved or passed between the quote, addresses, etc. There are now at least 5 tables involved, and data is missing from them because the migration was not done correctly. Attributes now have to be assigned to individual forms with elements and fieldsets (this only applies to the Enterprise Edition).
The solution is to edit the attributes at the database level, specifically the column "is_used_definied" in the table "eav_attribute".
You can also do this through an update script in your own module. After that, saving through the new manager is possible, and Magento creates the necessary entries in the tables. Saving during checkout then works as well.
Order storage has also changed. Orders are now completely flat. This means you also have to take care of creating any attributes you added to orders yourself. As expected, Magento does not handle this for you.
What is particularly lovely is the lack of backward compatibility. Why can't something be finished before it is brought to market? Or at least mark old features as deprecated for one release? After all, PHP provides the option of raising an E_DEPRECATED warning.
Backward compatible? That looks rather different!
A request to Magento: Don't just bring new features to market; document something for a change, too.
Surely it cannot be that difficult to provide developers with a migration guide covering the major API changes.