Open Call for WordPress 5.5 Tickets: What’s on Your Wish List?

Now that WordPress 5.4 has successfully launched, it is time to begin thinking about version 5.5, which has a tentative release date of August 8, 2020. On Wednesday, Josepha Haden, Executive Director of WordPress, put out a call for tickets.

Naturally, the block editor is the top focus as we continually inch toward new features such as a refreshed interface, block patterns, and eventually full-site editing. However, there is room to put a small dent in the thousands of tickets that are still awaiting the right people to move them forward.

Currently, there are 223 tickets assigned to the 5.5 milestone. We are early in the release cycle, so now is the time to advocate for the inclusion of that particular bug fix or enhancement you have had your eye on.

What tickets do you want to see addressed?

Wish List: Finished Custom Post Status API

While I have no expectations that my personal wish list item will make the WordPress 5.5 cut, it does not mean that I cannot hope. After 10 years in the making, with a fix here and there, I would love to see custom post statuses become feature complete.

A good example use case for custom post statuses is forum plugins. Topics or threads can either have an open or closed status. There are other cases such as archive, spam, hidden, and orphan statuses. Management of forums typically happens on the site front end, so plugin authors usually build custom front-end solutions to handle statuses.

The scenarios where users need to assign a post status in the admin is where things get tricky. In the past, it was a simple matter of recreating the “publish” meta box on the edit post screen with a custom status dropdown. With the block editor, I am sure it is possible to do something similar with JavaScript. If so, this still leaves plugin authors in a bind. They will need to code at least two methods to pigeonhole custom statuses into the WordPress editor — three if also doing so on the front end.

It is time we have a complete post status API.

The lack of custom status support in the core user interface has created several roadblocks for projects I have worked on through the years. At one point, there seemed to be some traction to make this a reality, but it seems to have fallen to the wayside as more important and shinier features have been given the green light.

Custom post statuses are as easy to register as custom post types and taxonomies. The primary missing element is the UI integration on the post editing screen.

There is a real need for this feature as outlined by developers in a related Gutenberg ticket. Some agencies and organizations with a more complex editing workflow cannot move forward with the block editor on some projects, even if they want to do so.

The WP Statuses plugin by Mathieu Viet could ease the pain for developers with its integration with both the block and classic editors. However, this level of integration belongs in the core software.

49

49 responses to “Open Call for WordPress 5.5 Tickets: What’s on Your Wish List?”

  1. Yes, here’s my wishlist:
    – spend one release cycle with bug fixes, no features.
    – move development to GitHub.
    – cleanup and improve old codebase
    – remove redundant code, such as Menu and Theme settings (in favor of Customizer)

  2. A page tree. Managing pages on sites that have a lot of them is a mess, and the various page tree plugins I’ve used are out of date. This seems like the kind of really basic thing that ought to be in WordPress core. (I understand that “basic” in terms of user requirements does not always equate to “basic” in terms of development.)

  3. Many of your users work at night on their projects, so it would be good to implement a dark mode to hurt their eyes less, besides, it’s popular nowadays.
    Also, it would be nice to finally be able to sort our media files by folder, it would be so much easier, especially for those who have a lot of photos/videos.
    And finally, a function to further customize the rights assigned to each user on the site.

    • User permissions (roles and capabilities) are a dangerous thing to customize. I developed and maintained such a plugin for a decade and have seen every horror story imaginable, particularly from new users. Users would lock themselves out of their site. Users would grant permission to subscribers to create new administrators. All sorts of security problems. Putting that power into the hands of every WordPress user out of the gate would be a recipe for disaster.

      In core, I would argue it’s best to continue providing the basic option of allowing administrators to set user roles. There is still some risk in doing this for the uninitiated, but it is drastically reduced in comparison to opening the full API via a back-end interface. Anything beyond basic role assignment jumps into advanced user territory. Once a user reaches that level of understanding on how WordPress works, they can choose a plugin to manage permissions.

            • I’ve seen folder-based organization for media pop up a few times. I suppose it really depends on how you want that feature to work.

              Would a faux folder feature work? Maybe by creating a new taxonomy — let’s call it “media folder” — that allows users to group their media? If the only purpose is sorting via the admin, that could be a possibility. A taxonomy could give you all the benefits of sorting without any of the roadblocks of moving around the actual files.

              Or, do you need something that physically allows sorting media into folders on the filesystem? I’m guessing that would be harder to accomplish since core would have to deal with hardcoded URLs in post content such as if a user moved an image. The same issue would exist with options, widgets, and many other places where an image URL may reside.

              Or, do you want something that sorts into media-type folders? I could see that working out of the box.

              • Thank you for your reactive response ;), I’m thinking of your first proposal instead : “Would a faux folder feature work? Maybe by creating a new taxonomy — let’s call it “media folder” — that allows users to group their media? If the only purpose is sorting via the admin, that could be a possibility. A taxonomy could give you all the benefits of sorting without any of the roadblocks of moving around the actual files.”

    • Yes, to this idea. I put this up there on the same level as custom post statuses. It’s one of those developer features that could solve a lot of real-world problems with more complex setups.

      Fun fact: When I built a home-brewed CMS back in late 2018, I started with the assumption that all data was equal. Posts, categories, users — it didn’t matter. By designing this way, I could define the object relationships as needed. Granted, it was a simple system. WordPress would need something more robust, but it’s crazy that this has not happened yet.

  4. I would like to see at least one other viewport preview, as per the customiser, that would match that of tablet in landscape. No matter what project I work on I have to go to the child theme style sheet to roll some custom css to make these work. All themes and nearly all builders follow the standard, out of the box, three viewports, desktop, tablet(portrait) and mobile breakpoints and even at that there doesn’t seem to be consistency.

  5. Make the Post Format dialog box a separate tab under Documents rather than under Status & visibility (post formats are neither, really) for those of us that still use them.

    Move the Block Manager to Settings, or Tools, or anywhere more visible. It works well enough, you just have to find it first.

    Page ordering (see above).

  6. I work a 12 -14 hour day so a dark mode would suit the upcoming version if it’s not too late to be implemented.

    Secondly, I think WordPress should have a voting system for developers to vote on future updates to keep us more informed and feel part of the evolution.

  7. My wish!
    An easy way to wrap longer texts around blocks.
    Like you wrap texts around images. For me it would be enough with something like clicking “Block to the right” and the text will automatically go around the block on the left . (Or clicking “Block to the left” and the text around on the right)
    Thanks for your work!

    • This should already work right now. Most blocks can be aligned to the left or right. When choosing one of those options, paragraph text following it should flow next to it. It’s possible you have a theme issue that needs addressing. Maybe try checking in with your theme author if this doesn’t work for you.

      Here’s an example of aligning a cover block to the left with the text moving to the right. This is with the theme we use here at the Tavern.

      Screenshot of a left-aligned cover block with text flowing to the right

      • Unfortunately it doesn’t work for all of them, blockquotes being the one I’d find most useful. But you can add alignleft or alignright manually. I also created a pair of custom styles, callout-left and callout-right, which I can apply to audio and video, tables and quotes and which (as the names imply) allow me to float items left or right and a consistent size. Next trick is to work out how to add a button so that I can add them from the toolbar (which is all the alignment options are doing, really).

  8. My only wishlist is to have robust rest API authentication and access control panel for all wordpress rest api and it’s plugin api. There’s problem with each and every plugin has to build different authentication and access control itself, dividing whole ecosystem in parts. For example, woocommerce rest API don’t have media upload rest API, Now wordpress has media upload endpoint but could not be used as woocommerce authentication tokens can’t access wordpress api.
    In an ideal situation, wordpress must provide different authentication token schemes and aceess control based on tokens, user and it’s user roles. A dedicated dashboard is required to change the aceess control for each token, extended by plugin developer following the standard.
    Since there’s no standard authentication and access control mechanism exist, each plugin implements differently and hence fragmentation in world of service based wordpress and reduce usability of system.

  9. @Gaurav, I’m with you with this one.

    I came here to say something else about REST API support, but relates to your comment.

    We need a better REST API implementation that should be considered completely headless.

    It does not make any logical sense to go through every single theme and plugin call for the sake of a single REST call…I’m not making things up; I had to create custom endpoints for a customer’s website and it was painful to design and still is painful to maintain with every single WP update.

    I have to make sure everything works, else the whole shop infrastructure will collapse.

    Also, why do I need to have an empty theme index.php and a style.css in order to the REST API as my backend infrastructure?

    Even if we do so, we are still revealing inside our HTML code that we are using WordPress and that is something I want to complete hide.

    Anyway, my wish list is the following:
    * what I have mentioned above
    * modern PHP, short array syntax please
    * remove ancient, obsolete, deprecated code that is kept for backwards compatibility
    * GitHub ticket support instead of Trac
    * more databases support; we do use PDO behind the scenes, don’t we?
    * maybe NoSQL support as well?
    * file caching as part of core; for more info as reference please read https://laravel.com/docs/7.x/cache#configuration
    * Namespaces and classes for cleaner code; no need to have humongous names with underscores.
    * split the whole infrastructure to smaller portions and wrap them as packages for the sake of “separation of concerns” and use those you need only

  10. A thing that always bugged me is the media alt text. You can’t go to the media library and change it once if you got to update the text. No, you have to go to the post and update it there.
    This makes sense if you need to display the image multiple times in different contexts. But why shouldn’t we have the media library alt text as a single source of truth that can optionally be overwritten by the image when we specify a different alt text there? Would make more sense to me.

    Other than that, WordPress should move to the next level and become more programmer friendly. You, Justin, have written tons of posts on modernizing a lot of things, and Leonardo Losoviz has excellent articles on Smashing Mag. It’s really time for WordPress to adapt modern paradigms. Perhaps feature by feature, one tiny step at a single time. No need for haste, just a road map to begin with. Stay in good health, pals!

  11. I know this will never happen, but I would like to have the ability to update a theme and plugin via the installer. One of the nice things about Joomla is that you can do that. There is no need to uninstall or tell a user to use FTP if the theme or plugin has no method to handle 1-click updating.

    I would also like to add….stop the madness of having to click publish twice (or more) with the block editor on new posts or having to click Update multiple times when updating.

  12. WordPress finally needs to move more towards a CMS. They are marketing a powerful media management on WordPress.org but that’s what’s included in WordPress in pretty basic to me.

    Heres what I woul’d like to see native in WordPress in the future.
    Pages:
    * Native page tree view. The current view for pages is so outdated and not fitting for WordPress as a CMS. I really like the way TYPO3 is handling it (https://docs.typo3.org/m/typo3/tutorial-editors/master/en-us/Pages/CreatingPages/Index.html)

    Media:
    * Folders in media. It’s turning into a mess pretty fast, specially when using multi language tools.
    * Replace image/video/doc
    * Reference where image/video/doc is used

    Again, TYPO3 is doing a way better job handling all the media for uploads, but I also understand that’s it can be a little bit to much for regular people.

    Permalinks:
    1. Handling of internal links for media, pages and posts needs to be more dynamic. If you update the url of a post/page/file it should automatically update everywhere the link is used.

    Gutenberg:
    1. Meta data for images should automatically update when changing, after the image is already is use in pages/posts. This should only apply to images where the alt/title/caption was not edited to fit the content.

  13. Footnotes:
    It’s right there at the finish line, just missed 5.4: https://github.com/WordPress/gutenberg/pull/15267
    Schedule a revision!:
    *without unpublishing the page

    “Sometimes, you might want to update a live WordPress page or post on your site, but you want the change to only appear at a certain time. Normally to do that, you’d have to make your change, then unpublish your page, and schedule it to go live later. But if you do that, and people visit your page in the meantime, your original information is not available, and your visitor will see a “page not found” error, leaving a poor impression.”

    quoted from: https://redearthdesign.com/help-center/update-live-wordpress-page-post/

    Some plugins I found that attempt to create this functionality, but was unable to get it working and they don’t integrate seamlessly with WordPress:

    https://wordpress.org/plugins/tao-schedule-update/
    https://wordpress.org/plugins/revisionize/
    https://en-ca.wordpress.org/plugins/revisionary/

    There’s almost 15,000 users combined using just these plugins, so there is a need for this sort of workflow.

Newsletter

Subscribe Via Email

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