Begin Prepping for Full-Site Editing With New Course on Block-Based Themes

Full-site editing is a mere half a year away from becoming a reality. The feature is expected to land in WordPress 5.6, scheduled for release in December. To prepare theme authors for this upcoming change, Carolina Nymark has created a new website and training course, aptly titled Full Site Editing.

Nymark has been a long-time theme author and contributor to the WordPress Themes Team. She has been a team lead or representative for several years and is one of the leaders behind the push for more accessibility-ready themes.

There are two major roadblocks that theme authors face right now. The first is that full-site editing is still in an experimental phase. The second is that there is not enough documentation, tutorials, and courses that do deep dives into this evolution of theming for WordPress. At least for the latter issue, Nymark has enough experience to do something about it, which is exactly what this new undertaking is all about.

After losing her job due to COVID-19, she wanted to use her free time to contribute back to the block editor. “At the same time, people around me started asking questions about full-site editing, and with the testing that I had done, I knew how to get started,” she said. “If I could share that, I could ease the process for others.”

Her representative role with the Themes Team also provided a unique insight into the uphill battle that theme authors would be facing. Nymark said she felt a sense of urgency with full-site editing looming ahead. “I only see a very small portion of the ecosystem — the WordPress themes that are submitted to be included in the WordPress theme directory; but most of the themes I see do not take advantage of blocks,” she said. “The themes do not style blocks, and the editor does not match the front. We as theme authors have not adapted fast enough to the block editor, and now there is another big change coming in six months.”

The course is available for free to everyone right now. However, that may not always be the case. Nymark is seeking sponsorship from people within the WordPress community. The idea is that they could fund the ongoing development of the course. If there is not enough sponsorship money available, she will need to turn it into a paid course. If that happens, she said the plan would be to go with a one-time fee model. Because of the frequent updates to full-site editing she wants customers to have access to the updated course material.

Developers who have a working knowledge of theme development are the primary audience for the course. Before anyone dives in, they should understand WordPress functions, PHP, HTML, and CSS.

What’s in the Course?

Screenshot of the welcome lesson/introduction to the full-site editing course.
Welcome lesson for the full-site editing course.

Currently, the course is unfinished. That is no surprise as the site editor is still half a year away from inclusion in WordPress. However, it does take theme authors through some of the basics they need to be familiar with before taking the next steps. The site also has an open forum that anyone can join and begin discussions on building themes from blocks.

The course is broken down into the following sections, each with its own lessons:

  • Introduction
  • All About Blocks
  • Block-Based Themes
  • Site Editor

Most lessons have a short video between two and five minutes. Nymark provides full transcripts of the videos for users who prefer to read. Along with the video and transcript, some lessons have downloadable material, such as code examples. At this time, there is only a single quiz for the “All About Blocks” part of the course.

Right now, the course covers only the basics. For theme authors who have already stepped into block-based themes, they might find some of the intro material to be a bit too low-level. However, they should expect more advanced topics going forward. For theme authors who have yet to dive into the block system, now would be a prime opportunity to catch up and begin prepping for the next phase of theme development.

Nymark is ready to add more content to the course soon, but it is an ongoing challenge staying on top of things at this point. “I have recorded content that I cannot use because of how fast the block editor changes, but that was expected,” she said. “My biggest concern is that I don’t want to spread misinformation, and that is difficult in this early stage.”

On the roadmap are example themes and slides that others can download and use for presentations during WordPress meetups. She is also building a parser that will create an improved block reference for theme authors to use in their templates.

The Road Traveled

There is a learning curve, even for someone as experienced as Nymark. She said it is still hard to picture how the template system will work when all is said and done. Because things are changing, it is an educational process as she builds out the course to teach others.

“The biggest confusion for me when I started was how the templates and template parts were saved,” she said. “When you edit and save a template in the site editor, it is saved as a custom post type, and that template will be used instead of the file that you have in the theme. Currently, if you change themes, the block structure that you have saved in the template is used, but it is styled by the new theme. This is why it is so important that theme authors style and test blocks.”

For theming, particularly one-page sites or blogs, the structure of the theme is likely to be much simpler than what we see today. Nymark said the new system, while under active development, still feels familiar enough to make the transition from traditional themes easy. The big difference is between making fewer decisions regarding custom JavaScript and PHP with more work toward design.

“The downside to this is that, in the beginning, I think we will see less variations in the themes,” she said. “Once the first excitement over playing with new toys passes, this might feel limiting. Block patterns will play a major role and I am looking forward to using them soon.”

For theme authors who are dipping their toes into the full-site-editing waters for the first time, she suggests starting by recreating headers, footers, and other small sections as block patterns. It is enough to get your feet wet without diving in headfirst.

Her second recommended step is to start thinking about how to convert customizer options to the block system. For example, when thinking about the various header options that many themes have, it may be worth creating block patterns to expose those user choices through the full-site editor.

The Road Ahead

Nymark identified several areas that need to be addressed going forward, namely documentation. “The general lack of documentation is a problem, not only for full-site editing but for the entire Gutenberg project,” she said. “It makes it difficult for people to learn and contribute.”

One key feature she would like to see is the ability for theme authors to lock templates to keep users from accidentally removing critical blocks that provide functionality to their websites.

She also listed several necessary components that are under development by the Gutenberg team but are not ready yet:

  • Selecting and creating template parts in the site editor.
  • Finalizing the global styles feature.
  • Updating existing full-site editing blocks with more controls.
  • Creating new blocks for remaining template tags.
  • Improving the Navigation block so that it is responsive.

There is still a lot of work to be done and many questions are still in the air. However, there is hope for a brighter future as WordPress moves toward a common design language through blocks.

“It will be easier for designers to create layouts without concern for the code,” said Nymark, “and once templates can be exported it will also be easier to share those layouts as themes. The barrier of entry will be moved; it will be easy to create a basic theme, but it may be more difficult to create complete solutions for users.”

9 responses to “Begin Prepping for Full-Site Editing With New Course on Block-Based Themes”

  1. “The themes do not style blocks, and the editor does not match the front. We as theme authors have not adapted fast enough to the block editor, and now there is another big change coming in six months.”

    How we are supposed to adapt our themes fast enough to the block editor if, for example, there is no summary of all the CSS classes that need to be styled for each block anywhere yet? This is something that many have asked for in the GitHub repo without success.

    • I cannot count how many times I’ve asked for reference documentation for classes and containers to apply to my theme’s block editor stylesheet. Trying to figure out the overloaded nested divs in the editor is a nightmare. Then there are many elements that no matter what you do to change the style, the core styles still cancel you out.

      Trying to get the theme front-end styles to match in the editor is an ongoing issue.

      There is also the problem of so many changes that happens with the “plugin” version of Gutenberg, that one has to design/develop a theme for several versions…and I’ve listed this before many times:

      Classic Editor
      Core Block Editor
      Gutenberg plugin

      Yes, three different environments to manage. Now, with what is coming, it just adds to the messy complications of adapting themes (new and old). How many more versions of the GB plugin will there be? Personally, the plugin needs to end and keep all GB development to the core.

      I still say to this day…and have since the beginning of GB…Matt (Automattic) should have built a completely separate WordPress that is built around Gutenberg and then leave the original WP intact as the Classic WP. Yes, it means two WordPress versions, but due to the complexity and completely different concepts, they should have been separate.

      • Your point about documentation is valid but as a developer it is not difficult to use the Inspector to learn the underlying markup and use your discernment to see what the best selectors to use are, just as you would when styling any other 3rd party applications.

        The good news is in WordPress 5.4 the markup and CSS of the editor got a lot simpler, so you should have an easier time learning what needs to be done. If it’s any consolation, I was able to rewrite the Editor Styles of my own theme for WordPress 5.4 in about three hours and now my user’s enjoy a just about perfect live preview writing experience.

        I was frustrated like you when I learned I needed to do a styles rewrite, but that was the kind of thing I expected to happen when I chose to support GB with editor styles and custom blocks. I am hoping not to have to do this again for a long time, and considering I first wrote my styles back in WP5.0 and didn’t need to touch them until recently, I am optimistic about the longevity of this rewrite. That I will give GB team the benefit of the doubt for as the editor has overall been a net positive for my customers.

        I have my own gripes about the editor and think I will have even more as it gets more invasive but as a longform post editor it has been nice to use.

        Lastly, and I don’t mean to pick on you, but I think that you having trouble with the “multiple environments” of GB/classic editor (assuming you are referring to meta boxes) is more of a reflection on you than the editor being bad.

        If we took that same logic and applied it to responsive design we would still see most sites don’t support tablet and mobile views because “they shouldn’t have to,” so why wouldn’t we develop our theme and plugin features to work in any environment as well?

        • My “gripe” is more about documentation or lack of as it relates to theme development for the back-end editor. Also, using the inspector to view markup does not always work well without doing some hacks. Regarding multiple versions, I don’t make multiple themes for each, I integrate it all into one theme to cover the classic, block, and plugin versions. I even give the user the option to disable the GB stuff to lighten the load. As a side note, I even make the themes compatible for ClassicPress. Basically, many environments rolled into one theme.

    • I don’t think Carolina meant that necessarily in a negative context toward theme authors (being one herself). I think she’s saying that’s simply the situation we’re in. She’s going to try to do her part and bring folks up to speed, so come along on the journey. We have all been asking for more documentation. Here’s someone willing to put in the work to make that happen.

  2. So 6 months out there are still gaping holes, an undecided feature set, almost no documentation and the block editor itself is still in huge flux with fundamental UX and UI issues. Full site editing is shaping up to make the v5 release look smooth….

  3. I’m really glad someone is trying to make sense of this. I just wish it was one of the people responsible for it!

    Look forward to see how this resource develops, it was a helpful read.

  4. Firstly I’d like to say that I’m super excited for the full-site editing capability. Despite all the stick it gets, Gutenberg needed to happen and is a great tool – one that we are all embracing and developing new blocks, plugins and themes for.

    Having said that, my experience with developing for the block editor for clients across several different versions of Gutenberg has been frustrating at times due to the lack of a frozen feature set and poor developer documentation. We just about get our heads around one way of doing things only to find it torn out in the next version with poor updates to the Gutenberg handbook.

    Features are great, but only with the documentation to back them up. One of the great aspects of the PHP side of WordPress is the stable core allowing you to develop knowing that your plugins and themes are unlikely to break with every other version release. This approach sadly hasn’t made it into the Gutenberg side of things. If full site editing also represents a minefield for many developers, they are unlikely to adopt it and develop themes for it.

    Maybe slowing down a little and allowing the documentation & community to catch up whilst ensuring things don’t drastically change so much version to version is more important right now.

    I think it’s fantastic that Carolina is trying to fill that gap with a much needed course. Kudos to you Carolina!

    • Ditto, I’m reluctant to invest time into learning and developing anything ‘seriously’ until they reach some island of stability however I have no idea when that’ll be or if it’s even planned. Lack of documentation says to me lack of spec [since my spec’s usually forms the basis of the docs] and lack of spec means lack of clear direction and goals. This unfortunately really shows.

      My beefs are not directed toward Gutenberg, it’s general concept or FSE for that matter. My problem is with the management, communication, direction etc well basically everything else. A total props to Carolina but this isn’t a gap she should have to fill, it’s the team ramming this through.

Newsletter

Subscribe Via Email

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

%d bloggers like this: