Logging-Extension for Shopware 6
Ready-made extensions from the Shopware Store
You can definitely find extensions in the Shopware store that are designed to make this functionality available, and we tested one of these extensions in a customer project. We quickly encountered problems and decided against using the extension. Nevertheless, it should be mentioned that the tested extension is certainly well suited for many use cases. However, this solution could not meet our requirements for the following three reasons:
- The initial reason for us to think a bit more about logging was a misuse, where an extension was accidentally disabled in the backend. This resulted in errors that took a lot of time to fix because the deactivation of the extension was not immediately detected. A meaningful log would have saved us a lot of time at this point. However, the extension we selected would not have recorded this event in the log either. When we asked the manufacturer, they could not tell us whether the feature would be implemented in the near future. With this, it was actually already clear that this extension would not bring us any further, however, the two other reasons that speak against this solution should also be mentioned.
- In the Shopware backend, no distinction is made between changes made by real users and API accesses. Since we use a middleware in the affected customer project that updates product data multiple times every hour, this led to an enormous growth of the log in a very short time. We are talking about more than 1 million log entries in a few days. The sheer volume of data thus makes the logfile generated by the extension difficult for us to handle.
- The extension does not write the events to a logfile, but to the database. This is to make the changes directly viewable in the backend. In our case, however, this would expose the database to an enormous additional load.
We write the extension ourselves
In the end, for the reasons mentioned above, we decided to program our own Shopware extension that meets our requirements. In the first step, we made sure that activities in the extension module are written to the log file. This logs all possible events related to Shopware extensions, including their installation and uninstallation, as well as their activation and deactivation. Also the execution of updates of extensions or themes is covered by our logging extension. A distinction is made whether the event is triggered via the Symfony Console or by an administrator in the Shopware backend. In the second case, information about the responsible user is also captured.
In the second step, we added the primary activities from the Shopware experiences to the log. Here, the extension is triggered by the "EntityWrittenEvent" and "EntityDeletedEvent" event. At this point, the creation, editing and/or deletion of pages, blocks or slots (elements in blocks) are logged. In our use case, it is particularly important that the active language in the frontend is also logged when a change is made, as experience has shown that the potential for errors is particularly high here.
Last but not least, we built the logging extension so that all entries are written to log files. We can then easily read these log files into our analysis tools and process them further.
We deliberately designed the extension's architecture to be open, so that an extension for new use cases is possible at any time.
Learn more
On our website you will find a compact summary of all relevant features and benefits of this individual development: Why is a complete, yet differentiated logging useful for every store operator and what concrete advantages does our logging extension have compared to the standard Shopware 6 solution? We have summarized everything worth knowing for you in our article on the Shopware 6 logging extension.
If you would like to learn more about this Shopware extension or about our services around the Shopware software, please feel free to contact us.
Please feel free to share this article.
Comments
No comments yet.