On this website, I present all the open source plugins for WordPress that I have published. I am aware that this is a large number - and also a challenge, as each plugin should also have the same quality in terms of its functions, security and sustainability. I will briefly describe here how I ensure this sustainability.
My principle
Everything has to have a reason, and you can find it.
That's why I often take a very close look at how something works before I release it to users. This sounds very time-consuming, but in my opinion it leads to enormous stability of the plugins, which is also reflected in very few support requests for the plugins.
At the same time, I've also learned a lot about the WordPress core and countless other plugins - how things work and how they shouldn't be done.
Code quality
So that I can still understand my own code even years later, I comment very diligently. I have gotten into the habit of commenting almost every line, mostly in US-American English. There are files that consist of 2/3 comments only - but that is quality for me. A chunk of code thrown down without any human sentence, as you unfortunately see in many other plugins, takes more time to be understood.
Use of AI
I use the PHPStorm IDE for development and the code autocompletion function it contains, as well as the AI, which is also included, to optimize code from time to time. I also use Claude or Copilot from time to time to solve tricky things more quickly. However, I never let the AI write my code. If I do, I copy part of the code it suggests, adapt it and comment on it. Or I talk to the AI like a human colleague to find a solution without adopting what the AI suggests 1:1.
Security
There are a lot of things you should pay attention to when developing a website. Security is a very high priority for me. Unfortunately, I come across far too many hacked websites in my support in the WordPress forums and also in my professional environment.
For this reason, every function that I add to my plugins is also considered holistically: its structure, its effect and its availability, both while you are logged in and as a visitor without login and also all interfaces that WordPress still offers (REST API, WP CLI ..).
Tests before each release
A new version of each plugin is only released if it passes the following tests successfully and without exception:
- Comply with WordPress coding standards by checking with their composer Package.
- Fulfillment of the tests of the WordPress Plugin Check Action (corresponds to the check by the WordPress plugin team for each new upload in the repository).
- Completion of a scan with PHPStan with regard to possible bugs at level 8 out of 10 (unfortunately, WordPress as of 2026 does not yet go higher within a reasonable range).
Only a few plugins must also fulfill the following requirements:
- A series of individual PHPPHP PHP is a scripting language with a syntax based on C and Perl, which is mainly used to create dynamic websites or web applications. https://de.wikipedia.org/wiki/PHP Unit tests, which test specific sequences of functions within the plugins that must be fulfilled in every case.
- A test with the composercomposer application-oriented package manager for PHP Package from PHPCompatibility with WordPress specifics.
The path to a release
I test every single function that I add to the plugins in at least 2 local test systems. I then create a local release (usually with ant) and also test the new function in a test system. With GitHubGitHub Software development platform I then create a new release and run the checks there again. Only then does the release follow in the WordPress repository via SVN.
But that's not the end either: as soon as the release is published, I will test the installation of the new version from the WordPress repository in a test system again to make sure that nothing went wrong during the transfer via SVN.
Quite a lot, isn't it? Yes, and now also largely automated.
To err is human
Software is only as secure as it was written. Mistakes can happen, and you have to accept that.
If someone does get in touch with me with a technical problem relating to my plugins, I want to know exactly how it happened. Not only because it is strange when the problem occurs with one of hundreds of users, but also because I like to get to the bottom of the problem - finding the cause and making further optimizations is an inner urge that I find hard to resist. Ultimately, however, finding a solution also fulfills the wishes of the user who reported the problem.
Fit for the future
For me, it is just as important that my plugins work as they should in the latest WordPress version. That's why I sit down before major WordPress releases and test every plugin with the first release candidate. In this way, I want to ensure that the plugins can also be used in the future.
Cooperation
Only very few developers have contacted me so far to make additions to my plugins. You are also welcome to get in touch if you have an idea and a proposal for implementation. Please note that every addition must fulfill the above-mentioned checks as well as the code quality I require.
You can find the sources of all my plugins on GitHub: https://github.com/threadi
Use
I hope this article encourages you to use one of my plugins. If you have any questions, please feel free to contact the relevant support forumsupport forum Forum for users of each plugin to ask questions and get help.
Leave a Reply