16 Comments

  1. Rodrigo
    · Reply

    (…) “so we need to make sure the Site Editor fills the gaps left by the Customizer”.

    I hope this means that we will eventually be able to add custom controls on the site editor’s screen via an API. Without this, there’s no way we can offer the same level of customization, which is currently avaliable on the Customizer.

    Report

  2. Matt Mullenweg
    · Reply

    “does leave one to wonder why so much work has been put into converting the sidebar/widgets system to use blocks over the past year”

    This is for all of the millions and millions of sites on a non-FSE theme.

    Report

    • Munir Kamal
      · Reply

      So that means this new FSE mode will only be enabled and controlled by a theme?

      Report

    • Justin Tadlock
      · Reply

      I still think it’s unnecessary. I’d leave non-FSE theme users with the traditional widgets system. I could be wrong (and often am), but I would think the users most interested in using block-widgets are going to be those who will also adopt FSE quickly. I’m sure there’s a sub-group in there that will want block-widgets but not move on to FSE for a few years. I know it is probably more in line with WP’s iterative approach to go this route, helping users along the path to eventual FSE. This will also depend on the theming community. We’re putting a lot of burden on theme authors by asking them to start adopting FSE while adding in support for new features for their older, classic themes. Of course, they can opt out, which is what many may do. It will be interesting for me to watch either way. :)

      The biggest thing that seems to frustrate a lot of theme developers is the lack of a roadmap that lays out some of these more technical changes. I don’t think they are asking for a timeline. They just want a general outline of major feature changes. Obviously, from that one discussion, one of the leading developers from the Themes Team seemed to be caught off guard with the plan and has several unanswered questions.

      The widgets system provides a good example of the need for at least a rough outline. If both block-widgets and FSE land in WP 5.7, some theme authors will want to just skip over widgets and start building FSE themes. Others may decide to continue building classic-type themes with block editor and widget support. An outline helps them plan ahead and make informed decisions.

      Report

  3. Munir Kamal
    · Reply

    I personally like the new direction of WordPress with Gutenberg. It’s the need for sure to make it future proof and align with the modern website builders.

    Of course, all these decisions are hard to implement and not every legacy can be retained.

    But, definitely, things need to be progressed well communicated so that the 3rd party developers can take proper action to make their these & plugins work with the new single app WordPress & also plan ahead on what to work on and whatnot.

    As in this case, I can see some theme developers are still working hard on building or upgrading the header/footer builder in the customizer and also improving that to use Gutenberg components in the customizer. If it will be deprecated, they need a clear announcement (I guess) so they know what things to work on making their theme future proof.

    That said, I personally think WordPress is heading in the right direction and it is opening up a lot more new opportunities for developers like me.

    Report

  4. Steve Truman
    · Reply

    “There’s a lot of interest in reducing the number of workflows, and I’m hopeful that we can consolidate down to just one beautiful, intuitive interface,”

    Amen to that. In my opinion try to build a hybrid / conversion / porting of Widgets and the integration / compatibility with FSE and site customizer has been a major mistake and has held back FSE development.

    Let it go – Gutenberg content editor and SFE are the one beautiful, intuitive interface. Traditional themes will be around for a while but will fade out as the FSE takes over, as long as we get on with it and stop trying top build something that supports every single existing WP user and theme.

    Sorry, I am frustrated by the continual delays in the development of the FSE.

    Report

  5. Steven Gliebe
    · Reply

    There are “special” things themes are doing that block-based widgets are not going to provide continuity for. I hope the Customizer, widgets, etc. are not deprecated. Existing themes need to continue working exactly as they do now, indefinitely.

    Otherwise, really, WordPress ought to have been rewritten from scratch rather than Gutenberg being worked into the existing project. I’m worried that backwards compatibility is not as important as it has been and that that’s going to be very inconvenient for site owners and theme maintainers.

    I am very excited about FSE, but only for brand-new themes – not existing themes.

    Report

    • Wouter De Backer
      · Reply

      I totally agree. I have worked on my websites and taught courses with the classic editor for nearly 20 years. I will not switch to the block editor. I am even in the process of moving my website at wordpress.com to another provider because they force me into the block editor. On my other websites, I’ll keep relying on the “Classic Editor” plugin and several widgets. If that is no longer possible in the future then I’ll convert my websites to another open-source CMS.

      Report

  6. Vasili
    · Reply

    Please leave the Customizer and Widgets as they are! I use themes on live sites where both, Customizer and Widgets, are important parts of these sites. I do not have the time or the will to make any migrations or re-coding this themes. Instead, make an option to turn these features off for people who do not want to use them. I guess there are millions of sites that will be affected by such, not really needed, change.

    Report

    • Justin Tadlock
      · Reply

      Just to be clear, widgets and the customizer will definitely still be available. They are currently disabled when a user activates a FSE-capable theme. Such a theme would not support widgets or customizer options anyway.

      Report

      • ClassicPress
        · Reply

        For how long? It looks like they would go away with the Classic Editor. If you want to ship an entirely different product, why didn’t you rebrand to something else? FuturePress or something? Switching the product while keeping the name is not the right way to transfer the users.

        Report

      • Rod Olman
        · Reply

        Considering that the Classic Editor is scheduled to be removed soon, what is the roadmap for widgets and the customizer to be removed?

        Report

        • Justin Tadlock
          · Reply

          That is one of the questions being asked — whether they will be deprecated. We are years out from a decision on that. These things are so fundamental to how themes work today that it will be a long while before that could really be discussed.

          Also, the lead developers were open about 2022 not being a set-in-stone date to remove the classic editor. When they evaluate whether to formally deprecate or remove it, I think they’ll push the date back. I’m not seeing the trends that would support the original deadline.

          Report

  7. Riad Benguella
    · Reply

    Hey there! Thanks for the post and for raising awareness about these updates. I’m happy to answer some of the questions raised here. We did have a lengthier discussion with Carolina Nymark on the #core-editor channel where we elaborated further. (Discussion linked on the PR)

    Even if the menu item is hidden, the customizer can still be accessed, will the options still work?

    Yes, the options will work properly but it’s not guaranteed that the access to the customizer remains but whether the customizer should be accessed or not when this lands in Core is something that is yet to be discussed.

    What role will the customizer have with FSE themes?

    As Josepha expressed, the ultimate goal of FSE is to simplify the admin, reduce the number of concepts WordPress has to deal with.

    The Site Editor and the customizer have the same capabilities but use different technologies. Having both at the same time can be confusing for users. The idea we are currently exploring is that the customizer as we know it today won’t have any role for FSE themes. The site editor would be the customizer of the FSE themes.

    Will it also be deprecated for non-FSE themes? How and When?

    No, I believe the customizer will keep working as long as WordPress supports non-FSE themes and I don’t see support for these ending anytime soon.

    How do I convert existing customizer options for my updated theme?

    A lot of customizer options are absorbed by Full-site editing blocks. For instance, you can edit template-parts right in your templates which is equivalent to widget areas capabilities, You can edit menus via the Navigation block, you can tweek the site description, logo via their dedicated blocks. You can also customize colors, fonts etc via the global styles panel. That said, extensibility APIs are needed in order to allow third-party global options. The current sidebar extensibility APIs and SlotFills available on the post editor are good indications of what these APIs might look like.

    This is actually one of the main reasons for this change in Gutenberg 9.3. We don’t really have all the answers today and as we move forward, things might change.

    We’d like to make it easier for theme developers and contributors to try Full Site Editing and the site editor, help us find the gaps, run user tests and address questions like: “What options are we missing by default” and “what APIs should we provide”.

    Report

  8. Ari
    · Reply

    A block-based theme (also called Full-Site Editing theme) is a theme that by definition uses the new site-editor screen to build layouts. In that screen, users have access to global styles where they can define things like background-colors, typography etc for their site, and they can build their layouts as they wish. So it makes sense to hide the links to the customizer & widget screens when such a theme is used.
    There are still a couple of things in the customizer that are not yet supported by global-styles, but these will eventually all be added. As for widget areas in an FSE theme, they are no longer necessary. Users can add a group block wherever they want, think of it as a widget-area and add blocks in there for everything their widgets used to previously do.
    Want a sidebar next to the content? No problem, just add 2 columns, content on the left and “widgets”/blocks on the right.
    Full-Site editing doesn’t deprecate anything. It simply abstracts the ideas a bit and allows for greater flexibility. We will essentially have an infinite number of widget-areas, wherever we want them in our layouts. They will no longer be called “widget-areas”, they are just content-areas where we can place anything, including widgets.

    As for legacy/classic themes, these won’t be affected at all. The customizer and widgets will continue working there perfectly fine.

    Report

  9. Mezie
    · Reply

    I absolutely agree with Carolina Nymark on the reception of this landmark changes on the part of the regular consumer. Go a bit farther with the PR this time, that should cudgel unwarranted skepticism around the new widget-lacking offers.

    Report

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: