Exploring Shopware 6 Extensions

Transcript

Brandon: Hey everyone! Welcome back to today’s episode of our podcast. We’re super excited to have two amazingly talented developers with us today. We’re going to be talking about all things Shopware, extending Shopware, and leveraging the experience these guys have in this area. I’m super excited to have both Christian and Vlad here with us today. This podcast is really about their experience, what they know, and what they’re doing. So, we’re excited to have them. Why don’t I pause and give them a chance to introduce themselves?

Vlad, why don’t you introduce yourself? Tell us about you, who you’re with, and what you’re doing.

Vlad: Yeah, hello there. So, I’m Vlad. I’m a Shopware developer & Tech Lead at IT Delight.

Christian: Hi from my side! Great to be here. My name is Christian, and I’m from the German Shopware agency Dasistweb. I’m working as the Head of Technology, so I`m one who needs to make sure everyone can work with all the technologies we’re using. I’m also head of QA, so that is probably why you hear me talking a lot about testing and improving quality. I try to do a lot in the community, building tools like Dogware, translation frameworks, testing frameworks, and I’m developing all the time basically and just try to do stuff that people hopefully like.

Brandon: Awesome. Thank you both for taking the time. 

Shopware is so exciting. Between the two of you, there are hundreds of projects and all sorts of experience. I’m excited to learn from you today about some of the things you’ve done and how you’re extending the platform. Clearly, Shopware has been around for a while, especially in the European markets, and we’re just starting here in the United States, which is fun. I love that we’re representing all parts of the world and elements of Shopware as we learn more.

Let’s start with Shopware. It has an incredible out-of-the-box feature set, but maybe we can quickly highlight some of your favorite out-of-the-box features as developers and for merchants. Christian, why don’t we start with you? What are some of your favorite out-of-the-box features before we talk about extending them?

Christian: Out-of-the-box, I would say Rule Builder. It can get complicated, but once you know how to handle it, it’s so cool to build all sorts of conditional stuff without having to code anything. The second one would be the latest Flow Builder. Me as a developer, doing stuff without having to code is fun. It’s not just for agencies and developers, but also for merchants using it. Those are some great key features of Shopware.

Brandon: Vlad, do you want to add anything from your side?

Vlad: Yep. Maybe the Shopware Frontends, which are robust systems that jump into the game. It’s pretty convenient if you’re a good developer at Next.js or Vue.js. You can create everything you want, even without a big knowledge of Shopware itself. I totally agree with Christian about Flow Builder because sometimes it can be very helpful. 

Christian: I also forgot to mention the Headless approach. Nowadays, it’s not just about having shops but ecosystems where Shopware is a part of it. The Headless options are remarkable.

Brandon: Amazing. I appreciate hearing about your experience and what you guys are working on. Christian, thanks for pointing out the Headless aspect because these commerce components are everywhere.

Let’s talk a bit about extensions from a business perspective. You guys probably think deeper than me, but there are business problems that Shopware doesn’t solve out of the box. What are some business problems that the available extensions solve today?

Christian: As an agency, we’re happy with the various ways to extend Shopware. I’ve worked on the Mollie plugins for a while. You can go to the merchant store, search for any cool plugin available as a subscription or for free, and install it without any knowledge of composer installations. The market for plugins is great for helping growing eCommerce businesses with almost out-of-the-box extension features.

Brandon: Vlad, what are your thoughts?

Vlad: Maybe I should mention the disadvantages of plugins and Apps published on the Shopware store. Sometimes, the Shopware team doesn’t have enough time to properly check extensions, leading to poorly developed ones that can’t be extended by agencies. For example, when I install an extension from the Shopware store, I expect it to work well, but sometimes it lacks necessary features or events for further extension. From this perspective, improving control and quality is essential.

Christian: That’s a good point. As an agency, we often face the decision of whether to go with a plugin from the store or build our own. We work mostly in the medium enterprise segment, and while the store part is great, the quality of plugins varies. I’m trying to improve quality standards and testing in the community because not every plugin works perfectly. And even if you invest a lot of time in doing high quality plugins it could just be that one single vertion that is a bit different, which is okay, but it happens and you just contest everythings.

Have you ever had a situation where a plugin didn’t work, and you had to develop your own solution?

Vlad: Yep, of course. As an agency, it’s pretty hard to communicate to a customer that a plugin is not so good because it reflects on Shopware’s quality. A lot of situations like this. 

We’ve seen a lot of improvement since the release of Shopware 6, and the core team is doing a much better job. Initially, it was possible to upload similar plugins with the same logic, but now there’s stricter control.

Christian: Have you experienced issues with Shopware updates and compatibility? The Shopware Apps should handle non-breaking changes through APIs and webhooks, but sometimes updates break custom developments. We’ve had to deal with such issues, and it’s challenging.

Vlad: Yes, we’ve had similar problems. I have decided sometime ago that plugins should be placed in the vendor folder and installed via Composer. So, as soon as we get an update, we just deactivate all plugins, then make the update, and it won’t affect anything. After that, one by one, or in batches, the plugins can be updated and activated. Sometimes it’s really annoying because you want to update and be sure that all plugins are compatible with the latest version. But sometimes, you try to update to the latest version, and not all plugins are compatible, which prevents you from updating the system normally.

Christian: That brings us back to the basic idea, especially in an agency doing enterprise shops. Whether to go with a plugin or not really depends. For example, payments — I would never do payments myself as a company because it’s risky and such an important part of the process.

When I started with payment plugin development, it was a bit scary. As soon as you learn about the numbers that run through that plugin, it gives you a different feeling when releasing it. But you get used to it and improve testing. 

But speaking of the third way of integration, the App system — if you’re a non-technical person coming from the Magento world, for example, Shopware also has a cloud option. If you’re hosting your shop in the cloud, you can’t install a plain plugin because of the PHP server-side scripts. If we were both on the same instance, I could mess up your shop. So, it has to be sandboxed because different merchants share the same instance. The problem now is you have a different plugin system, originally done by Shopware themselves. But as a plugin vendor, you also want to add plugins for SaaS or cloud customers. With the new App system, Shopware created one system that works for both cloud and on-premise customers. The idea is to have sandbox development where all your code is on your own server system. The PHP part isn’t in the Shopware system but on your external system. The main logic is handled elsewhere, and the integration is a small thin layer with some App scripts.

The cool thing is you don’t need to use PHP — you can use Go, C# or whatever language you prefer. This extends the number of companies that can do things for Shopware. If you have a bug, you can roll out an update, and every merchant immediately has the fixed version without manually clicking on update in the administration. But if you have a user bug, that might mean a horrible weekend.

Brandon: So, help me understand something, you guys. As a business user, you’ve talked about plugins, bundles, extensions, Apps, and themes. Are these the same or different? How are you using each of these different pieces? Christian, you mentioned starting points and what you’re doing versus not doing. Help a business user understand what’s what within this ecosystem.

Vlad: I suppose the difference is based on pros and cons of the approach. 

Basically, Theme is a plugin. The only thing which is different – Theme has an additional class, and that is all. Theme is only to extend the store front (frontend layer) according to Shopware recommendations. From a business perspective, in the admin of the shop, plugin and theme have the same installation cycle, but theme is placed in theme manager and plugin is placed in plugins. And if you have more than one shop – you can install different themes to different sales channels, when plugin you can install just globally.   

Christian: Okay then, let me summarize the different types of Shopware extensions for you. Speaking about business, let’s imagine you are a customer of mine, and you want me to help with your shop. The decision in this case is whether to go with a bundle, a real source code in the Symphony application, or with an App in that case.

The great thing about an App is that there’s always a trade-off, but with an App, there’s nothing you really need to consider because when you go with an App or plugin, you go on the extension from someone else. It’s up to them whether to provide a plugin, just an App, or both. In your business decision, you need to consider the Shopware plugin system. It’s been around for years, initially released with Shopware 6, so it’s quite mature and has many features if done correctly.

With the App system, it’s also kind of old but still relatively new compared to plugins. It has fewer features or options for developers. Shopware is adding many webhooks and functionalities, but it still has fewer options than the plugin system. If a vendor offers both a plugin and an App, you can expect the plugin to have more features, while the App might have fewer features. However, if a vendor is focusing on the App system, it may indicate they are transitioning to it, which allows them to fix bugs on their service, and it works immediately for you.

If you are a medium enterprise customer and ask me the best way to help you, I would probably prefer, depending on the plugins, to go with the bundle or source code way because it gives me, as a developer, more freedom to extend whatever you need, especially if you are on an on-premise system. If you’re using a cloud server, we would have to go with the App system, but it still provides options to customize the shop as required.

Lastly, you can combine both plugins and Apps. For instance, for payment solutions, I would go with a payment plugin or App if they are functional instead of creating one from scratch. These are the business decisions and potential risks you need to consider when choosing extensions.

Brandon: That’s perfect, right? Because there are so many pieces out there. And as I’m sure, you’ve got a developer audience out there listening to this as well, and I’m sure you’ve got some recommendations for them. But I appreciate you going back to the business side as well and saying, “Okay, these are the considerations.” Because, you know, when I’m working with clients or if I’m the client, having been the client in the past, I want to speak the right language. I want to know what you mean when you say something and why it’s important. So that’s an incredible thing. Thank you for going through the process and giving me a little insight into what’s what within Shopware.

I would say, for the rest of the conversation, tell us about what you guys are doing, whether it’s within the App system or a plugin. I know you’re working on lots of incredible things. We talked briefly at the start about some of them, but what are you working on and why? Why is that important? Just tell us a little bit about how you’re engaging within these systems.

Vlad: In our case right now, the main focus is social networks. We are developing Apps that will help shop owners to be notified about orders or order status mutations and so on. I suppose it will change the attitude towards the Flow Builder for specific events because, for small and medium shops, having a notification manager is really important. So, being notified via social networks is our main direction, and all of these are Apps.

Christian: I had an implementation in shops that moved on to plugins, and the latest thing is actually an App, that was the Mollie payments App. And we were speaking about Apps, what I did not mention, speaking to the developer audience, is that even though it’s a lot of work because you’re not just building a plugin that’s inside a shop instance, you’re building a completely new system. It really depends on what you try to achieve. It can be complex, but it’s so much fun.

I did the Mollie Apps and got back to testing — how to use end-to-end testing in pipelines to combine all these different containers so they communicate with each other automatically. It’s a more technical thing, but it’s so much fun — also, dev experience and dev setups. That’s what I did and also moved on to some kind of headless project. More later this year, but it tries to speed up how to use Shopware, compose, get data, and ensure it’s super fast in the end.

Nowadays, it’s not only about having an ERP system and a shop; it’s the whole infrastructure you’re trying to achieve as a manufacturer or online shop. That’s one thing. And the rest, I’m just doing a lot of open-source stuff, which will probably never end.

Brandon: I’m glad you are. We need people doing that, so that’s amazing.

Vlad: Maybe one thing to add, you know, as soon as you are an App developer, you should be aware of the responsibility for security. From this point, you are responsible for the security and maybe you won’t be only an App developer but also a DevOps.

Christian: That’s so good that you mentioned this. With creating Apps or SaaS systems, you really need to dig deeper into things like vulnerability assessments and threat modeling. As a pure plugin developer, you never needed that, but now it’s crucial. Sometimes people do not expect that situation to occur.

Another thing with the Shopware App system is that you have the plugin configuration fetched based on an iframe Vue.js application from an external server. It looks native but one thing you need to ensure is that the whole request-response communication is done with handshakes and secure signature stuff. If you have your own application being fetched as an iframe and you have AJAX calls in there, that’s not Shopware anymore — that’s your application.

Brandon: Great advice! It’s becoming more important as we go. I think you guys have given some great advice here for developers as they look to develop their own Apps and extend Shopware in different ways.

From a merchant or business user’s perspective, kind of from the outside looking in, what should a business user be looking at to help determine whether this extension is worth it or might provide vulnerabilities? What makes a good extension from a business user’s perspective? How can we spot the challenges or vulnerabilities that might be out there? I’m sure we can reach out to guys like you to help figure that out, but are there any other signs we can look for?

Vlad: The company name.

Christian: Reviews on the store help a lot. There’s just no chance — if there’s a huge security problem, someone out there is always better than you. The only thing you have is to see the company name and if it is well-known or if the reviews are good. Also, speaking about testing, one of the main things is that there are always bugs in the source code because we are all human beings. That means, you can use the best App and it will have security problems there somehow.  

Vlad: And this is not only a business side problem but also a developer side problem. As soon as a client asks to install the application for the store, it can be tricky because you’re not able to see the source code. What you see, in fact, is only one XML file where all webhooks are declared, and that’s all. It doesn’t matter if you’re a business owner, Christian, or another developer; we cannot guarantee that this App will work properly and be secure. The good thing is Shopware is testing and validating the Apps and plugins in the Shopware store. 

Brandon: Right, that’s really good.

I mean, they’re trying to keep that App ecosystem as healthy as possible. Every day, vulnerabilities come up, and there are different and unique ways people go about exploiting them. You’re never completely secure, so you always have to be on edge, watching and making sure you take action. 

My approach is easy, though, and not everybody gets to do this. I just send it to Vlad and ask, “What’s up with this? Tell me the good, bad, and ugly.” Not everybody has a Vlad, okay? So, that’s what I do.

Well, let me ask you this then. With all the things we’ve talked about today, let’s put our developer hat on first and then our business user hat. From a development perspective, if you’re a developer looking at Shopware, looking to extend it, and wondering if Shopware is a platform worth investing time and effort into, any advice for that person? Any excitement about what you’re seeing? Here in the United States, a lot of developers and merchants are starting to take notice of Shopware. I want them to understand how to extend Shopware in a better way and the reasons to do so. Anything come to mind?

Vlad: Okay, from a dev side, if you’re a PHP developer with strong knowledge of Symfony, you can go with bundles and Apps, of course. My recommendation for all developers is to check all options. I’m a big fan of plugins. I was a developer for Shopware 5, and I can’t say plugins are outdated or old-fashioned. No, I wouldn’t say that. If you’re a Symfony developer, look at bundles and Apps. If you work with C#, Go, Node.js, or other languages, of course, it’s Apps. As a Shopware developer, you should check plugins as well.

Christian: I would love to add that my fascination with Shopware comes from its use of the latest technology. Although I always wait a couple of weeks to see if something new becomes deprecated, the cool thing with Shopware is that they use the latest technology and latest approaches. We were just talking about Shopware composing with front ends, the App system, Vue.js, and pure Symfony. Compared to other applications, especially in the PHP world, Shopware gives you the feeling of working with state-of-the-art technology, even though it’s just PHP. The architecture, compared to Shopware 5, is so good. It’s well thought out by the Shopware core developers. It’s pure fun, and I think that’s what we as developers aim for when working with a platform. Sometimes we don’t care about the results; we care about the coding, and that’s just brilliant with Shopware.

Brandon: That’s awesome. I had the opportunity to ask Vlad about that the other day, and that was his approach too. He said the technology is so great and up to date, and no one else is doing that. I love it. Vlad, you were going to say something?

Vlad: Yeah, from this point, you can tell everybody that you are a Shopware developer because you can develop in any language you want. It doesn’t matter which language you select for development; you can say, “I am a Shopware developer.” Even if you don’t know it, it takes just 10-15 minutes to understand the logic of an App, and that’s magic. Shopware changes the rules in the ecommerce industry.

Brandon: Honestly, that’s huge, Vlad. I didn’t realize that. Coming into this podcast today, the ability to use all those languages and focus on what you’re good at is remarkable. I had a similar experience with my own store many years ago. We were using Magento, which is all PHP. My developer was building a Python script for something we needed, and it threw me off a bit. But knowing that you can leverage whatever technologies and languages to achieve your goal is pretty significant. 

Alright, from a merchant’s perspective, why should a merchant look at Shopware today?

Christian: If you compare what is happening with other platforms to Shopware, you see a clear aim to stay at the forefront of technology. Shopware was one of the first to integrate artificial intelligence options into the core system. They have what they call an “Innovations Lane,” a task force of people focusing on the next big things in e-commerce. This approach shows that Shopware is not just building a product but trying to build and improve the future of e-commerce.

As Vlad mentioned earlier, deciding which plugin to use often depends on how the company operates. If you look at Shopware, it looks good, feels good, and is continually improving. Although it has bugs, it’s not the same as Shopware 5, but it shouldn’t be. Shopware 6, especially with its Headless first approach, aims to give developers and agencies the power to build an entire e-commerce infrastructure. Shopware 5 had everything in the box, which might not always be the best approach. Shopware 6 focuses on having a robust core and providing the flexibility to build whatever you want. That’s what I would tell a merchant considering Shopware.

Vlad: Let’s add two more aspects. The first, is if you are trying to understand whether you want to go with Shopware or not, just check the investors.

The second point is to consider the perspective of shop owners. Shopware 6 was released after Magento 2, Shopify, and other platforms. So, all the people working on Shopware are quite clever. They had the opportunity to gather information about other e-commerce systems, combine ideas, investigate what works in other systems, and only after that was Shopware 6 released and developed.

Brandon: That’s a great point. They have the learnings from all those platforms and merchants. For me, as a non-techie, the easiest example is the flexibility with headless. You don’t have to choose just headless or just Shopware; you can have multiple types of storefronts and checkouts in different places. That’s unique and valuable.

I just want to say thanks to both of you. Developers listening have a great opportunity to see how they can work on extending the platform. Merchants can see the interesting things they can do with Shopware. I think agencies might also see this as a good time to invest. Any parting words of advice for anyone out there before we sign off?

Christian: Just go out there and give it a try. Make your fingers dirty, have fun as a developer or merchant.

Vlad: Be part of the Shopware team!

Brandon: Thank you so much, and thanks to all those who tuned in and stayed with us. Hopefully, something here sparked some interest and gets you headed in fun directions. At least, it should give you a better understanding of Shopware and how awesome both of these guys are. Leverage their experience because there’s a lot of it. Thanks, gentlemen!

Christian: Perfect, thanks for having me!

Vlad: Bye-bye!