One of my ideas for improving Sylius as a community project, is having more transparency about the development plans.
We have passed the point to which I could develop the project alone and roll out surprising updates and BC breaks.
When people are using the code in production, surprises are not appreciated.
Besides the essentials, there are many “easy-pick” issues, which you can close by contributing!
This week I’ll publish a detailed Contributing Guide, which should make it easier for newcomers and less experienced Symfony developers.
Please note that this article is about the Sylius application. Bundles have their own life and can reach stable versions much earlier.
Before I dive into the future, allow me to summarize the current state and history of Sylius.
If you were watching closely the project since the very beginning, you know it all started with lonely bundles.
I fell in love with Symfony2 and its modularity allowed me to create reusable components for my client projects.
I decided to open source the bundles, so that others can use them and contribute back.
At some point, people wanted to see how to integrate the bundles into their existing or new apps. Sylius sandbox was born.
It was a standard Symfony2 app, loosely integrating the components together into a simple shop.
Some people used it as an inspiration to build apps from the bare bundles, or even crafted their own shops on top of it.
Sandbox was clearly missing some features, tests and proper architecture, as it was just a playground and testing project.
Seven months ago I started the Sylius app, embracing StoryBDD with Behat.
Since then we’ve managed to develop a relatively big set of features and achieve a very extensible architecture.
Currently, except finalizing the repositories organization on GitHub, the priority is to fill the feature holes in the checkout and API.
It’s quite a shame, but the main application does not have any payment integration available out of the box.
This is the major challenge we have to face and implement/integrate a payment system, which will have the same flexibility level as other Sylius engines.
I started implementing gateway agnostic solution and will share a POC soon. It will allow to integrate any payment API library into Sylius, hopefully we’ll have many integrations in the core.
Once I publish the proof of concept, we can start an open discussion about possible bundles/libraries to integrate as gateways.
Apache 2.0 license, not maintained/developed very actively and forces us to use concrete data models. Apart from these problems, interesting option.
We have already created an integration bundle for Omnipay library.
Some of you tried it and it seems to work pretty well with Sylius, but the library itself has some architectural issues and involves a lot of BC breaks.
We should be very careful when evaluating this option, but it seems promising.
Payum at first glance looks like the most complex, but I believe it deserves our attention. It seems to be regularly updated and the author has already approached us on GitHub.
The Cart and Order models have been merged and all the checkout-related logic has been dramatically simplified.
Calculation logic and events are already in place, we have to make sure that templates are displaying the data properly in the cart summary.
If user has already selected the shipping method, we should display it, or even allow to change in the cart form.
Tax are recalculated on every cart change, but we have to handle the case when cart is changed and user has already picked the payment/shipping options.
I believe it is essential to have proper notification/confirmation e-mails integrated out of the box. Currently, people have to listen to events and use their own mailers.
What is “a modern e-commerce for PHP” without a nice and RESTful API? All Sylius controllers work on top of the great FOSRestBundle and those who needed the API, got it relatively easily.
I already started some work on routing configuration (in a separate branch), but we need to configure serialization mappings and use one of HATEOAS bundles.
Currently we are using the FSCHateoasBundle to handle the serialization of Pagerfanta (our paginator) instances.
The bundle is more powerful though. We should consider a more complete integration and usage.
There is also another option, the BazingaHateoasBundle. It is a much younger solution which integrates a standalone library into Symfony2.
It seems to have all the features we need, but we should consider both solutions and pick the best!
If you like the new look of our website, then you should be probably happy to hear that I’m discussing the Sylius default theme with the same guy.
I’m going to fund the redesign from my own pocket, so that Sylius may look as sexy as its code.
I’ve already heard from people who would love to use it, but their management is scared off by the look (not functionality) of our demo.
Customizing Sylius look is pretty simple with Twig and templates overriding, but I believe we can do better than that!
Before the designer starts his work, we need to discuss what do we really want – responsive Bootstrap 3 with a nice look? I’ll start the discussion very soon.
At some point, if the time and resources allow us, we could think about redesign of the administration panel.
Before making the final push towards the stable release, we need to focus on the documentation. No matter how great we make Sylius in the coming months, without a decent documentation … it won’t be useful.
I will be doing my best to document as much as possible and we should also consider organizing few documentation hackdays.
In worst case, I will be leading the documentation effort till the end of milestone. The best scenario … would be to find a person who has a bit of spare time to work with me closely on this topic.
I know I’m asking for quite a lot, but that person does not have to be a Sylius guru already.
While the bundles docs got some love recently, the main application has almost no guides at all.
Sylius has already been translated into numerous languages, from Polish to Japanese and Serbian. Most of the translations are incomplete though.
The process we are using for translating right now is not the best possible and I was already exploring different approaches.
I tried Crowdin.net translation service, which is great, but it wasn’t trivial to sync all the translations with multiple GitHub repositories.
I still hope that we can resolve this and find a gentle way to keep Crowdin data up-to-date with git and vice versa.
If you have a suggestion here, please add a comment.
Feature freeze will happen when we finalize the points mentioned above. I don’t want to write this date in stone yet, I expect it to emerge as we progress with the pending issues.
Everything depends on your contributions. I can’t achieve this milestone without the help of the community. I strongly believe that with better organization from my side, we can do even more than that!
After the feature freeze, we’ll focus on stabilization and fixing bugs. Once Sylius main app has working payments and nice RESTful API, we’ll be ready to release a BETA. I want that happen in December 2013, preferably before first SymfonyCon in Warsaw.
How long it will take to move from the BETA to the release candidates and finally version 1.0.0? Hard to tell, but I hope to make it a short way and release a really stable solution at the end.
It’s an optimistic date, but with strong involvement of people around the project and evangelization, we can do even more.
I hope this roadmap gives you a better overview of where we are and where do we want to be in future. If you’re excited, help us!
