WordPress Should Support Featured Images for Categories, Users, and More

One of the features that I have long wanted for WordPress has been on my mind lately. It is not a new idea, and it has been implemented in some form or fashion by plugin and theme authors in the past. However, it has never been standardized. WordPress needs featured images for more than just posts. It should support them for taxonomy terms (e.g., categories, tags) and users.

One month ago today, I participated in Round #13 of the FSE Outreach Program. It was the first time that the Gutenberg plugin allowed adding a new author template via the site editor (this is coming in WordPress 6.0). Author templates have always been supported if added via the theme, but users now have that power. The program called for volunteers to test this feature and some new author-related blocks.

As I always do when participating in the FSE Outreach testing calls, I tried to push the design limits of the editor. Much of the program focuses on the user experience, but I want to go beyond that and find those design-related pain points.

Ultimately, I settled on a design for my faux author template:

alt="Author archive as shown on the front end of a WordPress site.  Features a large hero header with the author avatar, title, and bio."
Custom author template.

I added a Cover block as the backdrop for the author profile section at the top of the page. I liked the look of the mountains mixed in with the active theme design. The problem was that there was no way to personalize that for each user account. Sure, every user gets to select their own avatar and write their own bio, but there is no easy way to let them have their own featured image.

Technically, it is possible to do this by creating custom author-{$id}.html or author-{$username}.html templates and manually and uploading them to the theme’s /templates folder. For controlled environments, such as client builds with a set number of users/authors, it is a possibility. Even in those scenarios, it is a bit of a management headache. And it does not account for every other WordPress user who might want to do something similar.

In the classic era, the same issue existed. However, it was relatively simple to code for the front end in a PHP-based templating system. For block themes, most would need to create a custom block. The image upload form would be the same in both scenarios (handled on user profile and taxonomy term admin screens).

The trouble with custom blocks is they do not tap into the core blocks’ built-in features. For example, WordPress 6.0 will allow setting a Cover block’s background using the post featured image. In the long term, core will likely support this for other image-related blocks like Media & Text. Porting these same features over to third-party plugins does not make sense.

It also does not empower users who want to build such designs with WordPress. Nor does it provide theme authors with the tools to ship templates and patterns with unique layouts to the public.

While I have primarily focused on author templates, the same arguments stand for taxonomy term templates, such as categories and tags. For example, I built out a quick category template using a similar design as shown earlier:

Front end of a WordPress site for a category archive page.  The category header section has a forest image in the background with the category title and description sitting on top of it.

The image works well for my example Nature category but not so much for others. We need a way to dynamically display per-category images.

There is at least a solid plugin for taxonomy terms: WP Term Images. Perhaps I can convince John James Jacoby, the plugin’s author, to extend it to the block system.

After stewing on this for a month, I still did not know whether I could make a convincing argument for the feature other than I think this would be cool. I am unsure if there is enough demand for it. However, it is OK to dream about new things from time to time and share those ideas with others. So, this is me, dreaming out loud, hoping that one of the items from my wish list will land in WordPress one day.

What are some of the things you want to see?

27

27 responses to “WordPress Should Support Featured Images for Categories, Users, and More”

  1. Yes it would be wonderful to have featured images for terms (at least), and I use JJJs plugin regularly. But I think there’s a bigger question here: should a featured image be setting, or content? If it’s a setting you can create consistent layouts like this, but if it’s content in a cover block you gain so much more control over how the image displays with things like focal point, which is better when determined by the image not the layout. Neither is a complete solution 🤷

    • Yep, I wasn’t quite ready to dive into that problem yet, but I’m happy to see that someone else has thought about it. It’s definitely an issue with some specific cases. Of course, the scenario that I used was the Cover block, which is a prime example of it. Sometimes you need to change the focal point, overlay, and other things based on the image. I hope that we can one day find a complete solution for that. For now, I’ll just take having a starting point.

  2. Love this idea and thanks for dreaming out loud Justin. I believe it’s that kind of thinking that pushes the boundaries. Your dream idea is exactly the kind of power and flexibility that WP needs to keep bringing to block editor and FSE in order to bring on board all those holding on to classic themes and/or the classic editor.

  3. Would love if attachment pages could be turned off or removed entirely without a plugin. I’m not sure what the purpose is for those, but they’re bad for SEO and add clutter to the sitemap.

    Even WP.com keeps these enabled and yet they champion their SEO features.

  4. Yes, this is a “missing link” of WordPress.

    Default true for categories, but filterable (BC implications).
    Default off for tags, but filterable.
    Off for post formats.
    Off for nav_menu (name for classic nav menus)
    New boolean property for registering custom taxonomies, default to value of public && hierarchical (BC implications).

    Users should have a status, so when not empty, behave like having no capabilities (like customer role on WC). Initial status as an option. Plugins can easily define their own and how that will affect real caps.

    Next: Taxonomy terms should resemble posts further, like have a status [ draft, publish, private, archived]. (draft = can be added, publicly invisible, archived = cannot be added, publicly visible), or something like that.

  5. How about the fix the wpcli and native import not to strip off update post data?

    If I publish a post in 2019, updated in 2022 and I export it via WordPress exporter and then import via import/cli it should keep the 2022 data and not return everything to 2019

  6. Also: as long as we add a featured image to a post or page, WordPress should allow that image to appear on the publication when shared to facebook ou twitter, according to the Open Graph Protocol. And it should be as simple as ‘Add a Featured Image’. Or am I missing something?

  7. There are a handful of features that 6.0 almost has. I’d like to be able to create tag-{tag name} templates in the gui. Do I spend the time building that functionality knowing that this might make it to core eventually? Sure will, cause I need it now

    • There is the example I gave in the post. Another example would be product category images on an eCommerce site, which is pretty common. A photographer might want to show off a specific images portfolio project categories. But, really, anywhere you might show a single term’s data or list multiple terms, you could use images.

  8. I left Drupal for WordPress, but the one thing I appreciated about Drupal was that everything was a “node.” Posts were nodes. Pages were nodes. Taxonomy terms and images were nodes. Menu items and users were too.

    This upside of this is every endpoint is as customizable as a post — they have a title, excerpt, features image, editor, post date, etc, allowing for each node to have content and meta content as needed.

    It was super flexible and I find myself constantly have to recreate this flexibility in each major WordPress project I work on.

    I’ve love WordPress to adopt a similar architecture. There’s no reason why terms can’t be as rich as posts.

  9. This is, in my mind, a classic example of where functionality exists within Woocommerce that should be up streamed into WordPress. I really wish that Woocommerce devs would treat WordPress as a framework their own software as a specific permutation. This would mean contributing back upstream any additional functionalities they need, and then building out their specific implementation on those new functionalities. Instead, there’s been a consistent pattern of building out Woocommerce itself as a framework, leading to more and more fragmentation and functionality silos in the WordPress ecosystem.

    It may seem unfair to pin this to a single project, but the significance of Woocommerce is nothing to be sneezed at, both by the size of it’s adoption, it’s virtually singular status for what it represents, and the fact that both projects are run by teams under the same corporate umbrella.

    Other functionalities that exist or are being developed within Woocommerce but not WordPress include the ability for an end user to manage custom taxonomies (Product Attributes), content reviews management, commercial-plugin licensing management, and the ongoing work on performance-oriented dedicated-entity data tables.

    On another note, and in addition to the above, I, for one, would be in favor of enabling the block editor for taxonomies, allowing for a much richer suit of possibilities for building out archive-based landing pages.

  10. This issue has been solved by third-party plugins, e.g. Toolset and Metabox. Both offer taxonomy term custom fields.

    While it would be very cool to have such a feature in the core, I also think the developers of such advanced plugins should continue to be able to profit from their hard work. They also contribute to the success of WordPress and play an important role in the ecosystem. If the core incorporates too many of their features, they might lose customers, which would not be good for the ecosystem.

    Anyone with more advanced requirements can simply extend WordPress with Toolset or Metabox to have a powerful CMS. Personally, I prefer WordPress + Toolset or WordPress + Metabox to Drupal…

    • This issue has been solved by third-party plugins, e.g. Toolset and Metabox. Both offer taxonomy term custom fields.

      While it would be very cool to have such a feature in the core, I also think the developers of such advanced plugins should continue to be able to profit from their hard work. They also contribute to the success of WordPress and play an important role in the ecosystem. If the core incorporates too many of their features, they might lose customers, which would not be good for the ecosystem.

      Those plugins are not limited to a single image feature. I also doubt the existing free alternatives for that feature have put a dent into profits.

      I understand the argument, and it has been made throughout WordPress’s history about one feature or another. I have yet to see it have any real-world negative impact (though there may be some examples I don’t know about).

      On multiple occasions, WordPress has added features that were available in themes and plugins that I have built. For example, my early themes were some of the first to support post featured images. By adopting that feature, WordPress didn’t hurt me at all. It made it easier to support my products by having a standard system. I even went on to extend it to offer even more options not available in core. Plus, the ecosystem has benefited from the feature being available to everyone.

      Almost every feature you see today in WordPress has existed in some form or fashion in a plugin or theme. To make the argument against adding a feature because a third-party developer has already solved it is to make the argument to never build anything other than, maybe, APIs (of course, there are some folks who would love that).

      Anyone with more advanced requirements can simply extend WordPress with Toolset or Metabox to have a powerful CMS.

      Unfortunately, that is not the case for everyone. For example, if a developer wanted to build a theme that showcased a featured category image in a Cover block (as shown in the post above) and release that theme for public use on WordPress.org, there’s no way to do that without it being supported from core.

      Maybe some DIY, tech-savvy users could recreate that using something like Toolbox or Meta Box, but the majority would miss out.

  11. Hi Justin, I would like to highlight the fact that instead of making new feature request, the FSE should first include things which are already available in standard WP and should be a part of FSE.
    It is really troubling to see that we are not addressing the Elephant in the room.
    Following are my observations :

    You can not add templates for Custom post type
    You can not add templates for Custom Taxonomies

    Further more , these high value tickets are currently open with no end in sight. The FSE is not flexible enough to accomodate more templates and the criteria for application. I really do want to support FSE but currently we are back to WP version 1.0 with no Custom templates.

    • CPT and taxonomy templates are 100% supported and have been since block-based theme support shipped with WordPress 5.9. The template hierarchy is exactly the same. In fact, we are using both an archive-podcast.html and single-podcast.html template right here on WP Tavern. Check them out via our podcasting page.

      This puts that piece of theme building entirely on par with classic WordPress.

      Presumably, you are referring to creating these templates directly from the site editor, which was an impossible task in the classic era since such a feature did not exist. It should be noted that the site editor is still in beta and is merely one component of FSE. It is the UI that will eventually allow creating entire themes from the WordPress admin. It’s getting closer, but it is not quite where it needs for some of the more advanced usages.

      But, there is good news. WordPress 6.0 is shipping a handful of new templates that can be added via the site editor. This is a necessary foundational step before building out the UI for creating custom templates for post types and taxonomies. There is ongoing work to make this happen, and I expect that we will see something like this land in WordPress 6.1. This is new territory, so it’s going to take a little time to flesh out the user experience.

  12. We’ve been using a custom field for term images just like JJJ’s plugin in our theme(s) [Mai Theme] for a while in the classic/hybrid era. Mostly for a custom “term grid” block, similar to a post grid but for categories/tags/terms. It’s been great but obviously custom and certainly leads to a bit of theme lock-in.

    I’d love to see this supported in core.

    Another benefit/use-case is for the OG (Open Graph) image on term archives, as mentioned in an earlier comment. That’s reason enough to add it IMO.

Newsletter

Subscribe Via Email

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