In this short blog post, I will show you how you can use shopware-cli to build your Shopware project and deploy it later with Deployer, Docker image whatever you want. But first what is Shopware-CLI? Shopware-CLI is a command line application written in Go. It’s not the same application as bin/console in your Project. It’s kinda a Swiss knife for the Shopware ecosystem. Likewise, it can do a lot of things like: ...
When you deliver your Shopware extension to a Shop owner, your extension must contain in src/Resources/public the build assets for the Administration and the Storefront. We committed in the first plugins in Frosh all assets directly in Git. But this led to annoying conflicts, or when you merged two pull requests at once, it didn’t contain both changes. So, for this reason, we removed the build files from all Git repositories again and used shopware-cli to build the files. ...
Shopware Apps are a different way to extend Shopware and can use an optional external App Server to provide additional functionality from your external backend. In this Blog post, I want to show you that a Shopware App with a Backend can be easy and also very affordable. The scary backend server Before the App system, the only way to extend Shopware was to build a plugin. Plugins are like Symfony Bundles with Shopware magic to offer them in Shopware Store. So we wrote code that runs directly in the customer’s web shop, and we can create additional tables to store our information. But we have to make sure that our code works on many setups and PHP versions. As the plugins can do like anything and this makes sandboxing difficult or build reliable that they don’t break each other. That was when the Shopware app system was born to offer a different extension concept. ...
With the Shopware version 6.4.11.0, we improved the performance overall a lot. To make sure that we still improve, we decided to set up a nightly load testing job to ensure that the application performance stays the same. So we have running since a month an automated load test for Shopware 6 running, and in this post, I want to speak about it. To test the Shopware, we use multiple dedicated Cloud Servers from Hetzner Cloud and wrote some custom tooling around Ansible to spawn the servers before. ...
Last week I attended the first Hockethon (combination of Hackathon + Hockenheim) of the Kellerkinder. That event was unique, and I want to thank Kellerkinder for organizing such an event. If you are interested in what we all did on that event, check out the blog post from Marco I teamed up with Manuel we made pretty fast progress to enable HTTP caching in the store-API. As the Storefront already has HTTP caching, we used the same logic. But in the end, we had a reference in the Core store-API to the HTTP cache of the storefront bundle. So to do it right, we had to extract the HTTP cache logic of Storefront into the core component. While migrating code between two components, we thought this task is so brain-dead, so let’s use Rector to do this for us. ...
In this blog post, I want to dive into the Shopware Caching to clarify how it works and what you have to care about while developing features. We will go from the inner to the outer caching layer in multiple steps and look into them independently. Stage one - the object cache First, we will start with the object cache implemented in serval “route” classes. The “route” classes/controllers are always used in the Shopware context as an entry point for the store-API. These are controllers and services simultaneously, so the default storefront and the store-API can share the same code. ...
I switched a month ago to macOS as of the M1 hype and wanted to try out the entire Apple ecosystem when I have an iPhone, iPad, and Mac. To get Shopware 6 running, I looked into some Guides for Mac and found out for myself: Why is this all so complicated, and why the hell is anyone using Docker for that. Docker on Mac I saw that many people are using Dockware for their Setup. (Dockware is a Docker image with all the Tools/Servers included to run Shopware 6). Docker runs not native on macOS and uses a Virtual machine to emulate a Linux kernel and all the containers below it. So obviously, the filesystem would be slow, and many people using, for this reason, SFTP or other tools like docker-sync to hold the same state between host and container. This is one of the most significant disadvantages for me. Like me, the dumb user has to run a tool to have this synchronized. I know that tools like PhpStorm can do this for me automatically, but when it doesn’t work, I will waste so much time to find this out. ...
Today is finally the day when Shopware packages is being released. You might ask what is Shopware packages, and what does it have to do with packages.friendsofshopware.com? Good question 🙂 What is Shopware packages? Shopware packages is the long-awaited official Composer package repository for all Shopware store extensions. But why do we want to use that or care about that? What can I expect from Shopware packages? With composer, we can manage all dependencies in our Shopware setups. We usually use a composer project template which requires Shopware and provides some basic tooling. When we want now update the Shopware version, we just pick a newer version of Shopware in composer, and we are ready to go. That’s nice and easy for our Shopware upgrades, but we mostly also use extensions for our shops such as PayPal. Typically, we download the ZIP-file from the Store, unpack and upload it to custom/plugins. Yes, we all are lazy and this really sounds annoying. With the new repository, we can treat the extensions as normal composer dependency like just using composer req store.shopware.com/swagpaypal like cool guys 😎. This will automatically get the most recent version compatible to our Shopware version and other requirements set by the extension manufacturer. Since the dependencies are built directly into Composer, we can use typical commands like composer update store.shopware.com/swagpaypal to update the extension or even update Shopware and all required extensions at once. It’s cool, isn’t it? ...
Every shop owner wants a fast online shop with the best pagespeed results. The images have a huge impact on these stats. But can we achieve better results with only PHP? Image generation with PHP In PHP there are two ways how images can be generated: using the gd, or the ImageMagick extension. Both extensions are not optimized to create very small images and they are quite slow. They also lack support for newer image formats like avif (PHP 8.1 will have avif in gd). The PHP community has build packages (like spatie/image-optimizer) to optimize an image after it has been uploaded by executing several optimziers in the CLI. This approach requires to have functions like exec, system or proc_open available, which are disabled by default on some shared hosters. Also, the optimizers need to be installed on the host system. But there are new technologies like ffi or wasm available in PHP. ...
Every developer who has created a plugin has already created a Symfony bundle. All Shopware plugins are extending from a Shopware bundle class which extends from the Symfony bundle. You might now ask yourself: when plugins are bundles, why did you write this blog post? First, let’s list the differences of a plugin and the two types of bundles: Feature Plugin Shopware Bundle Symfony Bundle modifying Shopware ✔️ ✔️ ✔️ can have migrations ✔️ ✔️ ❌ can be a theme ✔️ ✔️ ❌ can modify admin / storefront with js/css ✔️ ✔️ ❌ can be installed, uninstalled (lifecyle) ✔️ ❌ ❌ can be managed by the shop owner in administration ✔️ ❌ ❌ The benefits of working with a Bundle Having less features is sometimes better. As an agency, you don’t want the shop owner to manage your custom built extensions. The lifecycle of plugins is intended mostly for store distribution and often irrelevant in a custom built environment. When you make changes to a project, you want your code to be active always, regardless of the state of the shop. This makes Shopware updates smoother as well, as the upgrade process runs without plugins your code will still run. This solves theme compile issues during update process, e.g. The loading order of the bundles can be fix configured in the config/bundles.php file to fix bundle dependency issues. Also you could store the entire code in the template of the Shopware 6 project. ...