If you follow Sylius developments, you may remember that I wanted to extract standalone PHP e-commerce components from our Symfony2 bundles.
Next week I am going to merge the components branch and this will cause several BC breaks. Continue reading to understand why I do this and how you can upgrade.
I want Sylius to be clean, well-decoupled and loved by developers. I think that a lot of Symfony2 coders already like it – they feel like home.
Add BDD tools (Behat & phpspec) and we can safely say that we have cutting-edge technology environment for Symfony developers.
Why not go one step further? PHP hackers are a lot more than just Symfony users, Laravel developers want to develop their own e-commerce and they consider using Sylius.
I don’t think Silex is suitable for web stores, but what if you want to develop just a basic e-commerce interface and send carts to your e-mail? Why not make it easier?
You decided to use your own framework – that’s fine, but why reinvent all the logic, services and domain behind inventory management, payments and promotions? Use Sylius components.
I think the idea is very clear to all Symfony developers because that is how this framework is built. It is a set of components and bundles.
I always believed that Symfony2 bundle should be an integration layer between the framework and a PHP library.
This change will be beneficial for Sylius codebase and community, which will be able to grow outside the Symfony ecosystem.
An overview of how Sylius looks after the introduction of Components…
Everyone using main Sylius application and standalone bundles. Bundles not affected by these changes are:
If you use any of the bundles listed above, you should be relatively safe.
Bundles which are most affected and involve namespace and logic changes:
Adapting to changes applied to these bundles will requires a bit more work.
You do not have to upgrade immediately, before the components merge, Sylius 0.9.0 will be released. You can safely stick to this version until you find time to adapt to the latest changes.
Upgrading to the latest Sylius version 0.10.x will involve mostly namespace changes, but if you used or customized product related forms/logic, you will have to update some method and form type names accordingly.
I can safely estimate that upgrading should not take more than few hours, if you follow our instructions. In most cases it will take under 60 minutes.
All models and model interfaces have been moved to SyliusComponent[Component-Name]Model namespace.
Services and their interfaces, which do not rely on Symfony have been moved to SyliusComponent[Component-Name] namespace.
Due to popular demand, two packages have changed their names.
SyliusTaxonomiesBundle becomes SyliusTaxonomyBundle and SyliusPaymentsBundle will be renamed to SyliusPaymentBundle.
As you can already guess, the component names are Taxonomy and Payment, respectively.
It is still up to decide how we handle this on Composer part. I will inform you as soon as I figure this out with the guys behind Packagist repository.
This is the biggest change to the logic and architecture, but I wanted to do this for a long time and decided that this is the best moment to do it.
SyliusVariableProductBundle and SyliusProductBundle will be merged together and 2 new bundle and component pairs are introduced.
I always hated how object options, variants and attributes are coupled to product catalog because this functionality can be used a lot outside the Product model.
SyliusAttributeBundle will give you Attributes support for multiple models in your application. For Sylius it will be obviously Product model, but you can use it for as many entities as you wish.
This bundle provides the functionality you already know from the ProductProperty from old ProductBundle. I thought that Attribute is much more clear naming.
SyliusVariationBundle is even more cool because it can add Options and Variants support to any of your models. Want to have your Server entity in different variations and then integrated it with Cart?
Thanks to this new bundle you can have many variable models in your project.
These bundles will automatically register new forms and services for every object you register in the configuration.
For example, if you want to have servers and computer sets with options, you can configure them under the sylius_variation node and following forms and services will be generated.
sylius_server_option and sylius_computer_set_option forms as well as sylius.repository.computer_set_variant and many more.
It makes much more sense to have these functionalities decoupled, instead of strictly available only to products.
I will explain these features in detail in another blog post.
Together with the merge of components branch, we will include a new UPGRADE file, which will contain detailed instructions with code snippets for fast namespace changes.
Sylius is still in pre-alpha development stages. This is the price of having a great solution at the end of the whole process.
The only large BC break I predict in coming weeks is addition of the built-in multi-store support, but it will come with a similar warning blog post as current BC breaks.
Let me know what do you think about this move in the comments section below and please contact me at [email protected] for any assistance in upgrading your current project.
I will do my best to improve the migration instructions.
Expect an exciting blog post on Monday, which should bring a smile to face of people who miss Sylius theming and nice frontend.
Happy coding!
