When we introduced our chapters as part of our circle based structure, we had the idea to publicly announce what our chapters are doing, what technologies they are using and how they are working. When it came to the tooling decision, Docusaurus came up pretty quickly as it comes with multiple features that fit our technology stack out-of-the-box:
Since 2013 we have been using Silverstripe and the Silverstripe blog module as our blogging engine. After all those years, it is time to revisit and improve our toolchain as our requirements have changed over the years.
We decided to settle with Docusaurus for now. We'll share the "why" in one of our next blog posts, so stay tuned ;)
A few weeks ago, whilst applying the latest security patches for Magento, I ran into a problem in our build pipeline. The patches could be applied locally without any issues, but in our build pipeline applying the patches failed.
After migrating our old LDAP Server to a new instance, we realized that the EntryUUID attribute had changed. One of our internal applications relies on that attribute so we had to modify it to not break things.
Whilst configuring our Office 365 tenant via Powershell, one command failed with a server error. It did not spit out an error code or message, just a generic error message. After trying a few workarounds, I thought, I'd better check if my user has all the permissions needed.
For a few internal applications, we manage downstream forks with some customizations tailored to our needs. We try to contribute as many changes to upstream as possible, but for some cases, this does not make sense, e.g. when we customize user synchronization processes.
According to Microsoft Windows Hello is a "more personal, more secure way to get instant access to your Windows 10 devices using a PIN, facial recognition, or fingerprint". Wouldn't it be cool to use it to authenticate sudo via face recognition, fingerprint authentication, or a machine-local PIN? Luckily there's a PAM module that does exactly that and it is working perfectly for me so far.
A while ago a merchant notified us that it was not possible anymore to edit categories in Magento. In the Magento logs, I found several similar error messages:
A while ago we took over a Magento 1 shop that was migrated over to Magento 2. Some products and categories has a “.html.html” url postfix and the merchant wanted to have this fixed. When data was migrated from Magento 1 shop, the url keys came with ".html" suffix. On Magento 2, you have url_key and url_path attributes that help creating the urls for products and categories. Since the url_key attribute contained the “.html” postfix and url_path appended an additional “.html” postfix, the source of the problem was found.
Simply put, error 1062 is caused when MySQL finds a DUPLICATE of a row you are trying to insert. I sometimes hit this error when importing database dumps of applications that have been in production for a long time. The “fix” is easy: Find the duplicate data and delete it. Depending on your database structure it might not be that easy though. I that case, I configure MySQL to ignore those errors, for local development I find that approach acceptable. For dockerized setups, you can pass a “sql_mode” flag to the container which then will be interpreted by the MySQL server during startup. The docker-compose configuration that works for me looks like this: