This talk is a guided tour through the years, in which I have found back my passion for programming. The main trend in this was stepping out of my comfort zone, learning new programming languages and working with all sorts of frameworks and technologies. After having worked with WordPress exclusively for close to a decade, I’ve spent close to three years trying to get away from WordPress as much as I could. In this talk, I will share the things I have learned, how it actually made me a better (WordPress) developer and provide you with the tools and tricks to do the same.
If you are in the fortunate position, where your code is running on millions of websites, in my humble opinion it would be really silly to not follow what Danny has been doing here to reduce the carbon footprint of each website your code runs on:
It’s time to get my Lapisense project off the shelf. It has been sitting idle for far too long. The layer of dust on top of the box has become so thick, it needed a good cleaning before I could start working on it. This was a hard process, which required a lot of soul searching, trying to determine what I really wanted to do.
In the end, the reason why the project never came alive, all came down to a lack of perseverance. I had so many ideas, but never properly sat down to spend enough time coding up enough features to release it. Having so many ideas lead me into a never ending loop between wondering what would be the best approach, ultimately leading to nothing actually happening. Over on the Lapisense blog, I have written about this whole process in more detail.
For me to get moving, I needed a fresh approach. I took the box labeled ‘Lapisense’ off the shelf and gave it a proper dusting. While determining what the best way to move forward was going to be, I had an epiphany that my ideas aren’t mutually exclusive. What this project needed, was a phased approach. Getting something out in the world now is more important than covering every single use case on the first try.
I really needed to learn this lesson the hard way, ending up with a broken project for far too long. Onwards and upwards! 🚀
Now that Mozart is gaining more momentum and Composer is more commonly being used by WordPress plugin developers, I get asked this question more often. With popular tools like PHP-Scoper also being used in the WordPress ecosystem, I figured it was time to explain why I felt there was a need for another tool that does a similar job.
It’s been a while since I’ve written about what I personally find the single most annoying thing in WordPress, the issues around dependency management. When I started thinking about the project that eventually turned into the Mozart package, I knew that it eventually had to support processing of a full dependency tree. Today is the day that I can proudly announce that Mozart is able to do that!
Version 0.3.0 is now available and introduces full dependency tree processing as the number one new feature. Mozart now automatically detects the full dependency tree of the packages you specify and processes the entire dependency tree.
Even though I know that a couple plugins already use Mozart in production code (mind you, Mozart doesn’t run in production, it’s a development tool), I’d still like some more testing feedback before I tag the first production ready version. So if you have a plugin that requires an external package as a dependency, that you’d like to be rewritten to your own namespace in order to prevent version conflicts, give it a go!
Wow, this is actually my first post written with the new Gutenberg editor that recently shipped with WordPress 5.0. I have done some testing with the betas and release candidates and have often criticised the lack of opt-in for users and eventually the seemingly rushed release schedule to get it out the door before WordCamp US… That was all about the logistics though, I do like the new editor.
Now that WordPress 5.0 is released and Gutenberg is the new default editor, it’s time to embrace the new editor. I’m sure there are a lot of reasons why people shouldn’t immediately upgrade just yet. This can be either because of plugins or themes not being compatible yet, or the people working on the site aren’t ready to start using a whole new editor. That just takes time and we should give everyone time.
Accidentally committing sensitive information to a GitHub repository can have costly effects. This tweet of someone committing their AWS private keys in an .env file by accident, surfaced only a couple days ago. I’m sure something like this has happened to so many people already. It’s easy to commit a file that you do wish to remain private, simply forgetting to add it to your .gitignore file. Continue reading “Use a global .gitignore file to ignore commonly ignored files”
A quick and easy way to decouple your code from WordPress logic, is by using repositories. Repositories are standardized ways to get and put data in a data store, usually databases. WordPress introduces a couple functions to interact with various database tables (get_post_meta(), get_option(), etc.) that are commonly used inside plugin and theme files, that are cumbersome to mock while testing. Repositories on the other hand are very easy to mock in unit tests. Continue reading “Decouple from WordPress databases by using repositories”
It’s common practice in the larger PHP world, but something the WordPress ecosystem has yet to catch up on. All too often, I see WordPress plugins and themes setup actions, filters and use other WordPress specific functions in class constructors. This leads to a class that is directly coupled to WordPress logic. Continue reading “Class constructors should only setup the object”
A lot has been already said about Gutenberg and whether it should be included in WordPress core. How should it behave once it is included? Should it be the new editor for new sites only? Should it be an option that users can enable, or should it be on by default and give the option to disable it?