What Is Full Site Editing and What Does It Mean for the Future of WordPress?

Block-Based Twenty Twenty-One Theme in the WordPress site editor.
Block-based Twenty Twenty-One theme in the site editor.

As I said last week, 2021 will be the year of the site editor. Matt Mullenweg’s State of the Word confirms it. WordPress 5.7’s release planning is focused on it. It has been a long journey getting to this point, and it will be a much longer adventure afterward. The ultimate promise of the work that began nearly four years ago is nigh.

The Gutenberg project was never just about editing content. WordPress was aging software by late 2016. It needed to cater to modern audiences who may be less tech-savvy than the platform’s existing user base. It needed to capture a younger generation of developers who were looking at the greener grass of JavaScript-heavy software. It needed to offer an experience on par with modern web applications. WordPress had a lot of boxes it needed to check or face irrelevance.

The one thing that has truly kept the platform afloat is its large and diverse ecosystem of third-party developers.

One of the most popular types of plugins? Page builders. Those such as Elementor, which launched in early 2016, were filling in the experience gaps that WordPress was missing. While it was a testament to the platform’s extendibility for such third-party projects to arise, it was also a failure that the core platform could not offer a better experience to both users and developers out of the box. Far too many theme authors were forced into supporting third-party builders to remain relevant. They were focusing more and more on compatibility with plugins than simply designing.

The shortcomings of the widgets, shortcodes, meta boxes, and settings systems meant that developers had to either rely on non-core frameworks or reinvent the wheel. Every new API brought with it a new method for adding basic form fields. At best, it was inelegant, a platter of spaghetti that had been thrown at the wall, some of it managing to stick.

WordPress was beginning to show its wrinkles. It needed to revolutionize itself. It needed to feel fresh again. For better or worse, the developers behind the Gutenberg project have been putting in the work to do just that.

It is slow work. But, it is promising work.

While the term “Gutenberg” is often used interchangeably with “block editor,” the two are not one and the same. Gutenberg is a project. A plugin. An idea. A new way of thinking about publishing on the web. As the opening lines of the description of the plugin read:

“Gutenberg” is a codename for a whole new paradigm in WordPress site building and publishing, that aims to revolutionize the entire publishing experience as much as Gutenberg did the printed word.

The project has four phases:

  1. Easier Editing
  2. Customization
  3. Collaboration
  4. Multilingual

WordPress users who have not been testing the Gutenberg plugin have only experienced Phase 1 of the project. The launch of the block editor in WordPress 5.0 and its continued work set the stage for the phases to follow. The underlying block system is what will fuel the next decade or longer of WordPress.

Today, we are firmly in the midst of Phase 2. And, this is where things will get interesting.

Full Site Editing

Block-Based Bosco WordPress theme in the site editor.
Selecting a template in the site editor, using the Block-Based Bosco theme.

Phase 2 of Gutenberg, which began in late 2018, promised to bring blocks outside of the post content. In an introduction to this next step, Mel Choyce-Dwan outlined the three main focuses:

  • Be outside of post_content.
  • Focus on customization.
  • Upgrading themes, widgets, and menus.

Since then, those core concepts have remained the same. However, the full picture, the shape of what those concepts would look like, has changed in the last two years. If there is one thing anyone on the development team has learned, it is probably that it is hard to launch such drastic changes.

Full Site Editing is a mix of concepts. It is one part transition from tradition and one part full overhaul of how users and developers design the front end of WordPress sites.

Nav menus and widgets, which are a part of the old paradigm, have been set to relaunch under the block system for the past two major WordPress releases. They were not ready. Users should expect to see them in WordPress 5.7. However, these feature upgrades are merely stepping stones to true the true Full Site Editing feature. They offer a way for end-users who are still using classic WordPress themes to get a taste of blocks outside of the post-editing screen.

For the users who take the next step, widgets and nav menus — at least the traditional admin screens — will disappear. The customizer, which was once touted as the future of theme development, is also getting the ax. Site customization via a system where everything is a block will reign supreme.

Once the switch flips, the world will be looking at a whole new WordPress.

WordPress 5.7 and beyond will be about the site editor and block-based themes. The site editor is the visual representation of block templates that theme developers offer to users. Templates are infinitely customizable by the user from the WordPress admin. While themers will create custom configurations and set defaults, the power to decide what the front end of the site will look like will ultimately reside in the user’s hands.

Since the launch of Phase 1, the block editor has been a love/hate affair. Expect the site editor to be no less controversial.

Underneath it all, a theme’s code and the site editor will be talking in the same language. This essentially means that users could transition to theme authors if they have a knack for design or simply want to give it a go. They should be able to do this without leaving the comfort of the trusty site editor, which already allows exporting templates.

Because the post editor and the site editor both work on the same, underlying block-based foundation, there is no reason for users to not be able to seamlessly switch between the two. There is currently a ticket for adding such a toggle on the post-editing screen. It will allow users to switch to a template-editing mode while never leaving the post editor.

Toggle button for switching between post and template editing
Template-editing mode likely to land in Gutenberg 9.6.

This is not a newly-introduced concept. Josepha Haden, who led the WordPress 5.6 release, touched on this earlier this year. “I think one of the problems that we’re trying to solve with Gutenberg has always been a more consistent experience for editing elements across the WordPress interface,” she said. “No user should have to learn five different workflows to make sure their page looks the way they imagined it when it’s published.”

One of the larger goals is reducing the number of workflows into a single interface. We are likely years away from seeing the whole of WordPress site management reduced that far. However, the site editor is the next step toward that potential user experience.

What Does All This Mean for the Future?

While the last few years may have felt like a whirlwind of changes to our beloved platform, you ain’t seen nothing yet. We were just getting our bearings in Phase 1. The development team was building the foundation while also launching the user-facing block editor. With that foundation in place, the team can focus more on features. This will especially be true as the G2 Components project overhauls and standardizes how core and third-party developers build upon the block system.

The big Phase 2 changes this year means that theme authors will need to get up to speed. Traditional WordPress themes will still be necessary for a while. However, any theme author who is not already tinkering with block-based themes is already months behind. This is the time to be exploring and helping to shape the system. It is time to be filing bug reports and feature requests.

If possible, theme authors should be attending the twice-monthly block-based themes meetings. If time does not allow for attendance, you should at least be reading and participating on the Make Themes blog.

It is also important to check out projects like the Q theme or follow the Theme Experiments repository.

Carrd theme experiment in the site editor.
Carrd-like theme experiment from the site editor.

For end-users, this entire project is about you. Your feedback is crucial. If you are not already testing your site with the Gutenberg plugin, you should be. It is sometimes weeks or months ahead of what you are getting with WordPress alone. Try out an FSE theme like Block-Based Bosco. Consider joining the FSE Outreach Program. You can test and provide feedback directly on upcoming features.

FSE brings with it the promise of major changes in 2021. Many of these changes will uproot old methods of managing your WordPress websites. Those methods will be replaced with one of the largest overhauls to the platform in its history. It is time to get prepared.

It is going to be an interesting new year.

22

22 responses to “What Is Full Site Editing and What Does It Mean for the Future of WordPress?”

  1. As a designer/developer I’ve embraced Gutenberg and use it for all my new projects. I’ve already found Gutenberg to be quite limiting when it comes to creating unique and compelling designs. A lot of my design focus has switched to the themes header/footer layouts.

    With the introduction of FSE I feel like those limitations are only going to be increased. Maybe I don’t fully understand it yet, but I’m not even sure how I’m supposed to create a standard menu on desktop, which then switches to a ‘hamburger’ toggle with a popout/overlay animation on mobile.

    I hope I’m proven wrong.

  2. The elephant in the room is that WordPress has large architectural problems and missing backend apis.

    The problem is these issues are not being tackled at all (or even acknowledged) atm. As sadly the community is obsessed by Gutenberg. Which for all its coolness will only ever be a presentational tool.

  3. As a developer I love to experiment new things and I did so with Gutenberg and the whole block system. But when it comes to clients’ projects sometimes the time frame is tight and a “real” how-to guide would have been very handy: in my opinion that was missing for custom blocks apart from a few (not so useful for me) “hello world” examples. Therefore, since Gutenberg appeared on the scene a lot of my time was used in finding solutions with a trial-and-error approach or trying to understand the whole thing by reading (a ton of) code. I don’t think it was a waste of time, on the contrary, I would have found it useful if only I had the time to enjoy it!
    That said, I really hope that for FSE there will be also a good guide for developers to get the most out of it while enjoying the learning process.

  4. Hello, folx! Thank you for picking up the planning roundup post. Quick clarification – that I also added to the post – Full Site Editing is not THE scope of the release. Bug scrubs have started on December 15, and once everyone is back from a much-deserved winter break, there might be other items popping into the radar. Full Site Editing is a whole Gutenberg phase, so naturally, it will span over multiple releases.
    As per Nav Menus and Widgets being completed for 5.7, I couldn’t find any confirmation of this timeline. Can you point me to the source? I might have missed something!

  5. I manage a large corporate network of WordPress sites. One of the strengths of WordPress now is the ability for us to lock down the design while allowing the authors to easily add content. We can (relatively) easily reuse, migrate and repurporse content because we don’t use page builders.

    I realise that this isn’t the use case for the vast number of small sites out there, but the corporate and government world is subject to much stronger restrictions.

    I would hate to see that capability lost from core WordPress.

    • Keeping design & content strictly separated has been the purpose of every CMS since the early days. This basic principle ensures the longevity and transportability of our content. Every blog / magazine owner relies on it. WordPress gave us a good 15+ years of this reliability. I hope as well as you that this does not get sacrificed for the „democratizing design“ agenda. Happy holidays!

  6. I get that theme developers should be getting ready for the change; but what about us hobbyists? What we (I, certainly) need is a list of equivalences and functions and calls (a bit like the list I did of blocks and styles the other month), so that we can see how our hand-built themes can be converted into block-based themes. We don’t all farm that aspect of our sites out ;-)

  7. Well here’s my two cents. As developer I took it upon myself to switch for every editor on to Gutenberg because let’s face it, it’s soon to be native to WordPress, but as the editor is in its infancy state, it’s got room to grow. This is where ACF Pro comes in for me: I am able to take any design at any complexity and develop custom blocks built for Gutenberg and my users can build their own pages with my blocks. This helps keep designs nearly perfect based on any XD Design that is put in front of me.

    If the new update will ease this projects that is great. But I don’t see that happening based on anything custom.

    In 2021, ACF Pro! This is “still” the ways

      • Only static components that do not require editing. Take for example the Header / Footer of a page, those never change, hence, require no standard user adjustability. The context is changeable but the component itself, isn’t.

        I used to work directly with Flexible Content within ACF Pro but now transitioned to ACF Custom Blocks due to their native nature of integration on to WP. I would like to see something native from WP that either replaces this process or aids it.

  8. Bring it on.

    I’m only worried about the abandonment of the customizer, widgets, and menus because those are integral to “universal” theme elements–even in our themes that are all block-based. Keeping our themes from the repo in compliance with all the theme review requirements for blocks, sample content, etc., is a lot of work–especially with markup changes that happen with each release to the block editor.

    That said, the end-users are the ones who benefit most from the changes to how WordPress content is managed, and those are mostly my clients, who have been VERY happy with all the visual editing tools and templating abilities that come from the block editor. Seeing their eyes light up during training on the block editor and seeing them update their sites more often with more content that’s better designed and more engaging is what I signed up for, and it’s starting to really pay off for me, at least.

    I’m definitely worried about the workload but excited about the possibility of winning over more potential theme users who currently rely on Elementor or other bloated tools.

    🤘

  9. i feel non techy users have had trouble using gutenberg vs classic editor, a good % of them had to enable to classic, one client didnt know classic editor existed, and planned on ditching the wordpress platform completely because of gutenberg.

    myself i prefer classic as well, i feel i can write up a post much faster using classic editor, hopefully they keep classic up to date and working through 5.7

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.