Ever so often, I felt I finally saw the light at the end of the tunnel of my learning session, only to hit the next obstacle. But let's sum up what seems to be left to do and sum up my achievements in coding a Shopware 6 plugin as a side-project so far.

I have been developing a back-end API plugin for Shopware 6 for my former employer back in 2020, partially based on trial and error and advice from the helpful community.

Side projects and tutorial hell vs. paid projects

After focusing on front-end development when I quit my job to become self-employed, I started various side-projects to deepen my knowledge, both as a full-stack developer using TypeScript, Preact, and MongoDB, as well as revisiting PHP-based back-end development to get a proper understanding and prepare for an exam to get certified as an official Shopware developer.

Having overcome the challenge of installing a development platform on localhost, things have been going quite well, and I followed the greater part of the developer tutorial successfully, all the more taken aback by the fact that some of the seemingly simple details turned out to be the biggest obstacles.

Inconsistencies vs. the harmony of Symfony

After fixing the relatively easy steps, like using translations, setting a twig variable to avoid redundant paths and improve readability, I returned to some problems that kept bothering me. Besides actual bugs, some parts of the code are hard to memorize as long as they appear to be in a random order, following an inconsistent, arbitrary syntax instead of making sense and fitting into the large picture. I know that I probably shouldn't say this about back-end development as someone who loves to code in CSS, but I hope that one day I will see the harmony of Symfony as well.

Inconsistent naming: capitalization, plural, cases

Sometimes the mixture of capitalization and cases helps to memorize where we are currently working in the project. The PHP / Symfony parts seem to be the most consistent, using capitalized first letters, singular form and camel case mostly, like
src/Storefront/Subscriber/FooterSubscriber.php

while the storefront resources get more inconsistent. Capitalization ends after the first level of sub-directories, e.g. it's src/Resources/anything/below/is/not/capitalized, but there is no comprehensive rule when to use singular or plural, so we have src/Resources/snippet vs. src/Resources/views although both directories usually contain more than one file.

So all of that stays annoyingly inconsistent, but at least it's consistent with the original framework(s) (Symfony, Shopware) that we want to extend. And again, just like CSS and spoken languages, programming languages and frameworks have evolved over time, and it takes time and practice to learn how to use them properly.

Logging an exception causes an ErrorException

This is a hard one, a problem that I already encountered, skipped, and worked around earlier many months ago: Trying to log errors or info messages. The common practice would be something like $this->logger->info("Message") (much like we would use console.log("message") in our front-end JavaScript code).

What a pity that it simply does not work in my custom plugin, maybe not even anywhere in my local Shopware installation. Worse still, this one seems impossible to google! Searching for my error message ("ErrorException: Notice: Undefined property: Storefront\Subscriber\FooterSubscriber::$logger") in various variations either produce results omitting the relevant search terms or else stating that "it looks like there aren't many great matches" for my search. You don't say! I have already wasted a lot of time and still fail to understand how I seem to be the only person on this planet to run into this kind of problem. And it's not the first time either that I thought "I really enjoy life-long learning, but..."

I suspect that this is another example of "I closely followed every aspect of a tutorial, but my code is not working," instead of just getting inspired by tutorials without stopping to use my own brain.

Keeping a local dev installation up to date

This brings me to another issue: how to make sure that my local installation is up to date? Maybe there are bugs in the framework that have been fixed already. Unlikely that's what's causing my current errors, but it doesn't help to check anyway.

According to my admin dashboard, I am using "6.4.9999999.9999999-dev", which is always greater and seemingly "newer" than the latest current stable "6.4.x" release, so there must be another way to update - hopefully without breaking the working system - probably pulling the latest changes from git and rebuilding the framework, and that should have been obvious from the docs, but obviously it wasn't, and I forgot, getting so desperate, confused and "lazy" that I have to seek guidance and assistance and ask another question in the community chat.

Meanwhile, I could try my luck with one of the other leftover embarrassments like the system config service not working properly.

Fix reading Shopware's SystemConfigService

It can't hurt to make our code so verbose that it starts to look like Java: there are 10 occurrences of "SystemConfigService" in my class file, only to look up one (1) setting in my plugin configuration once! But that would be fine for me if it would work - only it doesn't!

It's not the first time that I use the logger or the system config service, so what is going on here?

I will probably tell you in the next part of my shameless revelations about feeling clueless learning in public, so stay tuned!