Porting Widgets to Blocks: Feb 18, 2019

All widgets we plan on porting to blocks have been merged! 🎉

Completed

Iterations

We have a couple of the more advanced widget blocks with v2 designs. These are “nice to haves,” but not necessarily scoped to any particular release.

In Progress

Needs Feedback & Dev

Notes

#blocks, #gutenberg, #widgets

Porting Widgets to Blocks: Feb 4, 2019

There’s been a ton of work on porting widgets to blocks since my last update! Here’s where we’re at:

✅ Completed

✏️ Work in Progress

  • Classic Widgets [13511]
    • Could use some additional testing, thoughts, and reviews.
  • Search [13583]
    • Needs a final code review and sign-off.
  • Tag Cloud [7875]
    • Getting close! Could use some more code reviews and testing.

⌨️ Needs Dev

The following iterations on existing widget blocks are “would-be-nice-to-tries”:

  • Archives [1464]
  • Recent Comments [1792]
  • Recent Posts [1594]

🗒 Notes

  • There’s an estimated ~4 weeks until this project is finished.
  • The Classic Widget [13511] is going to be moved into the “widget area Gutenberg support” project, since it impacts all of the widget screens.
  • The Meta Widget [13335] issue has been closed in lieu of adding login/logout and RSS subscription support to the navigation menu block.
  • You can track progress on GitHub: https://github.com/WordPress/gutenberg/projects/20

#blocks, #gutenberg, #widgets

X-post: Iterating our design workflow keywords in trac

X-comment from +make.wordpress.org/design: Comment on Iterating our design workflow keywords in trac

Status Update: Porting Widgets to Blocks

Per 9 Projects for 2019, all widgets will be ported over to Gutenberg blocks. I went through and audited how close we are to completing this goal:

✅ Completed

  • Audio [2299]
  • Archives [7949]
  • Categories [2102]
  • Custom HTML [1391]
  • Image [379]
  • Latest Comments [7941]
  • Latest Posts [870]
  • Text
  • Video

✏️ Work in Progress

🖼 Has Design

  • Calendar [1462]
  • Classic Widgets [4770]
    • Any existing widget will work by using the Classic Widget block.
  • Navigation Menu [1466]
    • This has a bunch of design ideas, but not a finished design. This block design is still a WIP.
    • Note: This is also its own 2019 project.

Additionally, the following completed widget blocks have v2 designs:

  • Archives [1464]
  • Recent Comments [1792]
  • Recent Posts [1594]

⌨️ Has PR

🙅🏽‍♀️ Deprecate?

There’s a couple widgets that I personally think can be deprecated:

  • Meta: Feels anachronistic and out-of-place in modern WordPress.
  • Pages: Should be replaceable with a navigation menu block.

Next Steps

Given this list, I think our top priorities are:

  1. Reopen, finish up, and merge existing widget block PRs.
  2. Create a PR for Calendar — maybe two: one following the original design, and one following the more complex v2. The original can likely be completed and merged quickly, which would put us in a great place in terms of widget support.
  3. Review the Classic Widget block design to ensure it matches current Gutenberg patterns, and create a PR.
  4. Create v2 PRs for Archives, Calendar, Recent Comments, and Recent Posts. Having a working PR can help us establish whether or not the designs are feasible, and a better experience.

Navigation Menu, as a broader block that extends beyond just widgets, should be tackled separately from this effort.

@karmatosed has created a new GitHub project we can use to track progress: https://github.com/WordPress/gutenberg/projects/20.

#blocks, #gutenberg, #widgets

Gutenberg Phase 2

Phase 1 of Gutenberg was intended to make post and page editing easier and more flexible for users, leveraging blocks as the main mode of interaction offering greater virtuosity, especially for non-technical users. The next phase seeks to expand this idea beyond the post, allowing editing and customizing the rest of a website in WordPress. This process also aims to eliminate the complex obstacles users have to find their way through — like multiple layers of abstraction and navigation — and to reduce the amount of technical knowledge required to customize the overall appearance and functionality of their site. 

The next phase of Gutenberg will take the ease of use that was introduced with block-based editing and extend that capability to the Customizer, starting with widgets, to make it easier for users to customize the rest of their sites.

In the first step of phase 2, we will bring blocks into the Customizer to create a more consistent user experience and give developers a smoother path to upgrading themes to Gutenberg. Longer term, we will expand the current Gutenberg post and page editor to become a full-fledged site editor, bringing everything together into a unified, modern product experience.

If you currently have a site like this and you want to edit any of these widgets that aren’t part of the post content, you have to use an interface like this:

It’s really disconnected from anything you see on the front end of the site, it requires you to sort through a list of widgets on the left and then know how to drag and drop them into these different widget areas on the right. More to the point, if you think about widgets, they kind of represent a really early idea of blocks — they’re discrete areas for content and functionality that you can add to your site. But now with Gutenberg, we have a much more advanced, elegant, and robust concept of blocks and how you interact with them.

The first step for phase 2 will involve upgrading the widgets UI to incorporate a modern block editor that is consistent with how you edit pages and posts in Gutenberg to create a clear, consistent editing experience across different areas of your site.

Widgets

In widgets.php

widgets.php would become something more like this, which is an early sketch, but you can see that all of these widgets are represented as blocks.

In the Customizer

Menus

We’re currently still investigating a number of ways that we might improve the menu management experience. 

In nav-menus.php

Inline

Editing blocks in-context

Once we have converted widgets and other elements like menus into blocks, what we can do in phase 3 (or 2+, depending on how things go) is to bring all of these elements together into a full site editor, where you no longer have to hunt for controls in the customizer menu, but can instead just edit blocks like menus and widgets in place on your site.

Instead you could add blocks wherever you need them to go and see them previewed in context. Once we bring this all together we start to realize a vision of WordPress making the web fully editable in a way that is powerful, flexible, and accessible to everyone from beginners to experts.


To recap, Gutenberg Phase 2 will:

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

Early version of phase 2 will be in the plugin. Be sure to reactivate it!

X-post: Gutenberg Usability Testing at WordCamp US

X-post from +make.wordpress.org/test: Gutenberg Usability Testing at WordCamp US

WordPress 4.9 Goals

Here’s a draft of the tickets and improvements that we’re looking at improving in 4.9:

  • Code editing improvements:
    • Better code editing experience (Plugin on GitHub).
      • Theme and Plugin editors (#12423).
      • Custom CSS in Customizer (#38707).
      • Custom HTML widget (#40907?).
    • Safer file editing:
      • Linting code changes: prevent saving, or add confirm message (#41073).
      • Add better warnings when you’re editing themes and plugins (even if they’re not active) (#31779, #41078).
    • Add nested folder structure deeper than 2 levels (#6531).
  • Customization improvements:
    • Changesets (Plugin):
      • Drafting changesets in the Customizer (#39896).
      • Scheduling changesets in the Customizer (#28721).
    • Homepage settings (“Page on Front”, #16379-ish).
    • Gallery widget (GitHub issue, #41914).
    • Add media button to Text widget (#40854, see convo in #32417).
  • Better theme switching:
    • Better widget mapping when switching themes (#39693).
    • Better menu mapping when switching themes (#39692).
  • Updating a plugin or theme via a ZIP file (#9757):
    • Needs input from updater component maintainers.
    • Also, drag and drop uploading of themes and plugins (#24579).
  • Media:
    • Customizer image dropzones (#35827).
    • Responsive images in the Customizer sidebar (#36191).
    • Stop forcing people to crop images that don’t need to be cropped (#36441).
  • REST API:
    • Getting in API endpoints that Gutenberg needs.
    • Will comment with more details.

This is quite a few items, so we might not be able to accomplish this all within 4.9. This is what we’re thinking of working on, though. 🙂

Check out the 4.9 development schedule.

#4-9

Image Widget Merge Proposal


As part of this year’s Customization Focus, @westonruter, @obenland, @adamsilverstein, @timmydcrawford, @gonom9, and I have been working on creating an image widget for core. This new widget lets you quickly and easily add an image to your site’s widget areas.

You may have previously seen this come up as a media widget on Trac, before we decided to split the widget up into individual media-focused widgets. Having single widgets makes them more discoverable, and eases the way forward for similar blocks in the Editor. The image widget is the first in a series of media-focused widgets we’ll be introducing to core.

You can check out the widget on GitHub, install the plugin from WordPress.org, or check out the Trac ticket.

Why make an image widget?

People want to add images to their widget areas. Visit any subject blog across the internet and you’ll likely find images in the sidebars. People add photos of themselves along with bio blurbs, link to their books, promote upcoming events with graphics, partner with other blogs and exchange ads, and add call-to-actions using images.

The current process for adding an image to your widget areas is quite painful. You need to:

  1. Upload or select an image in your media library.
  2. Copy the image URL.
  3. Go to the widgets admin screen, or the widgets panel in the Customizer.
  4. Create a new Text widget.
  5. Add the image to the Text widget using HTML, which is often a barrier for new or non-technical site maintainers. (See #35243 for work to add a visual mode to Text widget.)

This is a huge barrier to what should be a relatively simple task. This new image widget makes it much easier to add an image to your widget areas by natively integrating with core’s media library.

How is it implemented?

There hasn’t been any new widget types added to core in a long time; the Custom Menu widget was the last widget added in WordPress 3.0—almost 7 years ago! (The core themes Twenty Eleven and Twenty Fourteen did include their Ephemera widgets since then.) Since widgets are a very old part of WordPress, widgets in core have been very much entirely built using PHP with some Ajax sprinkled on top. In the time since WP_Widget was introduced in 2.8, WordPress has made dramatic shifts toward developing interfaces in JavaScript, including with the Customizer in 3.4 and the Media Library in 3.5, and more recently with the focus on the REST API.

Given that the media widgets are naturally interfacing with the media library JS, it is necessary that the media widgets make use of JavaScript to construct their UI instead of relying on PHP. Initial groundwork for shimming JavaScript into widgets was added in 3.9 via the widget-added and widget-updated events. A more recent proposal for making JavaScript more of a first class citizen can be found in #33507 and the media widgets incorporate some of its patterns that were also prototyped in the JS Widgets plugin. The media widgets make use of a Backbone View to manage the widget control’s UI and a Backbone Model for reading and manipulating the widget instance data.

Another unique aspect of how the media widgets work is how instance data is sanitized. Normally widgets write procedural code to sanitize instances via a subclassed WP_Widget::update() method. The media widgets, however, make use of a REST API schema returned from WP_Widget_Media::get_instance_schema() to sanitize instances declaratively. The WP_Widget_Media::update() method iterates over the schema and uses it to sanitize and validate the instance properties. Adding schemas to the base WP_Widget class is also proposed in #35574.

Please test

Please test the image widget. For now, you can grab the latest version of the widget on GitHub. You can either check it out locally using Git, or download a zip by clicking “Clone or download” → “Download ZIP.” Alternately, you can download the nightly version of the plugin from the WordPress.org plugin directory.

#image-widget, #media-widgets

Customization Meeting Notes: January 23, 2017

From today’s #core-customize meeting:

Thanks @iandstewart for help with notes. Drop by #core-customize next week on Monday at 1:00pm EST for the next full meeting, or join us at the same time tomorrow for ticket triaging.

Customization in 2017

The editor will endeavour to create a new page and post building experience that makes writing rich posts effortless, and has “blocks” to make it easy what today might take shortcodes, custom HTML, or “mystery meat” embed discovery.

The customizer will help out the editor at first, then shift to bring those fundamental building blocks into something that could allow customization “outside of the box” of post_content, including sidebars and possibly even an entire theme.

Matt

One expectation I want to start with is, customization isn’t just improving the Customizer — our goal is to improve the entire process of setting up a site, from initial installation to something you’re comfortable launching, to making changes to an existing site that has been live for some time. To that end, our goal is to help people accomplish the following:

  • “I want to make a site that I’m proud of that helps me succeed.”
  • “I want to make a site my clients are proud of that helps them succeed.”

The current customization flow in WordPress doesn’t generally facilitate either of those goals without a great amount of work, prior knowledge, and often a lot of additional development. That’s fine if you’ve hired an agency, or you’re a developer building yourself a website — but not fine if you’re a freelance site builder/implementer (a market I see every day in my local community) or are trying to build something for yourself with limited time and budget. If you can install WordPress, either manually or through a host, we should provide you with the tools to build out a website that accomplishes your personal and business goals.

With these goals in mind, what can we accomplish in the first couple months of the year?

  • Demo content on theme switch for an existing site. [#38624]
  • Pain points with lost widgets and menus when switching themes. [#19912]
  • Exploring a better customization-focused onboarding experience.
  • Adding an media widget. [#32417]
  • Adding formatting options to the text widget. [#35243]
  • Adding a code editor to the Custom CSS control, and make additional enhancements. [#12423, #38707]
  • REST API endpoints. [#39634, #38900]
  • Improving Custom Logos. [#38329, #36191]
  • Some more minor Customizer improvements [#37471, #38953, #39389] and continued bug fixing.
  • What else? Please comment.

Throughout the rest of the year, there’s a lot of larger projects that we’ll collaborate with the editor team on:

  • Content blocks, so we can build a better layout editor that helps people build a site that fits their individual needs. [Post]
  • Revisions, so you can visually see the changes you’ve made to your site and revert if you mess up. [#31089, #21666]
  • Drafting, reviewing, publishing, and scheduling changes, so you can get your site looking just right before you push your changes live. [#31089, #28721]

Some of these, like revisions in the Customizer, we can prioritize sooner.

By the end of 2017, we hope you’ll be able to:

  • Have an onboarding experience with smart defaults that guides you towards building the site you want, faster.
  • Build complex, dynamic layouts for your WordPress sites, regardless of your theme.
  • Move any piece of content on your site to a different part of your site, just by dragging and dropping it where you want.
  • Allow you to preview and select page layouts before you create your page.
  • Edit every piece of content where you see it, instead of needing to hunt for it.
  • Set up a basic website without having to jump in and out of multiple admin screens.
  • Live preview any settings that affect how your site looks.
  • Revert changes and see your revision history.
  • Maybe even build your whole site from your phone?

What other customization flows do you think we need to improve? We need your input to help make a better way to build sites with WordPress.

We’ll be doing weekly meetings every Monday. The next meeting is Monday at 1:00PM EST. Join us in #core-customize in Slack to get involved!