Strata Reaches End of Life
After years of having been largely ignored, I am archiving the Strata project.
Even though I know for a fact that nobody is using the library from looking at its Packagist install statistics, it is now official that you should not consider it to build your next project.
The reasons for the deprecation are twofold:
- I have not been in a position where I have to make Wordpress behave like a CMS for a while now.
- I have no interest in maintaining a project that found no traction in the community.
Things are still pretty bad though
While I no longer wish to modernize PHP and Wordpress, it doesn’t mean they have no room for improvement. Nothing has changed regarding Wordpress’s technical implementation in these last years.
Let’s move on
Nowadays I don’t recommend Wordpress for anything. I never really did, to be honest, but now I have the luxury of not having to use it… and I feel sorry for those who must.
I find the blogging tool to be a poorly implemented solution using legacy coding patterns written in a language that has trouble modernizing.
This description of Wordpress really shouldn’t be a surprise for any seasoned developer. Out of the box, the blog engine still won’t support Composer for versioning, it won’t ship with content translation management even though it features static translations, and it relies on events that can potentially be overridden in absolutely unmaintainable ways – whether or not that code is object-oriented.
Usage is not a sign of quality
One ironic realization that came to me while building on Wordpress is that the vast quantity of available plugins is often used as a selling point, but they are often more an hindrance.
To be clear some work fine. The big known ones like Advanced Custom Fields are awesome but, like Strata, I feel they are trying to improve boat that does not quite float.
In truth, the plugins you install on a site quickly become a liability because they are often security disasters waiting to happen. That’s when they enable the feature your project needs to start with.
For the brave, Strata is easy to copy
What Strata enabled can easily be added to the Wordpress core if they cared. All in all, Strata was really just an event hook that registered early in the rendering pipeline that would route URLs to controller classes.
It is true that we did clever Custom Post Type autoloading and that our controllers could override the templating engine to allow custom response types (ex: JSON, file downloads, etc.) which Wordpress would have a hard time refactoring in.
They would still have a better platform with a fraction of the features granted by Strata though and I am surprised they are not trying harder by now.
Routes worked great
In hindsight, especially because of translations, I would probably route on the template key used by a custom post type rather than its slug. I would also rebuild the router using Symfony components instead of the pattern matcher we were using.
No matter the details, it is hard to argue against routing actions, filters, events and custom post types to dedicated controllers classes as an elegant way of keeping your code organized while leaving logic out of the templates.
Custom Post Type as Models
This is where I think you got the most value out of Strata.
Considering each Custom Post Types as a model, we were able to create an abstraction to the database that hid Wordpress’ raw database queries.
You could query your posts with an almost ORM type API and invoke Active Record-like methods on the obtained result’s elements. Those clearly defined boundaries between your model queries and your model entity manipulations.
That was incredibly useful and I was able to deliver complex functionality easily with that and basic class inheritance.
And so this is it, goodbye Strata. I have learned a lot from building you.
I am sad that Strata has not attracted more developers, but I would not want to maintain it at this point anyways. Not while Wordpress continues being… Wordpress.