Cancel

Sarah Gooding

Gutenberg Team Publishes RFC Document on Widget-Block Interfaces

The Gutenberg team has published a Blocks in Widget Areas RFC (request for comments) document, detailing a technical approach that brings blocks to the wp-admin/widgets.php screen and the Customizer. This is one of the goals on the roadmap Matt Mullenweg outlined in his 9 Projects for 2019 post.

Based on the requirements outlined in the beginning of the document, it looks like the Gutenberg team is working to make the transition from widgets to blocks as seamless as possible:

  • Editing blocks in wp-admin/widgets.php and the wp-admin/customize.php should use the same block editor that wp-admin/post-new.php uses.
  • The block editor should read and update blocks in widget-editing areas via the REST API.
  • Upgrading WordPress must not affect the appearance of the user’s site, or any of their existing widgets.
  • Existing Core and third-party widgets must remain functional in the new block-based interface.
  • Backwards compatibility must be maintained. That is, themes and plugins that use public widget APIs must remain functional.
  • During a transition period, it should be possible to disable the block-based interface and return to the classic widget-editing interface.

The requirements for backwards compatibility are a tall order but will make it much easier for users to trust WordPress during this transition. Content will not be forced into the new interface and users will retain the option to use the classic widget-editing screen if they prefer. The team has not yet announced a date for when widgets will be officially deprecated.

Gutenberg version 5.4 was released last week with vertical alignment support for the columns block, a playsInline option in the video block, and a number of other minor enhancements. It also contains nearly two dozen bug fixes that will be rolled into the next beta of WordPress 5.2.

Gutenberg phase 2 technical lead Riad Bengella also confirmed in comments on the release post that the long-awaited section/container block is coming in the next release of the plugin. This will be an important milestone on the journey to full site editing with the block interface.

Category: ,
Tags: ,
13

13 responses to “Gutenberg Team Publishes RFC Document on Widget-Block Interfaces”

  1. For those of us who are hobbyists, and who have occasionally written roll-your-own widgets or theme modifications… is it simple to convert to blocks? For people like me who don’t speak php or JS fluently, a shallow learning curve would be appreciated. Gutenberg has enough idiosyncrasies (try converting a list block into regular text) already.

    Gary

    Create forum topic from comment

  2. I have 2 blogs which I run events on one. The purpose is to inspire and promote other bloggers thus I display the links for those that have participated in my weekly post. Tis a real tricky task to display the links correctly and becomes non-productive time wise.

    Also, scrolling is not smooth. The content in the blocks fades and jumps while typing, which is most irritating. I went back to the Classic Editor for this blog.

    With that said, I appreciate some of the features in Gutenberg and use it on my other blog. As long as I don’t have to deal with inserting several links, all is good.

    Bottom line is the user experience should be seamless and not a chore.

    Eugenia

    Create forum topic from comment

  3. My concern with “Phase 2” is that it was initially “Bring Gutenberg into the Customizer,” and was eventually reduced down to “starting with only widgets.” This shows that Phase 1 was still incomplete, and released prematurely as the majority of work that has been focused on in Phase 2 is not really overly relevant to this goal.

    This is a great step in converting widgets to blocks, and outlining a definite way for things to be done and why the solution determined is the way to go moving forward, but this to me doesn’t lend itself to “Phase 2” and seems like it should’ve been part of the overall roadmap in the first place. A lot of developers are very uncertain as to what Phase 2 will bring, and it’s not clearly being stated as to how it will impact plugins, and themes. I get the whole “well we don’t know yet” part of things, but at some point it needs to be known – otherwise work being done doesn’t have a real direction or purpose to a goal. It’s almost impossible for a theme developer to plan anything around Gutenberg, which was recognized from the first Phase, and many theme developers when questioned about integration have explicitly stated they chose to “ignore it”.

    In relation to the customizer, in December we had screenshots showing a proposition, and to date the next “biggest” update towards this goal has been a screencast of the same proposed idea, but not any code referenced in any of the discussions or repos that show what is being done.
    Reference to the originally proposed idea in December: https://make.wordpress.org/core/2018/12/08/gutenberg-phase-2
    A reference to the current proposed screencast: https://github.com/WordPress/gutenberg/issues/13205

    Yet it’s continuously being stated that rapid development happening has made Gutenberg stay on track and increase productivity. I don’t disagree with that, but I also fail to see how it’s “meeting it’s roadmap’s objectives and deadlines on time.”

    It’s also a bit concerning that two of the biggest contributors to the customizer’s recent state have iterated the same exact response to the initial proposal. “Why would you do it this way, and not use inline editing.” Reference to these remarks:
    Weston Ruter (much of the current state of the customizer API, and primary influence of the JS API): https://make.wordpress.org/core/2018/12/08/gutenberg-phase-2/#comment-35031
    Nick Halsey (responsible for menus added to customizer):
    https://github.com/WordPress/gutenberg/issues/13205#issuecomment-455435023

    I understand the reasoning, but the end goal of all this work is to get WordPress to a state of doing “frontend editing,” so why take a sidestep to change a UI and put forth work into integrating Gutenberg into a narrow window (customizer controls) when it’s intended to be used for editing content inline anyways. This is basically saying “we’ll do work now, and in the end it will all be thrown out because the next phase is to actually do frontend editing and we won’t need this anymore.”

    From a development perspective, there’s been no mention of how all these changes will impact the current customizer’s API for plugins and especially themes. This is the only API themes can really use, and if the goal is to replace this API, it’d be nice to get some information regarding this. It was asked in slack previously, but no information was ever supplied. You can reference the original conversation here: https://wordpress.slack.com/archives/C0381N237/p1543767795004900

    It seems like we have screencasts of active development efforts on bringing widgets to the customizer, but there’s not any publicly available code still. I guess this all just means that development of the feature is happening through “outside sources.” Any suggestions people have made to date have been discarded as “this is the goal for later, but right now we’re going to do what we want,” so community input hasn’t seemed to be very well accepted. I can only assume that this is possibly why there aren’t really any weekly meetings or activity happening in #core-customize on slack, and most of the questions asked there are pretty much just ignored.

    It’s a bit disheartening as I’m really looking forward to the functionality and feature set offered as being THE solution to bridge page editing and live site customizations.

    Create forum topic from comment

    • This is the only API themes can really use, and if the goal is to replace this API..

      Themes as we know them today will be history if Gutenberg will be complete as intended somewhere in future.

      Actually Gutenberg has to be considered as a fork of WordPress as it deeply changes the whole system, abandoning “old school” themes and complex template hierarchy in favour of a a few simple json templates with “allowed blocks” definition and trying to convert some plugins to blocks and establishing a block-repository, maybe one day also with paid premium blocks.

      People still fail to understand this long term concept and will argue “but Classic Editor”, but “Elementor”, but “whatever”, they will either have to abandon all that and move on with the “new” WordPress or stay behind, like some already do at 4.9.x, others as soon as Classic Editor will be phased out, or will leave to other solutions.

      Interesting times.

      Create forum topic from comment

      • “People still fail to understand this long term concept”

        Nah. Most people get the concept. They don’t appreciate a premature product shoved down their throats and having to deal with the liabilities that come with those bugs, quirks and fluidity. Believe it or not, some just don’t need the features.

        The internet is a massive and ever-growing place. The idea that one size does and should fit all is not only small-minded and short-sighted, it’s naive. If WP is moving from an adaptable everyman / everywoman tool, to a single-mind tool built by tech elites then that’s a sad moment in WP history.

        Create forum topic from comment

    • Hey Tim, thanks for your thorough comment! I believe that “clarity is kindness” so if the people working on Gutenberg (including myself) aren’t being clear, I appreciate you sharing that.

      Let’s first recognize that Gutenberg is a huge change for WordPress. With this comes a new paradigm – blocks. Phase 2 is really all about helping WordPress users, developers, designers, etc. adopt this block paradigm without completely changing all of WordPress. My efforts in this are to help everyone get there one step at a time. This means we might take smaller steps and remain on familiar roads for the time being. Converting everything to a block (ie. widgets), and adding these blocks into the familiar experience of the Customizer is part of this.

      I know this may not be the fastest path to an inline, full site editing experience, but I believe it’s the most considerate path forward. WordPress has just asked millions of users to learn a new thing, and I don’t want to push too quickly for them to learn another big thing. Phase 2, for me, is about working within the familiar patterns to bring this block paradigm into existing places where people interact with WordPress.

      I hope that brings clarity to the question, “Why are you doing it this way?”

      To answer your other question about where the active development is happening on the Customizer, it hasn’t really started yet. Moving Gutenberg into stand-alone editors that can be utilized outside of post_content takes some exploration to get right. There is a PR that’s helping to advance this in the wp-admin here: https://github.com/WordPress/gutenberg/pull/14612

      The screencasts you see for the Customizer are only prototypes of design explorations. No code has been written for that yet.

      I also want to note that if any suggestions haven’t been responded to, that’s my bad. I’ll address the comments you mentioned above. I haven’t been following #core-customize on slack, so I’ll try to do so. Most of the Gutenberg discussion happens in #core-editor.

      I really appreciate your excitement in bridging page editing and live site customizations. And I thank you for your patience. In order to ensure this bridge is solid, we need to lay down those foundations. We might even need to build structures that parallel and help shape the ultimate experience. Phase 1 was an amazing step forward that introduced a new paradigm. Phase 2 will help the adoption of this and bring everyone along the bridge together.

      Create forum topic from comment

      • My efforts in this are to help everyone get there one step at a time.

        With this approach you force everyone to continuously spend time to work on the site, checking compatibility of plugins, themes, installing updates, downgrade other updates, etc.

        But most of everyone just wants to use the website which they built or got built for a fixed budget and do not want to spend time and/or money again and again and again, but just post content once in a while or simply have the site static “as is” instead.

        All those “rapid development in live production updates every few weeks” geeks seem not to understand that – at all.

        Create forum topic from comment

      • Hey Mark,
        Thanks for replying back I appreciate you taking the time to do so! I don’t place blame on you or anyone in particular, for communication. It’s not just your responsibility, or even the team involved with Gutenberg’s responsibility. The lack of communication also comes from theme and plugin authors who are sometimes afraid to say things, or unsure where to go. It’s a two way street, and I hope more authors do get involved.

        I mean I have rendered some controls using react, and even managed to get some section/panel stuff implemented, but this will become a sensitive spot for theme authors. As mentioned by Frederike in his comment above, completely replacing this API or even heavily changing it’s underlying structure will severely impact a lot of themes. Theme authors – and I don’t think this is soley the fault of Gutenberg – were VERY unprepared for Gutenberg. Like you mentioned, “clarity is kindness,” and I believe Gutenberg is usually pretty open with it’s code, but it’s also enormous, and not a very welcoming place for outside collaborators. Theme authors just didn’t connect with it, and I think it’s pretty safe to say a lot of them were aware changes would be coming, but they also didn’t understand a lot of the changes. Many of them felt unheard when they tried working with integration as they noticed several things broken but didn’t really know how or where to report inside of Gutenberg’s repo. Even now authors are stating to their end users to use the classic editor, recommending the classic editor plugin in their themes, and flat out ignoring Gutenberg theme support stuff since most of the stuff is “opt in”.

        One thought I had to aide in this process was taking features that are present in Gutenberg and starting with some of those things. Yes, widgets are one area, but honestly there’s not many themes that are attempting to ever modify settings inside of widget controls via the customizer API.
        I think this is mostly because they are dynamically created, and they are unsure how things get where they need to be. Nav menus are the same way, authors seem to always build out their socialicon menus and not use WordPress’ built in handling for menus. They end up creating something custom for their own controls instead of utilizing the customizer’s menus like shown here: https://ps.w.org/customizer-social-icons/assets/screenshot-1.png

        While Widgets make a lot of sense from a block standpoint to actually get Gutenberg editor features into the customizer area, I think there’s more that needs to be considered with the level of knowledge and actual usage of the customizer’s API by theme and plugin authors first.

        I understand where the blocks angle comes from, but fundamentally authors use the customizer to provide settings for their themes. It would be much more beneficial to start with that simple fact for authors(not suggesting at all to discard Widgets though, more of a supplement to them).

        Gutenberg’s implementation for themes when it was introduced into core starts with specifically asking theme authors to opt in to support particular parts of the editor system. One area I think would be an immediate win and a minor feature to introduce then would be colors and the controls that relate to them.

        I believe that these points will help show how this would be beneficial:

        1. Introduces authors to react based controls. A lot of authors are still resistant to diving into JS, and this starts to force them to think this way more. More importantly it gives them some examples of how they can begin preparation on migrating their own custom controls into react driven components, which will help smooth the transition period for them.

        2. Fixes one of the most requested features for authors who embrace the customizer. I haven’t done much study on this topic, but I have witnessed 3 different authors who’s first custom control they added was an IRIS color picker with RGBA in their themes. I can only assume that it’s something that is commonly needed by others based on that. This would also reduce the dozens of various (and badly implemented) libraries used to add alpha sliders I’ve seen in .org hosted themes. Implementations ranging from random websites where they copy and pasted the code from, unlicensed repos, to large frameworks just to add this one simple feature since it’s not built in to IRIS.

        3. It’s an easy implementation, less work is always nice :)

        4. It begins to unify the experience between the editor and customizer. This is probably the one I consider to be the most important, and combine this with adding in the theme’s palette via theme_support that theme’s add for Gutenberg support, this could provide an interface for globally allowing users to edit the theme’s color palette. This will begin an important step in theme authors untangling some hardcoded colors per selector, and give users an easy way to change the palette for the whole site in a uniform way to maintain a set “style guide” for their colors. This palette could be available in the customizer, and would be the same palette that’s updated in their editor instances. In theory, the array of colors for add_theme_support could even become defaults the theme sets for number of colors and initial values this way, which would be a step towards not even needing to declare theme_support on this feature as it could be supported by default with a predefined palette, or even chosen via a random palette to provide variety for initial values in the future to help backfill themes that don’t supply a palette with a “prettier” set of defaults when the authors hasn’t supplied one.

        5. It will highlight some of severity of impact to theme authors (and customizer based plugin authors) without completely forcing a change at the beginning (if there’s any planned changes to the underlying API). I think about all the progress to the customizer’s JS API, and the time it took to get there. It wasn’t just getting there, but the time it took for theme authors to slowly ease their way in to utilizing the features it provides, and there’s still a large amount who are afraid to delve in.

        6. It would fix some wp core unresolved issues:
        An initial feature request for this:
        https://core.trac.wordpress.org/ticket/39681
        I believe this would also be resolved, but might need some adjustments in ColorPicker from @wordpress/components (haven’t looked at this in component in 6+months so I don’t know for sure):
        https://core.trac.wordpress.org/ticket/42078

        Introducing something like this now, or in the very least before/at the same time as widgets is something that should be considered. Aside from the things above doing something like this will provide a better user experience and solid expectation as UI elements become more unified not only for end users but also for developers of themes and plugins. As it stands, Widgets is a good entry point, but the only thing it realistically accomplishes is unifying that interface making for a better end user experience (which is still important). However, it really doesn’t help any of the authors/developers who rely on the customizer’s current state out.

        It’s possible I may have a misunderstanding, and maybe you can clarify on this a little if I am. The other possibility I have gathered from this is that widgets being the introductory point for blocks being integrated within the customizer are really only the starting point for testing the waters, and that’s all Phase 2 is now (in relation to the customizer). The goal for this change was only to get scripts setup, but we wanted to impact an area that is known to not have many modifications by plugins and themes via the customizer’s API to reduce any noticeable footprint. Then the next phase would completely remove any existing control pane (ie replaced by inspector) from the customizer and bring all controls into an inline editing experience. I don’t think you mean this though as you’ve mentioned about easing into things, and this way wouldn’t provide authors much in the way of preparation against such a leap.

        PS: Sorry if this isn’t the right place to ask for clarification. I can send something on the core-customize slack channel if that is preferred :)

        Create forum topic from comment

      • re: “With this comes a new paradigm – blocks”

        True. The problem is, you don’t seem to be realizing that that’s not the only paradigm that’s changing. And then to force feed those changes on everyone – as opposed to letting the market define what it’s willing to adopt – is shady, at best.

        Create forum topic from comment

You may also like

Newsletter

Subscribe Via Email

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