TL;DR: yes.
Questions about the future are either answered by choosing points at random or by looking into the past. With several years of experience and contribution I try to go the extra mile to look into the history I witnessed.
So with Shopware 5 we’ve already been able to have voice-commerce applications, connectivity tools to different APIs, good documentation, various developer utilities to reduce boilerplate and an active and helpful community. Though Shopware 5 also has difficulties and limitations I think it is a really good software.
Now with Shopware 6 at hand I think about the previous downsides and I am happy that most of the downsides are already eliminated. Setting up a cluster is easier, having a task queue, updated tech-stack, normalized API and cloud-app-only payment service provider. Some of the previously mentioned points from Shopware 5 are still missing in Shopware 6. But I don’t worry. They had these features before, so they will get them back again. I want to point out how they approach planning: Shopware includes feedback and even requests it from the community. Everytime Shopware takes a big step ahead I was able to participate in providing feedback. Every contribution I did, has been taken seriously into account and has been valued. I was even able to look into Shopware 6’s architecture before the official brand name was known. The fact that Shopware reacts to the needs of the community heavily makes them dependent on the feedback. Don’t get me wrong. What Shopware 6 was on day 1 is basically all their own invention and was sophisticated. But the path the software will take is heavily influenced by the community.
So with this in mind I look into what I expect from the future of Shopware 6. I noticed the demand for a structured API, better cloud-usability as well as for easier PWA options and now we have all of it. With a growing community, with various needs and especially with needs that are less European-centric, Shopware will have a solution for any of the mentioned trends and when they continue like now, it is likely to be a good solution. I wish my and more importantly Shopware’s expectations will be met in the future.
TL;DR: Cart, CMS and community
The cart API is a very crucial part of an ecommerce framework. I really like the cart API from Shopware. One create new cart item types in a very thoughtful way. You have caching of complex data, it refreshes properly, it is merged when logged in, prices don’t just have the calculated taxes but all single values needed to recalculate them yourself. Nesting is also allowed. In addition to all of that: the cart content is persisted exactly like it was when the cart has been converted into an order. This is an important concept as orders are like a snapshot of history. They are still readable even after you deleted the customer, the ordered products from your catalogue and all vouchers used.
Some commerce concepts do not require a CMS. Who needs a CMS for a shop, that is only API driven? But the way Shopware thinks about CMS is a different story. CMS is totally optional. And if you use the CMS it is very plug and play and flexible. CMS elements are only built by developers, which ensures a clear way of using CMS elements. Content editors can rarely break the page as they likely never have to leave a WYSIWYG editor and don’t have to write HTML to achieve great responsive pages. CMS elements also can be used anywhere. Even product pages can just be CMS pages. This gives a lot of flexibility for a content editor without technical support to just change the placement of two blocks. A lot of apps in the community store, that add new content types like FAQs or blogs come with new CMS elements and page types. So you can just place an FAQ item into a blog post without the technical integration of two apps that don’t know each other.
It is for me as an active community member really important to have the community. We are a huge blob of knowledge and to access this is quite useful. And Shopware is itself part of the community somehow. And it is not just about asking or answering questions yourself. You can just follow conversations and learn by reading along. Different developers have various backgrounds. Despite the fact we all work with the same technology stack, we all have different additional knowledge, that is always helpful to get different views onto a topic. You just have to be aware: 99,9% of the community work is something, that is done next to the regular work.
TL;DR: Mostly, yes. Shopware and Symfony blends in at a lot of places.
Although Shopware decided not to use doctrine/orm, which is the ORM to go for when using Symfony, there are a lot of concepts followed that Symfony explains in their own documentation. Even Shopware sometimes points to Symfony documentation for an explanation. So Shopware self-hostable apps for example are database managed Symfony bundles. Bundles are like a plugin system in Symfony. They are mainly used in a hardcoded way. Shopware adds configuration and a lifecycle (install, uninstall, …) to them and now you have a vivid plugin system. So when you make a self-hostable app, you will use a lot of Symfony features.
Shopware decided to plant Twigs at different places in their forest of PHP service classes. You have Twig for the storefront HTML rendering, Twig makes SEO URL templates flexible and editable in the administration, Twig powers the email-templates, Twig is the base for invoice documents, and Twig is even used as a sandboxed PHP for cloud app scripts. As Shopware uses bundles a lot you can also use the “shipped” debug bundle, that adds a lot of useful insights of Twig rendering. ASTs to debug issues or find a good entrypoint for your HTML changes are key. And these are all common utilities from the Symfony community. So Shopware documentation and slack is not your only source of information. You can rely on the knowledge of ten thousands of more developers out there.
Even though Shopware decided to build their own database abstraction layer, they still utilise Symfony. For example when you are up to write your API endpoints for your database entities, you are already finished when you declared your entity definition service in the DI as a Shopware entity. It will create API endpoints for you. Already limited by authentication. There is a lot of magic behind the scenes going on and most of it is Symfony logic. To keep the entrylevel low though Shopware reduces work and boilerplate code for a self-hosted app developer with automatism like the one described to ensure a common API structure and speed up development a lot. When you know Symfony before, it easy to spot, if you don’t you might not even need to know.
In my Steam game library are a handful of games with quite a high amount of hours tracked. But Steam is not collecting statistics from unsupported platforms or games. In there I am missing my 999h+ The Legend of Zelda: Wind Waker entry which I replayed a lot when I was young. I still have the Nintendo Gamecube, the game disc and the memory card with that game file where I grinded the new game plus just to collect all the figurines you were able to have in this game. I also still have the Nintendo Gameboy Advance cable to connect it as a controller into the NGC. This allowed two players to play the game. So in theory the player two is also missing most of the hours in their statistics. After buying a physical extension to upscale the video output of the console to HD video with HDMI port made it even easier to use newer displays than one had to use back in 2002. It is still a lot of fun and there are still good video games I play again.
