Cancel

Justin Tadlock

WordPress 5.6 Wish List: Homepage Post Type Selection and Block Management

With the WordPress 5.5 development cycle coming to a close, it is time to begin mapping out what features should land in WordPress 5.6 later this year. Earlier today, Chloe Bringmann asked the community to chime in with its wish list on the Make Core blog.

As usual, I have a few thoughts. I tend to lean toward addressing some of the long-standing developer-friendly tickets because these features allow plugin authors to build better products for end-users in the long run.

A complete custom post status API tops my usual list of most-wanted features. I have already opined over this for my WordPress 5.5 wish list. It may be time for more realistic dreams. Maybe we will revisit it another year or two down the road. However, if any core leads want to give the feature a green light, I will gladly be the evangelist and get others excited about it.

Homepage Post Type Selection

For this release, I want to call out one of my other years-long wishes. WordPress should allow end-users to select any custom post type for display on the homepage.

Imagine a WordPress where users can head to their Reading Settings screen in the admin and select something other than their normal posts list or a page to appear on the homepage. Have a forum plugin installed? Maybe users want to list their latest topics or forums list. Running an eCommerce plugin? Users should be able to display their products. Setting up a web design portfolio? Display the most recent projects by simply selecting this choice in the admin.

This is an area where the software has always catered to bloggers and has avoided throwing a little love to other types of sites.

Currently, plugin authors must perform some crazy hacks to make this work. The WooCommerce custom query class is enough to make any developer give up. Not all of the code in that file is for the front page, but it has a frustrating amount to make something work that should be far simpler for plugin authors.

The reason this needs to be in core WordPress is so that each and every plugin does not need to roll a custom solution. Plugins should be able to flag their post types during registration as “allowed on homepage” — not all post types are meant for this type of display. Then, WordPress should handle all the dirty work behind the scenes if a particular post type is selected by the end-user. The addition to the API for plugin authors would be simple, and plugins that are already hacking this feature together can drop a lot of unnecessary code.

There is an existing 8-year-old ticket for the feature. It has a few old and likely outdated patches and has not seen any real activity in the past four years. Nevertheless, it would be nice to see this feature in core WordPress and finally close the ticket.

Block System Wish List

Like most releases, the block system will be getting the most attention. The things that will land in WordPress 5.6 are mostly already set in stone, assuming a particular feature does not fall behind in development like widgets and nav menus did for the 5.5 release.

On the whole, I like the general direction the block system has been headed. If anything, I have been impatient with some things, such as awaiting the integrated block management screen in the admin. For other features, such as full-site editing, I am still wondering whether they are realistic goals for the WordPress 5.6 release.

I would take a release and focus on tightening up and polishing the existing system. Take stock of the pain points — and there are many — that users are mentioning. Spend time working on smoothing out the editing experience before tacking on new features.

That is not going to happen. New features are what get developers up in the morning and excited about the project. Therefore, my fallback request is to bring on the block management screen.

What’s on your wish list?

Category: ,
21

21 responses to “WordPress 5.6 Wish List: Homepage Post Type Selection and Block Management”

  2. Hi,

    I am proposing radical changes.

    First of all the core principle is “Moving Forward”, a radical shift from granularly making nit picking changes as that current path is leading to Squarespace, Wix and Shopify taking even more of the market.

    The other core principle is that everything should be aimed at the core client and consumer, the average Joe, not the geek/coder/developer. The end goal is to make more regular people using the CMS, not geeking the geeks to use the product in a geeky way.

    Branding

    Changing of WordPress.org to Gutenberg and leaving WordPress.com to be the only “WordPress”. The Gutenberg itself to be renamed to Gutenberg Editor.

    For years people are getting confused between .org and .com. I am talking about the average user. That confusion is still not solved to day. That requires the step necessary to change that.

    WordPress.org Web site

    The website should be radically transformer in an Apple style of simplicity in order for the most important things to be more prominent and to increase the desired action.

    No more third party stuff all over the place and confusing navigation. Clear top navigation of the new Gutenberg.com or whatever the domain would be that aims to provide clear Download, clear “Features”, clear Block, Plugin & Theme directory.

    Gutenberg.com should feature refactored legal pages with privacy policy that is aligned with the laws of First World countries, including the EU with user-friendly human-centric documentation.

    Gutenberg.org should be simple and use the current version of the current default theme of the CMS. What more better advertising than using your own theme?

    Heavy utilization of white-space just like the Gutenberg Editor in order to provide a conformist branding look that is cross service.

    Development

    Clear separation of Blocks and Plugins. A prominent equal level style of presentation of plugins, blocks and themes.

    Blocks would be the new default way to enrich your content, while plugins remain a more system level stuff that is more like behind-the-scenes enhancement.

    Blocks are separate from plugins and don’t clutter your database with additional junk like the current method.

    Apple-style of App Store management of the Gutenberg Store – the new place for blocks, plugins and themes. A special internal handle of in-store purchases so that the plugin/theme/block developers don’t have to have a third party payment processor etc. A small flat fee of 10% with 0% on the free item is a reasonable way of dealing with the infrastructure costs.

    People should feel more secure to purchase things from the Gutenberg Store rather than going to a third party website and handle things there.

    Rigurouse clean up of the junk that was collected through the years on unmaintained plugins and themes, that are still in the repository for some reason. These should be deleted in order for the most important ones to shine.

    Gutenberg Editor

    Heavy emphasis on making it a real drag ‘n’ drop WYSIWYG editor using well known workflows, UI and UX from other well known text editors and mail clients. Anyway who was familiar with Microsoft Word, OpenOffice, Google Docs and a regular email client, should feel comfortable using the Gutenberg Editor.

    The Gutenberg Editor should take into account that people use different devices, including wide screen displays, desktops, touch enabled laptops and 2-in-1s, mouses, not just trackpads and make the interface in accordance to that.

    Again, the editor should be tailored at the average consumer and the average Joe, not just to geeks/coders/devs using laptops with small screen and trackpads.

    Google Docs are a perfect example of how one text editor could work well on wide screen displays on devices with mouses and on touch enabled laptops.

    Complete overhaul of the way all the quirky ways of the UX and the UI, which are unfamiliar with other services and software, I am talking about things like page velocity scroll on drag and drop etc.

    Centering the idea that a good WYSIWYG editor is a drag and drop editor, not a 6-click editor to accomplish something simple.

    Gutenberg Editor – Two Separate Modes

    One mode for building a page, this is suitable for primarily static 20-30 page sites of small businesses.

    Text mode editor – this is suitable for news, magazine and blog style sites that need to constantly have fresh new content and are in a stage where the core design and layout of the site was already build. Now it is time of the content producer to produce regularly fresh new content, not to handle block customizations and layout changes.

    Performance & Security

    The WordPress database become like a Windows registry, as soon as you uninstall a plugin, you have that massive amount of data cluttering up the database just like a Windows registry.

    This must stop now. Embrace a core-level way of monitoring of what happens throw the install and handle the uninstall on a core level. Two places to put the clutter in the database – settings and temporary items. Upon uninstall request the user if he wants to save the settings or completely uninstall the plugin. This must be handled on a core level, plugin devs won’t respect a guideline.

    That would save tons of people from blaming WordPress / Gutenberg of being slow and even accusing their hostings for that.

    Same should happen on a file level. Completely isolating the WP core from the user side of installed blocks, plugins and themes. These must be separate. One should be read-only image-like within its own directory and the rest should be separated in a better way than the current. Some hostings are already implementing such structure on their own.

    That would potentially have a huge security impact.

    Introducing of iFrame lazy load as Chromium now supports that as well.

    Admin Area

    2FA built-in with a companion phone app.

    Customization of the branding of the admin area and the colors of the admin area with custom hex codes.

    New modern style home screen focusing on the important stuff and not the clutter.

    A strict new enforced place and the only place where Plugins could put stuff – A-Z ordered single menu per plugin inside Plugins. No other place, no root menu level etc could be populated with plugins. This must be restricted from the core.

    Core level management of the top menu items if you want to enable or disable a shortcut there for clearing cache and others.

    Notifications basked like what we have in Windows, MacOS, Linux/BSD, Android, iOS, ChromeOS etc. One place to manage them all. Restricted on a core level, so no plugin, block or theme devs could circumvent this. Silencing of these notifications and nagging screens just like in any OS.

    Privacy

    Core level control of the data that’s being processed from a plugin. No more sending of private data and strict control as iOS style of privacy control.

    Dev Handeling

    Stop pretending that everything is open and democratic. Yes, it is open, but 90% of the staff that is working on this is Automattic employees, do not hide this, embrace it. Hire more people.

    Simplify hierarchy.

    Embrace one single place for all tickets. Clean up the ever growing WordPress track system. As much as it grows, the harder is to see the real issues. Some are not even relevant as being associated with something ancient. Going through rigorous filtering, merging and closing so that the open ones become less and less and not more and more.

    More staff, more people and more effort on clearing tickets for the Gutenberg Editor and the core. We need to push and move forward.

    Yes, we’ll lose many devs doing all this, but yes, the platform would become much stronger.

    Human progress is not build throw evolution, but throw revolutions. A huge leap forward is always built throw revolution – e.g. making something completely new and moving faster, not throw nit picking small issues and fixing them just to count a ticket number for the new version.

    Create forum topic from comment

    • A few things

      Gutenberg is not WordPress, it is not even 10% of what makes WordPress great.

      WordPress.org is the bigger brand than .com. If anything automatic should rename its service.

      With the exception of some way of registering settings and meta for each plugin.

      And having a notification queue, which is being looked at (wp notify project)

      All your other wish list items are unrealistic unimportant, unrealistic, or destructive. So many though so it’s hard to know where to start.

      Create forum topic from comment

      • I use WP since 2009. I know pretty much what’s Gutenberg, it’s completely refactoring what WP was, from the core. You know that better than me. Hence why rebranding is needed.

        If change doesn’t happen, Shopify and Squarespace and potential new ones would enter the space and take even more share as people are leaving the platform. Current block editor [which I idea I really like], is implemented in a way that is alienating the regular person. That’s why the 1 star reviews are. It’s not because it’s new, it’s not because the idea is bad, it’s because the implementation is terrible.

        If you don’t self-cannibalize yourself, other’s will do it. Without hierarchy and moving forward, with this pace of progress, the platform would slowly fade.

        Create forum topic from comment

        • I agree with your philosophy and some of your crititicism but your ideas are mostly ridiculous.

          I agree gutenberg has issues but building the whole branding around it is stupid and counterproductive and some of your suggested improvements would be steps backwards.

          Performance & Security, agree with registering settings and meta but otherwise you need to explain what you mean.
          Iframe lazy load is/will be on its way.
          2FA built-in with a companion phone app.
          No way not needed whatsoever, if people need it install a plugin, ther are plenty already.
          Admin area
          yep could be improved but I´m sure it will be
          Dev Handling
          Your ideas on this are 180 degrees wrong, Automattic already have to much influence and thefact that the first priority is gutenberg shows this (there are way higher priorities)
          Simplify hierarchy.
          No issue with single ticket

          7 Revolution not evolution
          compleetly wrong . Most progress is from gradual improvement. Most revolutions end in anarchy and destruction. History show this and shows why most of your radical ideas and downright dangerous.

          Create forum topic from comment

          • When you think “revolution” I mean Industrial Revolutions and revolutions in science and innovation, not political ones despite some of them being good like the French Revolution, the US independence etc. These were all revolutions and changes history dramatically.

            Create forum topic from comment

  3. Media management. Should I pick one area that really needs improvment.

    Even with third party plugins, its a mess. Especially once a site has been live some time and different authors are uploading media. I’m mostly struggling with:

    Image Sizes aka Thumbnails. Different themes adds different sizes, and it becomes an iceberg of bloat where you only see the tip.
    Orphaned files that are no longer used. Ever stumpled over 10 different versions of “header.jpg” wondering which one is in use?
    Webp conversion – why isn’t that native already?
    Better filename santization – uploading that “Rødgrød med fløde.pdf” is causing all kind of troubles if not taking care of upfront.
    Renaming files. Not only their titles, the file also.
    File categories / folders

    I know WordPress isn’t a media/file server, and I don’t want it to be, but creating text only websites is not what I’m asked, ever, and the build in media handling leaves a lot to desire. Just my opinion :)

    Bjarne

    Create forum topic from comment

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

    Maybe a good first step would be to extend the admin option that allows you to choose a page for the “post” post type, to the rest of the post types.

    Create forum topic from comment

  9. Hi,

    Drag n drop & cut/copy/paste doesn’t work normally.

    The reasoning behind all that is because it is built in a quirky non-standard way that goes against the well known logic from 30 years of office suites, word processors and text editors.
    To fix that I propose the following:

    1) Make CMD + C, CMD + X and CMD + V work on all blocks, no matter of their type and no matter of the length of the article [currently it doesn’t work for lengthy posts with many images].

    2) Make Cut, Copy, Paste to exist in the drop-down menu. Currently there is just “Copy” and “Move to” and the second don’t even work on many setups and/or post lengths.

    3) Add symbol for dragging as the average Joe wouldn’t know that he can drag things by hovering over the block type icon.
    Make up and down separate buttons. There are people on tablets [that serve desktop site versions like the new iOS], all in ones with touch capabilities, laptops with touch capabilities, and 2-in-1s with touch capabilities. For these people the up-down buttons must be separate thumb-space clickable.

    4) Ditch the page scroll velocity that starts from the beginning when you drag things. Such thing doesn’t exist in any OS, platform, word processor or anything. In the normal well-known already-established environment the scroll of the page doesn’t happen until you get to the bottom of the page.

    By making these changes you’ll make things that are all aligned with what people are getting used to in the last 30 years of word processing.

    In my opinion there should be a guideline of the geek/programmer/dev that is working on the Gutenberg project to put himself in the shoes of the average Joe which the primary consumer target.

    Gutenberg shouldn’t be built to be used just by geeks/programmers/devs, but primary from the average Joe.

    Kind Regards

    Create forum topic from comment

  10. I would love easy dependency management.

    It should be easy for Themes and Plugins to declare what plugins they require (as well as those they suggest), without having to graft on something like TGMPA. Ideally just comment lines in the plugin/theme’s main file, Like :

    /*
Theme Name: My-theme
Version: 1.0.0
Requires: advanced-custom-fields-pro, debug-bar, redirection
Wants: svg-support, wordpress-seo, wp-mail-smtp
*/

    Dependency management is a huge part of software development in 2020 — entire ecosystems exist around tools like npm, composer, etc. Why can’t WordPress have something sensible baked-in, like Drupal has had for years?

    Create forum topic from comment

  11. Global CSS breakpoints that every plugin and theme respects. With browsers supporting CSS variables, users should be able to set their own breakpoints for what they think is desktop, tablet, and mobile. A new menu item in the Settings menu or a tab on the Appearance menu. Users set “Desktop = 1200px/75rems/75ems, Tablet = 768px/48rems/48ems, etc….” . When these settings are set, WordPress outputs some CSS such as:

    :root {
--desktop: 1200px;
--tablet: 768px
--mobile: 468px;
}

    The plugins (especially built-in Blocks and third-party blocks) and themes take those CSS variables into account:

    @media(min-width: var(--desktop)) {
/* do something like set the default columns in a grid*/
}

    This would fix problems with different plugins deciding what they believe is the breakpoint since a plugin has no idea about a theme’s styles.

    Create forum topic from comment

  13. What I wish for is a propper dependency manager. Like just add a list in a .json-file and hit install in the backend. Read it, install it, done.
    Like composer or npm does. It still is a hazzle to do things quickly, and it just shouldn’t be that hard in a system that is so big.

    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.