WordPress 5.7 Wish List: Save Block Editor Settings Per User

WordPress 5.6 development is winding down as we begin to close out the beta testing round, inching toward the final release on December 8. That means it is time to think about what WordPress 5.7 will look like. This is one of my favorite times of the WordPress development cycle because I get to see what others want to be added to the core platform. I also get to share a feature request of my own.

Francesca Marano opened the discussion on the Make Core blog. She asks that people link to a specific ticket, which can be from WordPress Trac or the Gutenberg repository.

One consideration for everyone’s wish list is that 2021 will potentially see four major WordPress releases rather than the typical three. WordPress 5.7 is tentatively scheduled to land on March 9, 2021. The team has scheduled future releases in three-month intervals. While the dates are not written in stone, it could mean each release’s feature set might need to be scaled back to some small degree.

Most features that land in WordPress 5.7 will be items that are already under development. Enhancements like block-based widgets and nav menus that were punted from the 5.6 release should land early and be ready for a full three months of testing. The development team will also focus heavily on pushing an early/beta version of the site editor into core WordPress.

There is still room for other things to land, and now is the time for everyone to make their case for their pet feature.

Unlike past wish-list discussions, I am going to take a step back and control myself. Instead of asking for one of those big-ticket items that I know is unlikely to happen — hello, completed post type API and homepage post type selection —, I will simply ask for something more practical.

In WordPress 5.7, I want the block inspector tabs and some block option defaults to remain the same each time I write a new post.

One of my biggest pet-peeves is with the image block in particular. Each time I add an image, I first close the Styles tab in the sidebar. I do not use it often, so it is not important enough to always be open. Then, I must switch the Image Size setting to Full Size from its default Large. I typically format my images for display before uploading and simply want to use the image at the size I uploaded. These are small things, but they break my workflow. As a daily writer, it has become a nuisance over time.

Adjusting an image block's settings in the WordPress editor.
Configuring image block settings.

These should be per-user settings. Each user’s workflow is different, so WordPress likely needs to handle this as user metadata or a similar method.

I was unable to track down an open ticket for saving the tab state. There are over 2,600 currently-open issues. Maybe I did not nail down the right search terminology. Or, it may be a non-issue for other users.

However, there is a two-year-old ticket for remembering the last image size used. I was happy to find like-minded peers who share my frustration in this case. There is also a more recent ticket about storing the default image size on a per-user basis. The feedback in the tickets shows a clear and present need for WordPress to fix this problem.

A representative of Feast Design Co. noted in the first ticket, “Every time somebody inserts an image they have to change the image size. This seems small but at 10 seconds per image x 5 images per post x 2 posts per week x 52 weeks per year, this is 86 minutes per year.” I believe I can manage it in a little less than 10 seconds per image, but it stills knocks me out of my flow each time. It is a seemingly trivial issue, but the time wastage adds up for those who add many images to posts throughout the year.

What is on your wish list for WordPress 5.7?


17 responses to “WordPress 5.7 Wish List: Save Block Editor Settings Per User”

  1. Thanks for resurfacing this issue.

    The thing is that these settings ALREADY EXIST in the database as image_default_align, image_default_link_type and image_default_size

    Someone just needs to load them into the block editor and integrate it, instead of relying on the current hardcoded setting.

    I’ll actually pay for someone to code this and commit it.

    • Upwork works well for these kinds of micro-projects.

      Project completion criteria is an accepted PR. Because it cannot be guaranteed, some reasonable approximation could also be agreed upon.

  2. Justin you have a good point. While it breaks the workflow for an advanced user like you, the current situation is more impactful for the non-techie user. For them, image sizes in WordPress are a real pain point. If their dev can tell them one option and it could be saved it would alleviate a lot of headaches for them.

  3. On my blog I write notes a d .ake use of the list block. This often involves using different types of list styles. Unfortunately I not able to change list styles. Something so basics is not implemented while people go on about full site editing

  4. Gutenberg should aim to achieve feature parity with modern page builders. Their stellar success over the last few years is a clear indicator to what people expect from modern web creation platform. It’s a clear win for all because plugin developers could focus on solving more specific problems.

    Also, it would be great if the WordPress/Gutenberg UI/UX would be more cohesive and consistent. At the moment it seems as a collection of bits and pieces. As such it lacks the flow of modern design tools.

  5. irrelevant things keep getting added every update… We can’t filter images uploaded to a particular post.

    You can’t multi select images using the IMAGE BLOCK yet they are talking about BLOCK WIDGET.

  6. The Classic Editor plugin will be officially supported until December 31, 2021 and yet there are many plugins that make extensive use of meta fields such as WooCommerce or all event listing plugins that are still using the classic editor UI.
    Two years have passed since WordPress 5.0 was released and still there is not an adequate way to replicate a big panel with many meta fields in Gutenberg.
    I know that the PluginDocumentSettingPanel and PluginSidebar components exist, but they are too narrow and are not suitable for custom post types that use meta fields heavily.
    Can someone in the Gutenberg team take a look at this and offer us a solution, please?

  7. Agreed! Generally speaking, I believe making things work smoothly should be a priority over new shiny features – especially easy fixes like this.

  8. It’s not a wish in the sense you mean, but: with four releases per year, perhaps the big-ticket items could be given six months development time, instead of four? Less pressure to get them introduced in the next major version that way, and a bit more capacity to fix the niggling issues, such as re-ordering Pages…

  9. Here’s mine:

    The ability to use Gutenberg blocks on Post type Archive pages, both before and after the entries’ loop, and better handling of post type archives in general. For example, a simple thing that I deal with often is that you cannot allow the site Author to set/change the archive title unless you make some custom field and modify the template.
    Better handling of relative URLs. I know that it won’t happen but nevertheless, it would be nice to not having to do a database search and replace every time we switch domains (e.g. from staging to live).
    Make tags and non-hierarchical taxonomies in general respect the order that they are being added by the user (here’s the issue: https://github.com/WordPress/gutenberg/issues/21589).
    Sometimes, on poorly or irresponsibly written plugins, notifications persist even after I close them. Those times I would love a “Mark as spam” functionality, but that would be too much and it could easily be misused, ending up making things even worse. A less aggressive and maybe more realistic approach would be some sort of “Mute this plugin” option: Users could disallow specific plugins from displaying notifications overall, either permanently or until their next update (in case they indeed need to announce something actually important).
    A better way of setting site-wide options for blocks. For example, I made a block that uses MapBox and I wanted to have an option to declare the API key, so I made an options page on the admin. It would be nice if I could set this directly from the block’s options, and the setting to be kept across all instances of the block.

    • I believe many of the post type archive issues will be fixed with the upcoming site editor. Because the user will have direct access to editing the templates in the editor, I’d imagine it’d be pretty simple to change the title. Same thing with other aspects of it. So, that’s something to look forward to.

  10. WordPress is already so comfortable for authoring posts, but some advanced features for site admins is completely forgotten. For example, I dream for a drupal’s views module (query builder), in WordPress core. Then something like drupal’s rule module (workflow engine).
    So, I think the classic editor was more than enough for most users/use cases. For decorating special pages (homepage, about us, …), there were plenty of options to choose from free/premium page builders. In this regards, Gutenberg project could be postponed for at least 5 years, to focus on some infrastructures, like field API (hello Pods team), and then working on features needed for using WordPress in Enterprises without wrangling with php codes: built in visual query builder, workflow engine, …
    In other words, I wished WordPress choose Drupal/Sitecore to compete, not Wix/Weebly/Squarespace.

  11. Why have simple things like increase/decrease indent buttons been left out of Paragraph and List blocks? I have to go to Classic Paragraph block when I want to indent.

    Also there is no option to position images in paragraph (left, center, right). I usually go to html to fix that.

    And the classic editor gave table options that were left out of the Table Block. Trying to implement with html usually causes an error. This is bizarre when the html has been checked and double checked for correctness.

    I’m surprised that I haven’t seen comments on this kind of thing by you or others.

  12. Atop my wishlist for 5.7 (as it was for 5.6, 5.5, 5.4…) is proper dependency management for plugins. Eight years ago when I transitioned from mostly working in Drupal to mostly working in WordPress I was shocked that a plugin or theme couldn’t just declare in its main file comments a list of the plugins that it needed in order to function, as Drupal supported something similar. I figured WordPress was still new to being a “real” CMS, though, so it would come in time.

    Here we are eight years later and still the same. Instead we have to turn to janky third-party code libraries like “TGM Plugin Activation” that haven’t been updated in years and clutter the admin with notices, or just let plugins/theme that extend or rely on specific plugins be active while not actually doing anything or working properly.

    I have ideas how this could be implemented, but no idea how to get the leaders of the WP project on board to make it happen. Maybe I’m the only person who wants this?


Subscribe Via Email

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

%d bloggers like this: