Something I have observed over the last few years of working in the WordPress space is that it has become increasingly difficult to use work we develop on Client projects and contribute it back to WordPress Core. To me, that is a really concerning development, and I want to write about some of the things I’m observing to hopefully start a conversation about how we can improve this again. 

How contributions used to happen

When a client approaches us to develop a cool new feature for their website, we are often on a tight deadline and have specific launch dates in mind. We scope out all the work and then build solutions on top of WordPress. These solutions leverage WordPress’s hooks and filters to develop our solutions as custom plugins. 

This method allows us to develop these custom features on our own timeline and iterate quickly. Once we wrap up a project, we often approach our customers to determine whether they would like to contribute some of the things we built for them back to improve WordPress itself. 

That’s a great model that has worked very well for everyone. The client benefits in a few ways because they feel good about having made a larger impact. At the site time, it reduces ongoing maintenance costs for them because they are no longer using a one-of-custom solution but rather a feature WordPress officially supports. And the entire community can benefit from this work.

Besides just custom development work for clients, this model of feature plugins is how most of the larger features in WordPress got developed in the first place. Including the block editor, which started out as a feature plugin and technically remains one to this date. (Even though I would now think of it more as the alpha channel of WordPress core. But that is another topic)

So what changed? 

Since the block editor is in core we are finding it more and more difficult to actually use this model to contribute back to core after a custom feature has been built. The block editor itself is not nearly as extensible as “old WordPress” used to be. That is, in part, due to the nature of JS. Also, the open approach in the core has been misused again and again by plugin authors to degrade the experience of using WordPress. (We’ve all seen sites with ads and notices everywhere…)

However, this change in how extensible things are for 3rd parties now essentially means that any UI explorations, anylarger customization of WordPress can only happen in a feature branch or fork of the Gutenberg codebase itself. So, for custom projects that are on a fixed timeline & budget, that is no option. Instead, we have to resort to building custom integrations that don’t function as they would in core and, therefore, are not really something one can port back to WordPress after a project is complete. 

This problem has only worsened over time because any new innovation in the block editor happens behind private APIs and internals that never get exported. So, it becomes even harder to customize/explore features outside of working on core itself. We cannot get clients to pay for this because there is no clear timeline or even an expectation that the improvements will get merged into core at some point. 

I don’t suggest that this is an easy problem to solve. I have been and still am a big proponent of the introduction of private APIs because we needed to solve our backward compatibility issues. This post is just attempting to showcase some struggles I’ve been running into to continue the conversation about how we can improve this. 

Protecting the Experience

Another reason I often see from members of the Core team is that we want to prevent a similar situation to what WordPress ended up in before: ads and notices injected into all places of the UI, leading to a greatly reduced usability of WordPress.

And whilst I fully agree that WordPress, in particular, has many problems with this issue, I don’t think that it is the right approach long term to outright prevent extensibility to protect us from bad actors. I know it is naive thinking, but I still believe that, in the end, customers will choose which plugins they want to use based on what provides value to them. 

Having to fork all of Gutenberg to experiment with a new experience just doesn’t seem very future proof to me.

I really believe that the ability to extend virtually any part of WordPress core and swap it out for a custom implementation is what helped it grow so much and what, over the years, led to its steady rate of contributions from various sources.Whereas today, you have to essentially be a full-time contributor to the project in order to make a meaningful difference.