Blog items

When using automated tools to improve code quality, it sometimes happens that warnings are shown while the code is correct or hard to fix. Depending on your setup, this warning can prevent committing your code or setting up a test/acceptance environment.

To improve the editing experience for content creators, you often want to alter the styling for the form that is used to create and edit nodes. These forms use the node-edit-form.html.twig template to generate the HTML, and no extra theme suggestions are provided by Drupal natively.

I have to admit something, and it's a bit weird for a programmer to say, but I like comments. And I like them a lot, really a lot. If I'm frank, I love them even more than code. So, now that I've said that, I do feel relieved.

A default value can be set for fields that are attached to a content type (i.e., any field-able entity). The entered value is used to pre-fill the form (i.e., entity) when creating new content. Although having a static starting value is often perfectly fine, true power comes when these values can be set dynamically.

As a developer, I strive to deliver high-quality code that is understandable for other developers and is as future proof as it can be. For me, this is an ongoing learning process in the way code is written, and tools that can be used to assist me. Many different sources can be found with opinionated instructions on how to write "perfect" code.

By now, every Drupal developer should know that it's a bad idea to overwrite core and contributed code. Especially when using Composer correctly and, therefore, only store the composer.lock file to the version control system. It should be imminent that changing files containing core code is a no-brainer (don't hack core!).