Gutenberg and The Impacts It’ll Have on the WordPress Business Ecosystem
As has become customary over the past 8 years, I joined thousands of fellow WordPress enthusiasts and supporters for WordCamp US 2018 in Nashville, Tennessee. For me, the highlight is always the State of The Word (SOTW), delivered by Matt Mullenweg (Co-Founder of the platform).
The SOTW provides an opportunity to reflect on the last year, and where the platform is going. Where the platform goes is often a strong indicator of where the rest of the ecosystem will follow.
The WordPress Business Ecosystem
Last year it was a pivotal year for the platform. We did away with release cycles, introduced a multi-lead approach, but more importantly it introduced the hottest and most contentious idea since the platforms inception- Gutenberg.
We were treated to a live demo. It provided a fresh, awe-inspiring, view of Gutenbergs power. It wasn’t at this point that I gained a completely new appreciation for the role it will undeniably play in reshaping the WordPress business ecosystem.
How many plugins would it have taken to achieve this experience?
This is what I kept asking myself as I watched.
Today the WordPress business ecosystem is comprised of products (e.g., plugins, themes, etc..), integrators (e.g., Pro’s, Agencies, etc..) and services (e.g., hosts, security, maintenance, etc..). Tomorrow, it’ll look dramatically different in large part to what Gutenberg is doing. Are you prepared?
Gutenberg site customization…
Future of 2018 – Matt Mullenweg
As Gutenberg moves beyond the posts / pages, into the world of site customization I find myself wondering how many more thing it’ll simplify and consolidate. Specifically, how that will impact the small businesses that power today’s WordPress platform; those that have built themselves dependent on a platform’s specific design.
If it was not apparent, the platform is changing. If your product is meant to simplify some aspect of the platforms experience, your future is inevitably numbered, as it’ll likely be commoditized at the core level.
The message and direction is clear for the platform. We achieve our BHAG if we can optimize the users experience. We’re doubling down on this.
Good or Bad – Doesn’t Matter
It’s not that the plugin / theme community isn’t valued or that no one sees the platform exists because of it. But it is about hitting goals, and what the platform needs today to get to it’s BHAG is very different than what it needed when it required growth / user adoption.
If I were Matt I would be doing the same thing. It’s about combating the encroaching affects of outside closed-source platforms, the threats they pose on the larger open-web conversation, and also hitting that platforms big hairy audacious goal (BHAG) of 51% market share.
If I were the plugin / themes shops I would be rightfully concerned and upset. It’s this feeling of frustration, and possibly betrayal. As a small business, there is already limited time and resources to support the needs of acquiring new customers, let alone supporting the ones you have, and now there is new requirement that feels extremely exhausting.
The real question I would be asking myself is not whether I can support it, but rather what does it do to my product category when it becomes standardized in core? My general feeling is that the WordPress business landscape will be look dramatically different in five years. Where does your product / business sit?
This does not mean that there won’t be a plugin ecosystem in 5 years, but rather that it’ll be dramatically different than today. Tools that prove invaluable in moving the platform forward will prove market need, and this need will be productized at some level.
The impacts here will move beyond just the plugin domain, there are affects to be felt within the theme space as well. One could argue that when the site creation process is introduced how themes are leveraged will fundamentally change. When you simply the creation process, do you really still need a theme at all? If so, what does that theme really look like?
There is also the impacts to integrators, specifically the professionals that make a living on helping users establish their online entity and do it by taking a theme and configuring it. I’m talking about that process that many Pro’s take today – sell a site to a customer, buy a framework (think Genesis), read the document and configure the site for their customer. In many ways, you can argue the Do It For Me (DIFM) market exists predominantly because the Do It Yourself (DIY) space has proven to hard. What happens when that technical divide becomes smaller? We’ve always known the platforms achilles heel is 5 minutes to install, 3 weeks to configure.
There are certain things / products that deliver such intrinsic value that it transcends any platform. Security is a good example such a product. These are the areas we, you, should place your energy as a small business if you’re targeting WordPress. These are the areas that cannot be consolidated or commoditized. If you build around how something works today, you might find yourself out of a job tomorrow. This evolution is not unique to WordPress, it happened with Google, Twitter and the list goes on. The platform will always do what is in the best interest of the platform.
Just because WordPress is democratizing publishing, it doesn’t mean it is a democracy.
Hi,Toney Perez
Very good article,Really helpful,Thanks for sharing this information.Keep up the good work.
https://newseland.com/
Speaking of Gutenberg and Security…
As it stands Gutenberg doesn’t really have any server side API. The WordPress server has no knowledge of what blocks have been registered, what properties those blocks have/can have, what shape/type of data can be associated with blocks, etc.
All block knowledge is exclusively on the client, and after chatting with several members of the core Gutenberg team at WCUS, there’s no plans to change this anytime soon.
This seems to be bad practice and encouraging bad practice. I can’t think of a single time I’ve ever built any type of user input where the server didn’t have the final say on what should be done with the data.
Gutenberg introduces hundreds of inputs for users to interact with but provides no server API to validate the data, set permissions/capabilities on who can edit said data, etc.
Curious to hear the thoughts of a security expert like yourself.
Can the concern for the apparent lack of a server-side API be because web development has become less dependent on the server and more dependent on the client? I think so. As I see it the future of WordPress development belongs to Javascript developers.
Gutenberg still has major UI and UX issues and feels like an editor designed in the style of the Customizer.
I think it’s great to take advantages of the advanced things rich clients allow us to do, but no matter how powerful client side development becomes, it’s still client-side.
Gutenberg is encouraging plugin developers to migrate functionality into blocks, etc.
Many plugins have sensitive data that should only be viewed or interacted with by users with proper capabilities.
If all blocks are handled completely on the client, with no true server API, that allows anyone of any role to interact with blocks, edit content of any block, etc.
It seems like the lack of a true server side API for block registration and validation is opening up all sorts of problems with workflows in the admin.
I can’t see how plugins can truly migrate their functionality to Gutenblocks until there’s a server-side API that handles things like validation, auth checks, etc.
Think of the Book example that Matias demo’d at WCUS. It had a layout that had content and an image. . .let’s say the workflow for an organization was to let writers add the content, but not be able to edit images. Then a photo editor could edit the images, but not edit the text content.
Ideally, we should be able to mark the blocks with certain capabilities so that just the appropriate user could edit the field.
Right now you _could_ technically figure out a way associate a block with a capability on _just_ the client, but simply opening up the browser’s console/inspector and you could override that and still post changes to the server, giving anyone with any role free reign to update content they don’t have permission to update.
The server should be the contract between the client and the persistence layer, validating the content, checking permissions, etc.
Gutenberg living 100% on the client with no true server-side API makes it very difficult, if not impossible, for plugin developers to convert things to blocks with any confidence.
Additionally, having a server side API will also reduce the amount of client code needed.
Gutenberg is going to ship with what, 40+ blocks? If there were a server-side API, and I deregistered 38 of them on the server, only 2 blocks would ever need to load on the client. But right now, you have to deregister blocks on the client, meaning all 40 blocks will load, plus the client side code that deregisters the blocks. Seems backwards. . .and still doesn’t even truly work. If all 40 blocks are loaded and the client deregistered them, simply opening the console/inspector will allow someone to re-register them, as they’re all loaded in the client already. . .
I think React, etc is fantastic, but I think the project is being rushed and not being fully thought through. Without proper APIs in place, I can’t see how it’s realistic to ask any plugin or theme developer to integrate with Gutenberg.
There’s discussion about other implications of not having a server-side API as well:
https://github.com/WordPress/gutenberg/issues/2081#issuecomment-345534166
https://github.com/WordPress/gutenberg/issues/2751
But doesn’t seem like the server side API is a priority, or even thought of as truly necessary. . .which baffles me.
“The platform will always do what is in the best interest of the platform.”
And herein lies the problem. Because “the platform” in this case is almost always .com and it’s competitors rather than the needs of the community (.org). This has been an issue time and time again throughout the 13+ years I’ve been a part of this community.
If only it was engineered for the Customizer or at least the front end, but now I hear that the term “front end” is debatable… Apparently Customizer integration comes later along with an example theme. This is why some of us are calling for a clear Roadmap, as none exists for neither Gutenberg nor WordPress.
Yep there does need to be a clear roadmap.
https://github.com/WordPress/gutenberg/issues/3354
https://github.com/WordPress/gutenberg/blob/master/docs/faq.md
I don’t see why would themes become redundant?
Gutenberg is an editor, but you still need at least a stylesheet to make the content look the way you want, especially if you want it to look the same as in the backend.
What I mean is that if you take a vanilla WP install with the 2017 theme and Gutenberg, the backend shows a serif font, whereas the frontend shows a sans-serif font. The backend is full width, whereas the frontend has a sidebar, which ensures that the brand new post is exactly “WYSIWYG-NOT”!
Am I missing something?
WordPress.com introduced a business level plan at 30 or so bucks per month that allows plugins and themes installation. That happened sometime last month with little fanfare. I am sure you can recognize that the .com is now morphing into a real competitor of proprietary systems like squarespace and wix. In that context, a better content editor is critical and will most likely benefit WordPress.com users well before they benefit the wider diaspora of .org.
Automattic is a business with an open source community powering its ever growing market share expansion. Gutenberg is yet another feature in a long line of improvements that will enable WordPress.com to flourish first, enabling the community and ecosystem to benefit from the growth of new customers adopting WordPress in general.