Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The Economic Impact of the Timeline of the Gutenberg Rollout #3926

Closed
gidgey opened this issue Dec 11, 2017 · 37 comments
Closed

The Economic Impact of the Timeline of the Gutenberg Rollout #3926

gidgey opened this issue Dec 11, 2017 · 37 comments

Comments

@gidgey
Copy link

gidgey commented Dec 11, 2017

Issue Overview

As a business-oriented marketer, my perception of Gutenberg is not about it's beauty or ease of use. Rather, I am very concerned (and have been since June 2017) about the timeline of Gutenberg, how quickly it is being iterated, and the economic impact it will have and, frankly, attrition.

Disclaimer

I am the Marketing Team CoRep for Make.WordPress, I am a business owner, and have formerly worked for a very successful plugin development company and advertising agency who both rely upon WordPress for their business model. Though I will write about this on my own blog, I thought I would put my money where my mouth is and be an official voice instead of a behind-the-scenes voice.

I commented on #3902 but the economic concern is separate and deserves its own issue.

#3902 (comment)

Backward Compatibility

It is my understanding that WordPress, as a project and community, is committed to backward compatibility. To be fair, I've mostly heard this discussion when considering back-end compatibility with PHP. And I understand the frustrations with developers wanting to use PHP7+ functionality.

However, PHP developers are able to wrap the depreciated code. The new Gutenberg experience (editor) puts a large-scale burden on plugin and theme developers in a short, four-month period.

SWOT Analysis

To assist in the marketing strategy both inward (Make Teams, WordPress Developers) and outward (clients, end users, agencies), a SWOT analysis should be made by us.

Here is an example:

Strengths: Ease of use, modern technology, possibilities with VR, etc.
Weaknesses: Accessibility, SEO issues, compatibility
Opportunities: New developers, new customers, modern technology, better UI
Threats: Attrition (loss of WP to Wix, et al), Economic impact, loss of volunteers

Attrition

Attrition is a real risk. I shared Morten's article from LinkedIn and an affiliate marketer began having a conversation with me that I think we should listen to. 29% of the internet uses WordPress. The rollout needs to manage expectations, educate, and give people time to learn.

We're not Apple. We don't dictate and expect people to adapt. We believe in democratizing publishing. This is key to our culture as a software.

https://twitter.com/JessicaGottlieb/status/940033708299448321

https://twitter.com/JessicaGottlieb/status/940040642855518208

https://twitter.com/JessicaGottlieb/status/940104882425442307

Economic Impact of a Tight Timeline

Businesses run on fiscal year budgets, not timelines for software releases. It's easy for us on the inside to become excited about amazing features and great possibilities only to forget about the small business owners, the plugin and theme developers, and the bloggers.

Plugin and theme developers, for example, have to shift budgets from marketing (how will this affect WordCamp sponsorships, for example) to product development and support. They need to train themselves and their developers to deeply learn JavaScript and React and Vue (possibly) in order to create compatible metaboxes. Plugin development companies also have to decide if they are going to support their legacy clients. Should they decide to support both, the technical debt now becomes financial in nature as they spend more hours (time) and/or budget (money) keeping current clients. Should they not, they risk losing current clients through attrition.

Agencies who use WordPress often have year-long contracts. The site is built and then used to publish content on a regular basis for lead generation, SEO, and business development. The agency will have to ensure their clients' sites either remain on 4.9.x or are fully compatible to Gutenberg. Many agencies build custom themes on frameworks or with ACF. Those themes will need to be worked on (that translates into budget shift). Personally, I've recommended many of my agency clients and friends to prepare for this last October. Many have added to their budget to be prepared.

Small businesses often come to WordPress for the reasons we promote: technical SEO, ease of publishing, owning your own data. Convincing them to stay, when another option may be cheaper (WIX, Squarespace, even Dot Com), may become a challenge. Businesses don't make decisions based upon community loyalty; they make decisions based upon finances.

Possible Solution

I would love to see the version that will be shipped with 5.0 set sooner than later. This will allow WordPress educators, agencies, businesses, the Make Team, and development shops to prepare the general public for the rollout with marketing materials, documentation, and, of course, compatible code.

Keep iterating. It should iterate. But the economy that relies upon WordPress needs time to learn and accept.

Thank you for your time.

@doubleedesign
Copy link

doubleedesign commented Dec 11, 2017

Great post Bridget, thank you for writing this. It echoes my concerns.

I used to work for a company that, by the time I left, had over 400 WordPress sites with custom themes (built with an in-house framework) and were in a years-long process of migrating ~200 more from an older CMS in addition to new builds. While companies like this no doubt are monitoring Gutenberg closely and preparing, I imagine a good chunk of developers' time will be spent installing something to disable it, not trying to make 400+ sites work with Gutenberg.

I look after 30 sites myself and that's what I'll be doing, and then I'll look at each site at a later date and see which ones can easily be updated, and then try to work out what to do with the rest.

Depending on complexity of sites, devs simply cannot afford to spend a lot of time on this for existing sites, because we can't charge for it unless a client specifically asks for their theme to be upgraded to suit Gutenberg. We built our maintenance pricing structures around the backwards compatibility that has always been a strength of WordPress, whereas this reminds me of the lengthy Drupal 6 to 7 migrations I witnessed colleagues working on in a previous role - difference being that's the way Drupal has always been so contracts and pricing structures reflected that.

I do have a clause in my contracts that if a site ceases to be compatible with the latest version of WordPress or a plugin, it will continue to run on the last compatible version until a solution is found. I never thought I'd need to use that clause for WordPress itself.

On another note, there are users who have DIYed their own website using free or commercially-made themes reliant on metaboxes and shortcodes whose sites will suddenly break at some point if Gutenberg isn't clearly optional. Surely that will be terrible for retention.

@senlin
Copy link

senlin commented Dec 11, 2017

I imagine a good chunk of developers' time will be spent installing something to disable it

Exactly my thoughts.

I have had a look at the Classic Editor plugin, with which the user still needs to tick a box to remove Gutenberg completely. So I'd either fork that and install it on the sites of my clients or simply set the version to 499.x right before 5.0 drops.

And then I can in my own time migrate my clients to Grav, Kirby or anything else that I fancy, because we all know that most clients really don't care on what CMS their sites are running!

@gidgey
Copy link
Author

gidgey commented Dec 11, 2017

@doubleedesign It's a good thing you have that clause. I'd start educating your client base sooner than later so that you can get them used to the idea.

@gidgey
Copy link
Author

gidgey commented Dec 11, 2017

@senlin Piet,

Are you saying you may leave WordPress?

@senlin
Copy link

senlin commented Dec 11, 2017

@gidgey Bridget,

I am seriously looking at other CMSs and have already put together a couple of sites with Grav CMS.

So, yes, you can indeed say that there is a more than 50% chance that I will drop WP when Gutenberg drops in WP 5.0.

@senlin
Copy link

senlin commented Dec 11, 2017

And something else to consider:

If you are landing a medium sized project now which you will definitely build with ACF if you were to choose WP, would you then actually choose WP?

I know I wouldn't. I'd rather have the learning curve, than to tell the client in 4 months that the site I developed cannot be edited anymore or cannot be updated anymore.

@gidgey
Copy link
Author

gidgey commented Dec 11, 2017 via email

@gidgey
Copy link
Author

gidgey commented Dec 11, 2017 via email

@doubleedesign
Copy link

If you are landing a medium sized project now which you will definitely built with ACF if you were to choose WP, would you then actually choose WP?

Some backstory: I started my career as a junior Drupal dev and learnt WP on the side for my own clients. My next job was 100% WordPress, so while I wanted to stay in both ecosystems, long story short in reality it made more sense to mostly stick with WP.

The first thing that drew me to ACF was basically that it brought something I loved about Drupal - the ability to specify fields for content types easily in the backend - into WP. There are just so many uses for this. It's easy for clients to fill in a form with their content without having to worry about formatting and layout, and then I control the display with the template. This is the foundation of how I build sites.

So if I can't build like this anymore and Gutenberg doesn't work for my clients (I can already think of some who would hate it because they don't want to think about formatting or layout, that's my job) then no, I would not choose WP in some cases. I would probably go back to Drupal. Not for everyone, and probably not even for most - I will still be working with WP - but definitely for some.

@gidgey
Copy link
Author

gidgey commented Dec 11, 2017 via email

@doubleedesign
Copy link

My presumption (and hope) is that the ACF plugin will convert.

Yes, absolutely, I believe it will, which is why I'm not immediately, hastily jumping ship back to Drupal for everything ;) Not unlike WooCommerce really, it's become such a backbone of the ecosystem.

But, it is still a worry, because the developer needs time to make ACF compatible. Which means those who heavily use the plugin can't convert existing sites until they do. Which could make the already short timeline even shorter.

I agree completely with the suggestion that Gutenberg be optional for at least a year. This gives plugin developers an opportunity to do a thorough job of making their plugins compatible, as well as giving developers time to integrate those changes and educate clients.

In addition, there should be an option (e.g. through the Classic Editor plugin) to keep Gutenberg turned off and keep the classic editor for even more time after that, for sites that just won't be converted at all due to cost/time constraints. The shelf life of a small to medium website means that in a few years that client may want a redesign anyway and then they would get Gutenberg when that time comes.

@senlin
Copy link

senlin commented Dec 11, 2017

@doubleedesign Leesa makes a great point here:

they [clients] don't want to think about formatting or layout, that's my job

And that is also one of the things that makes me angry/disappointed! That there are page builders is one thing. Obviously there is a market for that, but it's not my market nor that of my clients.
So why is everyone now pushed into WP becoming a page builder? And using the phrase democratizing publishing for it does NOT make it right.

When I build site for clients, then they're highly customised and they do exactly as per the client's wishes. My clients do not make mistakes when it comes to editing content, because (with ACF) I create a backend experience that leaves no room for mistakes.

I was watching the presentation by @mor10 where he mentioned that theme developers can lead the users through the content.

I am already doing that for the past years!!! Without Gutenberg!

I rolled into WP in 2005 and have been using it very happily since. I have developed a number of plugins, some more popular than others, and have developed a specialty which has kept me off the street so to speak.

As I often tell my clients, the website world is constantly in motion and I guess that the time I spent intensely with WP is reaching its end and new frontiers to discover are on the horizon for me.

I just don't like the way it is ending, but then again, sometimes a breakup is easier with a push than letting it die slowly...

@doubleedesign
Copy link

That there are page builders is one thing. Obviously there is a market for that, but it's not my market nor that of my clients...

My clients do not make mistakes when it comes to editing content, because (with ACF) I create a backend experience that leaves no room for mistakes.

@senlin, it's like you're reading my mind! ;)

@ghost
Copy link

ghost commented Dec 11, 2017

That there are page builders is one thing. Obviously there is a market for that, but it's not my market nor that of my clients...

My clients do not make mistakes when it comes to editing content, because (with ACF) I create a backend experience that leaves no room for mistakes.

@senlin, @doubleedesign, exactly the same here.

Gutenberg surely is an interesting and ambitiously project, but not of any use for 99% of my clients.

@wpchannel
Copy link

I've been using WordPress for 10 years and I'm involved in the French community since the beginning but this time, it's the first version that's scared me for all the reasons you mentioned...

@karmatosed
Copy link
Member

karmatosed commented Dec 12, 2017

I wanted to pop in to give a little perspective about the timeline as is currently planned. I say planned because as we move towards 5.0 the community, 5.0 lead and core team will work together to figure out the path to merge. Note it has not been merged and at least 11 versions are expected - 1 has just been released.

It's worth noting that all releases have a release candidate phase, 5.0 will be no exception. Also worth saying is something several people have, there will be for a long time the option of the classic editor plugin and even network activating it. That plugin isn't going anywhere on 5.0's release and will likely stay around for a good while, the classic editor itself is still being maintained.

Custom fields isn't been missed out, there is an awesome plugin being worked on and a post here: https://riad.blog/2017/12/11/with-gutenberg-what-happens-to-my-custom-fields/.

Metaboxes have a few potential paths to upgrade, right now it's working out the best of those. How the system will default and what the user experience will be regarding that. Nothing is set in stone, everything is being worked on for the best user experience. Users are all types of people - those actually writing, theme creators, plugin makers and a whole lot more.

I know change is hard and scary, we all feel it. I do, you do and it's even worse when we can't quite understand the change. I would point people to wordpress.org/gutenberg as a starting point to understand the project. I say starting point as from there you can go to the handbook: wordpress.org/gutenberg/handbook. Here for example is the compatibility section that I feel is important to share:

The Gutenberg project is actively addressing compatibility concerns. Blocks are the de facto new mechanism for building content features, and we recommend that developers migrate any features they offer that are well-encapsulated by blocks. However, support for existing WordPress functionality will remain, and there will be transition paths for shortcodes, meta-boxes, and Custom Post Types:

Shortcodes.

  • Will continue working without changes.
  • There is a new “shortcode block” to help inserting them.
  • There’s a planned mechanism for previewing them in place.

Meta-boxes.

  • Some will continue to work with no changes under the new UI.
  • Some will need updates (particularly those that rely on the DOM for operating).*
  • Several can be converted to native blocks (particularly those that are rendered on the front-end).
  • Some can transition to new Gutenberg native extension points outside of the content area.
  • There will be a mechanism for conflicting meta-boxes to load the classic editor instead with a notice.

Custom Post Types.

  • Are supported by Gutenberg.
  • Need REST API (show_in_rest) declaration.
  • Can opt out by not declaring “editor” support.
  • Will be able to declare supported and default blocks.
  • Certain meta-boxes that rely on the specific structure of the current editing screen are not guaranteed to work under Gutenberg, and might need changes before they can be loaded correctly.

I would encourage you all to consider in what I have said which is the right path for your particular set up. Each person may want or need to take a different approach with Gutenberg. The key is that nobody on day 1 is expecting you to have made blocks. It would be amazing if people have, but the reality is there will be options for you to slowly upgrade. A whole lot of documentation, education and discussion needs to happen. That's great because the entire community is involved in this and can do that.

Lastly, please don't be scared. WordPress is a community and whilst threads like this can seem scary, Gutenberg is not and the last thing anyone involved in the project wants is for you to feel scared. Those making Gutenberg care, those in the community care. WordPress is an awesome project that really respects the awesome things people are making. I'd encourage you to work out the path that will be the best for you and then explore, have fun and get excited about blocks. Have your plan and then look to how you can build up from there.

If you have any questions about Gutenberg at all, in any context the #core-editor channel on chat.wordpress.org is always there for you. You can also watch in that channel the work that is going on and see the weekly meetings at 18:00 UTC on Wednesday's and generally hangout. Let's all work together on the way forward.

@senlin
Copy link

senlin commented Dec 12, 2017

@karmatosed Tammie,

Metaboxes have a few potential paths to upgrade

Thing is before GB my metaboxes are fine and dandy. They may be active on sites I no longer manage. How about the clients of those websites I developed a few years ago? All of a sudden their site content becomes not editable anymore.

I know change is hard and scary, we all feel it.

These type of remarks are unnecessary as they come across as really condescending and patronising! Pointing people to reading heaps of documentation that hasn't even been finished and is still a work in progress is ridiculous in my opinion.
a. I don't have time for that and b. this discussion is not about understanding GB it is about The Economic Impact of the Timeline of the Gutenberg Rollout

Regarding the list of what needs to be done regarding shortcodes, metaboxes and CPTs, shows that it is even worse than I thought.

CPTs will not work anymore without declaring show_in_rest?!?!?! So I am now supposed to go back into clients' sites and redo 3-5 years of work?

That, Tammie, is exactly the economic impact @gidgey (Bridget) brought up with this post! That you seem to fail to understand this is scary at best, especially since you are part of and evangelist for GB!

@doubleedesign
Copy link

doubleedesign commented Dec 12, 2017

@karmatosed Thank you for your thorough response.

there will be for a long time the option of the classic editor plugin and even network activating it. That plugin isn't going anywhere on 5.0's release and will likely stay around for a good while, the classic editor itself is still being maintained.

For sites that will use the classic editor for the forseeable future, does this need to be installed prior to 5.0 rolling out? The ideal for me in these cases is that Gutenberg is never turned on, so to speak - not that I hurriedly log in to all my sites to turn it off.

I know change is hard and scary, we all feel it.

This thread isn't so much a Stewie Griffin voice "Something's wrong with the house! I don't like change!" thing. It's about the speed of it. You say that you don't expect anyone to have built blocks when 5.0 ships...yet without intervention, site backends will have that interface, new sites in development will need to be changed or an upgrade planned; new sites being planned/scoped will have a bunch of question marks over their plans.

In addition, clients with existing sites but without maintenance plans or active developers may be confused, and if their site breaks, angry. IT departments will be receiving support requests for something they know nothing about, and developers will be fielding calls from irate past clients.

All of this is going to take up significant amounts of everybody's time. I know Gutenberg has been in beta for a while, but it's just not the same as being able to use it on real sites with real clients to confirm what the real trouble points are for our sites and for our clients.

there will be options for you to slowly upgrade

A slow transition needs to be the default and the expectation. This has probably already been suggested but surely there could be a "Please choose your editor" prompt upon upgrade to 5.0. This would be particularly helpful for clients without an active developer/maintainer who are worried about changes.

@senlin

That, Tammie, is *exactly the economic impact @gidgey (Bridget) brought up with this post! That you seem to fail to understand this is scary at best, especially since you are part of and evangelist for GB!

The default response to developer concerns seems to be "But Gutenberg is awesome!!!" Right now, I don't care how awesome it is, I'll find that out in due course through proper use of it after release. Right now I care about what's going to happen to, and what I need to do about, the 30+ sites I currently maintain, and the handful I currently have in development.

Users are all types of people - those actually writing, theme creators, plugin makers and a whole lot more.

@karmatosed This is also a bit condescending and isn't helping how alienated some developers are currently feeling. We know we aren't the only users. In fact there's been comments in this very thread expressing our concerns about the impact on some of those users actually writing, because they are our clients. We're not just making it about how we want to code (though that is an element of it, but not relevant to this topic).

@karmatosed
Copy link
Member

karmatosed commented Dec 12, 2017

@senlin let's move on from accusations of intent, we all care what happens here and respect is important.

I shared what I did with the intent of informing, not intending to patronise. It's important to note I see the value in this discussion, I engaged and I am engaging here. I also do see the point of the thread. What I felt was that sharing the resources we have right now was important in working out a path.

Let's move on from this point and dive into a reply to your comment:

How about the clients of those websites I developed a few years ago?

This is why I added the documentation quotes, to show the potential fallbacks being worked on. It will depend on the metabox but that fallback potentially is what happens.

One thing worth noting for those working on this to learn, sharing the examples you are thinking of is important. That helps the two way conversation.

@doubleedesign, thank you for your reply also.

For sites that will use the classic editor for the forseeable future, does this need to be installed prior to 5.0 rolling out?

The classic editor plugin does need today to be turned on. This would mean having it live on the day of 5.0.

I totally would encourage where possible people to try Gutenberg today on sites. By trying, bugs, issues and feedback can be sent to those working on it. That's crucial to get this two way discussion.

@senlin
Copy link

senlin commented Dec 12, 2017

It will depend on the metabox but that fallback potentially is what happens.

。。。

@doubleedesign
Copy link

It will depend on the metabox but that fallback potentially is what happens.

Admittedly I haven't been involved in a software project of this size myself so I don't know if this is normal, but I'm nervous about all the parts that still seem to be uncertain this close to release.

@karmatosed
Copy link
Member

karmatosed commented Dec 12, 2017

@doubleedesign just to be clear I wasn't dismissing developers here:

We know we aren't the only users. In fact there's been comments in this very thread expressing our concerns about the impact on some of those users actually writing, because they are our clients.

I was saying it's about the experience for everyone, developers, designers, users. I wanted to make sure on that point as feel it was misunderstood. I was saying all matter and not at all dismissing developer experience.

To summarise what I was saying:

  • When 5.0 ships things won't break. There are options in place to avoid that. More options can be added.
  • To ensure things don't break, feedback is needed. Testing, telling the team where the issues are and what setups are breaking, is essential. This is not to say that those working on it aren't testing, it's just every single stress case that is out there, nobody knows. The two way communication is key.
  • How Gutenberg ships is a detail for 5.0. The team right now are focusing on the product, getting feedback, responding and iterating. That does not dismiss anything but that's where the lead of 5.0, the community step in; working out how Gutenberg gets shipped.

@senlin
Copy link

senlin commented Dec 12, 2017

@karmatosed

When 5.0 ships things won't break.

Is this a guarantee or just summing up what you were saying without any value attached to it?

@josephahaden
Copy link

@gidgey I think also a potential solution in the midterm is this crowdsourced site for getting and giving help transitioning products to Gutenberg: https://gettingreadyforgutenberg.com/

I realize that mostly addresses a potential symptom, rather than an overarching concern you have. From a purely philosophical standpoint, I wonder if we are underestimating the resilience of the type of person this community attracts.

I can't predict the future (though it's top of my wishlist for super powers) but you are right that there will be a big economic impact. I think we have to go into this change with our eyes open, and thank you for verbalizing your concerns openly here for discussion. It's conversations like this that help us name our fears so we can address them as best we can. 🤗

@gidgey
Copy link
Author

gidgey commented Dec 12, 2017 via email

@iandunn
Copy link
Member

iandunn commented Dec 12, 2017

CPTs will not work anymore without declaring show_in_rest?!?!?! So I am now supposed to go back into clients' sites and redo 3-5 years of work?

My understanding is that it's the other way around; CPTs that do not explicitly declare show_in_rest will not use Gutenberg by default. Gutenberg uses the REST API to get and save post data, so if the CPT doesn't support the REST API, then Gutenberg can't work with it.

So, ~95% of CPTs will use the Classic editor by default, without any changes needed.

gutenberg/lib/register.php

Lines 303 to 338 in 9864a60

/**
* Return whether the post type can be edited in Gutenberg.
*
* Gutenberg depends on the REST API, and if the post type is not shown in the
* REST API, then the post cannot be edited in Gutenberg.
*
* @since 1.5.2
*
* @param string $post_type The post type.
* @return bool Wehther the post type can be edited with Gutenberg.
*/
function gutenberg_can_edit_post_type( $post_type ) {
$can_edit = true;
if ( ! post_type_exists( $post_type ) ) {
$can_edit = false;
}
if ( ! post_type_supports( $post_type, 'editor' ) ) {
$can_edit = false;
}
$post_type_object = get_post_type_object( $post_type );
if ( $post_type_object && ! $post_type_object->show_in_rest ) {
$can_edit = false;
}
/**
* Filter to allow plugins to enable/disable Gutenberg for particular post types.
*
* @since 1.5.2
*
* @param bool $can_edit Whether the post type can be edited or not.
* @param string $post_type The post type being checked.
*/
return apply_filters( 'gutenberg_can_edit_post_type', $can_edit, $post_type );
}

@youknowriad
Copy link
Contributor

youknowriad commented Dec 12, 2017

CPTs that do not explicitly declare show_in_rest will not use Gutenberg by default.

This is actually a "bug" in the API because any CPT with "show_ui" => true should be able to be edited in Gutenberg. And I expect this to be fixed before the merge.

@mor10
Copy link
Contributor

mor10 commented Dec 12, 2017

@iandunn That's a huge problem for the future progress of Gutenberg since Gutenberg isn't supposed to merely be an editor replacement but a whole new way of managing views. If CPTs block Gutenberg, Gutenberg can't move beyond the editor.

@wpmark
Copy link

wpmark commented Dec 12, 2017

I completely agree here in that the problem for me is not change. If we didn’t change or move forward we would still be stuck with WordPress v1, which at the time was amazing but is far from as good as we have now.

The worry is the timing of the rollout. We are being told that Gutenberg will be rolled out sometime in early 2018 which is very worrying and in my opinion far too early.

Most projects in WordPress (thinking of the REST API) were plugins for months or even years before being introduced into core, and they we not even plugins that users would actually notice. This is the first big development that I can remember that will massively effect every user of WordPress. Whether you are a developer, design or content editor it is going to effect you in some way or another.

To mitigate this effect, and make the transition smoother we just need more time. Right now, like most in this thread and many in developers in the WordPress community I know, we use tools such as ACF in order to build out sites that are customised to client needs. To do the same going forward, in such as short space of time will require me to learn an entire new language using Javascript and React, which is unrealistic in what could be 4 - 6 months.

Many threads on here tell us to read documentation and go and learn all about Gutenberg. It is not that I am not willing to learn Javascript and React and Gutenberg - I would love to and it would seem like if you are going to build something new in WordPress that is the way to go. However like many in this thread I have a business to run, current clients to look after and realistically I cannot learn this in such a short space of time. I just don’t have the time.

I am genuinely worried about what will happen to client sites when WordPress version 5 lands and I would expect a lot of unhappy clients. Granted we are not there yet and I hope that the path to WordPress version 5 with Gutenberg is smooth. I must admit though, not a lot I am hearing is convincing me that this will be the case, with mixed messages.

Never before has there been such a divisive issue in the community. We are told not to worry but with no solid evidence to back this up. I just hope it goes more smoothly than I anticipate.

@aaronjorbin
Copy link
Member

Thinking outloud, but I wonder if people have various times in their head for when they think 5.0 is being released.

My back of the napkin thoughts are:

Gutenberg continues with regular weekly releases as a plugin (with a well deserved holiday break) until around early April.

Then, Gutenberg will be proposed for merge into Core. This will likely take at least a week of logistical work, maybe 2 weeks. We are then looking at mid April.

In past releases after feature project merge, there has been a week long window before Beta 1 is released. I'm going to say April 25 (again, this is my thoughts, not a firm schedule).

A Releases of this size is going to likely need at least 4 betas, but I think 5 might be safer here. So we'll say that it is the end of May before we hit RC1.

A 3 week RC period to iron out any edges puts the launch around the 19th of June which is just about 1 year after Gutenbergs world premier at WCEU 2017 (ignoring that work was ongoing before that and posts had been on make.wordcamp.org/core a few months earlier outlining some of the early work)

When I think about the fact that we are essentially at a point that the API is stable, this gives over 6 months to prepare. Obviously, there is a need for more documentation in the near term to help make it easier for people to build ontop of Gutenebrg, but that's essentially 2 quarters to prepare for the waterfally types, or 13 2 week sprints for the more agile folks.

@nikolov-tmw
Copy link

Dropping in from the AWP Facebook Group

I agree on the need to educate. However - it won't take us a lot of time as developers/site creators to test Gutenberg on a couple of existing sites. If you have a staging/local site for a site you've already completed, just install Gutenberg on it and test. It took me maybe half an hour to test Gutenberg on 3 sites(I updated WordPress and all plugins as well on those sites). One that was using Beaver Builder was perfectly fine for the pages, as long as I used Beaver Builder(which is the perfectly reasonable thing to do) and the posts(no builder) worked fine out of the box.
The other two sites were powered by heavily utilizing ACF and I found out that the meta boxes are currently not saving. Haven't figured out yet, and I'll probably report on GitHub(I saw there were a couple of issues on the topic already) when I have some time.

I personally have trust in the core team and all of the contributors that are working really hard on Gutenberg, that when 5.0 comes out, it will work out of the box for a really high percentage of all sites. The goal as far as I see it is not to break most sites running on WordPress.
However, we do have to give back to the community by at least reporting any incompatibilities we encounter along the way.

Also, I can't fully agree with the point of "it will cost a lot". What will? Installing the classic editor plugin? If you have a support agreement with your clients, then as part of the 5.0 update you'll be doing, also install the Classic Editor plugin. Boom! You're done :)
If you don't have a support agreement, take a day(or however much time you need - you have a couple of months) to create a list of past clients that you've built sites for. Send to yourself and Bcc everyone and write something along the lines of

Hey, I just wanted to give you a heads-up that with WordPress 5.0, which is scheduled for release on <insert release date for 5.0>, a major update will be made around the publishing/editing experience. Because this is a really major update, it could have potentially negative effects on managing your site's content.
Don't despair though! There's a really easy solution, that will still allow you to safely update - just install and activate the "Classic Editor" plugin. This will make sure that you keep using the same interface as you're used to.
As always, I recommend that you do these updates on a staging site, or at least make a backup of your site before updating WordPress.
If you want to learn more about the upcoming update, feel free to read up on it here

If you need any assistance, I'd be glad to help.
Best regards,
<insert your name/company here>

Boom! You're done. Yes, you might need to respond to a bunch of enquiries at that point, but that will only solidify your clients' satisfaction. They'll see that you care for them and the well-being of their site, even after you've completed it. If you don't want to give your clients a heads-up, then don't, for me it would be worth it.


Some thoughts I didn't post on Facebook:

  • It would be a good idea to create a pointer(that's what they were called, right?) after updating to 5.0 that tells people about Gutenberg, and that they can install the Classic Editor plugin to get their old UI back. This can dramatically reduce the number of frustrated people that will rush to Google/developer/support/etc. for help.
  • Anyone that's claiming that they'll have to change everything they're currently doing for developing custom WordPress sites - please understand this will not be the case. At the worst you just have to install a single plugin(or add the equivalent code to your theme/plugin) and that's it.
  • For anyone saying there's not enough time to adjust(even plugin authors) - please, there are 4+ months. Gutenberg is not something that is being worked on behind the scenes and will be dropped onto everyone's head without a warning. Again, if you test right now, you'll know if you need to make any changes. If something doesn't work - contribute by creating an issue.

And finally...

Please, please, please - be kind to all of the contributors. I understand that big changes are frustrating, but put yourself for just a minute in the shoes of a contributor working on Gutenberg or standing behind it. How would you feel if thousands of fingers are pointing at you and saying "what you're doing is bad and you should feel bad. we don't want your innovation"? Work with, instead of against the contributors. Help them find all of the combinations of code/plugins/themes they could not possibly stumble across. Help make the transition easier and better for everyone. Give back to the community ❤️

Peace out ✌️

@nikolov-tmw
Copy link

@senlin

I am seriously looking at other CMSs and have already put together a couple of sites with Grav CMS.

So, you are willing to invest the time to learn another CMS, but not to install a plugin that just keeps the experience as is? You do understand, that anything that you are not the sole developer of, might at some point in the future make a choice you don't like/agree with and put you in the same situation? You're free to do as you will of course, to me it just seems like an illogicall decision, given the situation as I understand it(maybe we just understand it differently?).

CPTs will not work anymore without declaring show_in_rest?!?!?! So I am now supposed to go back into clients' sites and redo 3-5 years of work?

As is right now, if you CPT doesn't declare show_in_rest, it will just default to the standard editor(so you won't even know Gutenberg is installed by editing a post in your CPT). However as @youknowriad mentioned above, this should be fixed in the future, so that show_in_rest defaults to the value of show_ui when missing.

Have you had a chance to test Gutenberg with one of the sites you've built previously? If not, I'd highly recommend installing it on a dev site, so that you get a better picture of what does and doesn't work with your setup.

@senlin
Copy link

senlin commented Dec 13, 2017

@nikolov-tmw Nikola,

So, you are willing to invest the time to learn another CMS

Yes, indeed!

but not to install a plugin that just keeps the experience as is?

Keeps the experience for how long exactly?

You're free to do as you will of course

Wow, thanks, I really needed your permission!

maybe we just understand it differently?

probably

Have you had a chance to test Gutenberg with one of the sites you've built previously?

As a matter of fact I have it installed on a couple of sites

If not, I'd highly recommend installing it on a dev site, so that you get a better picture of what does and doesn't work with your setup.

Thanks for assuming!

I guess in the end, the economic impact all depends on how you build sites (for clients). You mention Beaver Builder, I already mentioned before (scroll up) that page builders are not something I use or my clients want. So two different things you are comparing here really.

The economic impact that swapping over to Gutenberg will have for me is so large that I indeed rather switch to a different way of building websites altogether. Thanks for your understanding and respecting that!

@maguijo
Copy link

maguijo commented Jan 10, 2018

So many great points here. I agree with pretty much all of them. I think the real solution is to have core Wordpress implement Gutenberg as an OPTION. Leave us the ability to choose to use the Tiny MCE editor without having to install a plugin.

@ghost
Copy link

ghost commented Jan 10, 2018

I understand both sides. The chances and the concerns. I have no clue if Gutenberg will attract new WordPress users or offend the existing ones. But as a developer I have to say that all I have read about the way Gutenberg shall become part of the WordPress Core seems wrong.

I am missing @m in this conversation. Where is the backward compatibility talk from the past? If you want smooth transitions you must not force breaking changes. Do not provide a plugin to switch back to the classic editor. Make the classic editor the default for any existing WordPress updating to 5.0. Make Gutenberg an option for those who update. Have you ever thought about the thousand of WordPress installations doing an automatic update? You won't reach 90% of the users to tell them how they can 'solve' the Gutenberg issue. Simply don't activate it. Tell your story about it on the WordPress Update Screen. Tell people why it may be interesting. If Gutenberg is the future you can activate it with each new WordPress installation but never ever default to Gutenberg after an update.

WooCommerce moved to CRUD. A breaking change. And it was not as smooth as expected. However it did not break backward compatibility. Developers got time to adapt after CRUD has been introduced. Why not doing the same with Gutenberg?

You talk about better Gutenberg documentation. Fine. But developing plugins for and applications based on WordPress I have learned the best documentation it the source code. Therefore you simply have to wait until the final Gutenberg arrives as you don't know what will change during further Gutenberg development.

If I would be the project lead I would follow a simple plan:

  1. Gutenberg would not get the active editor for WordPress updates. Only for new WordPress installations
  2. The plugin to switch to the classic editor would be part of core. It's settings would be visible under the general publishing options of WordPress.
  3. CPT's would work as they did before. If they declare editor support they will default to the classic editor. If they shall use Gutenberg, they would have to declare it.
  4. Metaboxes would work as before. No matter whether they deal with content, taxonomies or custom stuff. There is simply no reason why the editor should have any impact on business logic.
  5. And last but not least for me Gutenberg would be nothing else than any other page builder. Therefore I would have a close look to all the excellent work from those developers and how they managed it to NOT break any WordPress core features ;-)

Just my 2 cents

@gran1887
Copy link

talking of economic impact:

a few claim it [GB] is a bug I should resolve since I suggested WordPress in the first place.

https://deliciousbrains.com/wordpress-gutenberg/#comment-3700968927

@danielbachhuber
Copy link
Member

Thanks to everyone who took the time to weigh in. This is meaningful feedback to refer to as the project progresses.

Closing this issue as there's nothing immediately actionable.

@WordPress WordPress locked and limited conversation to collaborators Mar 28, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests