1. Feast Design Co.

    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.


    • Leho Kraav

      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. Kristin K. Aus

    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. Garikai Dzoma

    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. Matija

    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. Kingsley Felix

    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. Bastian

    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. Felipe

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


  8. Gary Taylor

    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. Giorgos Sarigiannidis

    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.


    • Justin Tadlock

      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. Jeffrey Carandang

    @Justin here’s the link of the open issue regarding the block editor settings per user : https://github.com/WordPress/gutenberg/issues/15105. We’ve done the same approach on Iceberg Editor which I think is really necessary in order for every users to have there own preferences saved.


  11. Abolfazl Ahani

    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.


  12. Charlie R

    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.


  13. Ben

    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?


Comments are closed.

%d bloggers like this: