On the other hand, I’m one for meta-games, especially when I have doubts whether I stand a chance in the game itself, thus came the idea of do something around 100DaysToOffload that might also result in a blogpost. Hence came the “Hundred Days to Offload” WordPress Plugin idea: get a bit of coding in, make something useful to see if the game has been “won”, an also get one (or more) write-ups out of it.

Spoiler alert: it’s working now, very barebones, but to the point… that there’s a long way to go.

In the process, that took a couple of days over the weekend, I’ve revisited PHP, that I used to “play” with for projects before, though haven’t done anything serious, nor made it part of my Language of the Month series, so far. It was still quite interesting to revisit with more mature eyes of e.g. how good projects look like in the Python ecosystem (where I spend most of my time), and whether lessons learned there are applicable here.

The Making of a WordPress Plugin

The plugin itself is pretty straightforward: query WordPress for all the post that were published in the last 1 year, and count them. It could be slightly more complicated, if the goal would be more closely aligned to the “100 days to offload” name, that is if one would have to count the number of unique days on which posts were made, but let’s not move the goal-posts here.

Starting from the relevant WordPress Handbook page I could have an initial stab at laying out a plugin project structure, though I have to say, that the examples are not going too far in helping with that. This was augmented by a GitHub wordpress-plugin topic search, where I could work from examples a lot better, and see some (maybe too many) best (or at least reasonable) practices.

This lead me to various ecosystem tooling such as

• Composer, the PHP dependency manager that I didn’t know before, and could very much relate to (with it’s prod/dev dependencies, scripts definitions, etc, reminding me of Poetry for Python a bit in spirit)
• PHPStan static analysis tool, and its “fun times” with WordPress code (which can be fixed by various stub projects, etc),
• all the “code standards” tools that do various fixes (while not being quite a linter and code formatted, but still being a little), for example wpcs. This latter had a fun side effect that have to work from its cutting edge “develop” branch to work with PHP 8.1 that I had at hand, so definitely learned through that a few Composer quirks.

In the end I had my little snippet of code, run through all these codes, fixed up tabs vs spaces, docs strings, types for return values, dependencies, actual bugs of wrong input types to various PHP functions, and also some best practices (which might or might not apply to my little code). It’s a rabbit hole that could go a lot deeper, though, so cutting a release version at a point. The rest goes into an issue tracker to pick up one day.

And now, with an MVP (minimum viable plugin;) at hand, I’ve submitted for review. That’s just the cherry on the top, or start of new problems with a project to support. Either way I can use the plugin checked out with git just fine.

I’ve definitely picked up a tiny bit of PHP for now, even if mostly accidentally, and likely full of bugs and bad practices. It’s still interesting, and a learning experience. For example data handling is a source of many, various pains in all languages I’ve across so far. The PHP way (or WordPress way?) of object orientation is also just scratched on the surface and accepted as it goes, but not from a point of solid understanding.

Looking to the future

From the plugin’s side it would be good to add some style and looks, as it’s super dummy and bare bones. But how should it look? Time to learn a bit of design and/or run some user testing? The mixing of HTML and code is also particularly mind-bending (or awkward, or intriguing, or…), I would need to look where to set the right boundaries for that, as there could be many.

Adding CI/CD as well, so definitely various PHP versions can be tested (seems easy), and potentially various WordPress versions as well (seems a lot more hairy) could be a practice and baseline.

Adding some settings to change would help me to learn more plugin development, though this particular plugin might not benefit a lot from it.

Work out how to do proper translations / i18n would be probably pretty solid benefit as well, and that needs a lot more digging (variable texts are not straightforward to translate).

Finally, all of these improvements might also just make a few extra blogposts to get towards my 100 Days to Offload.

The post 100 Days to Offload WordPress Plugin appeared first on ClickedyClick.