Practical WordPress Development

A False Dilemma in Niche WordPress Themes

Niche WordPress themes is regular of topic of discussion for those involved in creating themes for WordPress. Discussions range from debating whether or not niche themes are dead all the way to why niche WordPress themes continue to be one of the ways to create something unique for WordPress.

Regardless of where you fall on the topic, niche WordPress themes currently exist – and need to be maintained – and will likely continue to be created for the next few years.

One of the challenges that comes with creating niche WordPress themes is how to manage certain aspects of WordPress that are typical for standard publishing themes but aren’t necessarily required for niche WordPress themes.

Niche WordPress Themes

For example, let’s say you’re working on a theme that’s meant to showcase photographs. Let’s say that it’s not intended to display text, comments, or tags. Instead, it’s only meant to display images that are added within the post editor, the date of the post, and the name of the author who publishes the post.

If you go this route, the front-end is obviously constrained because there are only so many things that are to be displayed on the front-end. But this raises the question: What do we do with all of the residual options in the dashboard?

Take the idea of comments: In this particular theme, comments are not going to be supported. This means that the Comments form will not be rendered on the front-end. Similarly, this also means that the Comments menu item doesn’t necessarily need to be displayed in the dashboard.

Then again, that works under the assumption that everything that’s rendered in a user interface indicates what the user can do when working in the application. In this case, this means that there’s a disconnect between what the theme supports and what WordPress supports.

Users will see that Comments are visible in the dashboard, but aren’t visible on the theme. Ultimately, this may lead them to think there’s a feature that’s not activated or that something is broken with the theme.

On one hand, it seems like removing the menu option makes the most sense, but what if the user is installing a new theme on an existing WordPress installation that has comments from a previous iteration of the site? Or what if the user wants to continue to be able to access the comments from the dashboard after they’ve changed themes?

It feels like a bit of an impasse, doesn’t it? And this is but one example. We aren’t even taking into account other things like categories, tags, and potential text that can be added in the post editor.

What’s the Best Thing to Do?

I don’t have a strong standpoint on either side of this, but I – like the rest of you – have my own opinions that are largely based on my experience.

Above all else, I think it’s important to remember that just as users may think something is broken in the theme if they see something in the dashboard that doesn’t correspond to a feature on the front-end, they may also think that the theme is causing WordPress to malfunction if there’s a feature they’re expecting to be present but has disappeared from the dashboard menu when the theme has been activated.

Personally, I’ve found that it’s far easier to leave the dashboard in its standard form and then provide a level of guidance as to what the user can expect when working with the theme.

This may come in the form of messages, tooltips, or pointers in the dashboard and/or it may include writing documentation that includes screenshots and other points to let the user know how the theme is supposed to function. Granted, this also sets the expectation that users will read the documentation and anyone who has done any level of theme support knows that for every user who reads the documentation, there are two or three who will not.

There is, however, one course of action that I think is viable although is does depend a little bit on user education: In short, wrap all of the functionality that controls what features are displayed in the dashboard in a plugin and then give the user the option on whether or not to activate the plugin.

That is, when the plugin is activated, the dashboard is limited to features that are only relevant to the theme at hand. No data is removed, nothing is changed in WordPress core, and it gives the user a second option to the all-or-nothing approach to the features of a WordPress theme.

Similarly, for those who are building the theme, it provides a single place where any decisions related to what the dashboard offers should reside and it prevents us from getting stuck in the perpetual debate of “If we leave it here, users will expect, but if we don’t they’ll think WordPress is broken.”

The Dangers of the Dashboard

Working with niche WordPress themes that only use a subset of options that the application provides and trying to restrict the user interface by default is a slippery slope because if options are not going to be displayed based on what the theme offers, then it also implies that when a plugin is installed that introduces a new menu item, said menu item should only be displayed if the theme supports it.

Furthermore, this also means implies that only certain fields should be displayed if the theme supports it. Say, for example, your theme has no support for the user’s Twitter URL. Should the field be removed from the Profile screen? And what if you add something like support for Instagram – should that field be added?

As much as I like the idea of limiting the user interface to only what the user can do, this is one scenario in which I don’t think it’s actually feasible. Instead, I think that documentation and a plugin are our best bets for giving the user a choice on how much they want to restrict the dashboard.


  1. Nick Haskins

    Great post Tom. I’m doing this very same thing currently, working on a massive overhaul of the admin to get rid of a lot of kruft (ironically for writers), and I think one of the ways you can get away with this is if you’re hosting a private ecosystem. I

    I have to agree with you and don’t think this would be prudent on a theme that one would purchase.

    • Tom

      Yes to both – on hosted ecosystem and on purchased themes.

  2. Tom

    Having worked with WordPress as the platform for an SaaS, this certainly resonates. The way in which users administrate sites with WordPress and the way in which themes/plugins are implemented vary so much – testament to how flexible the platform is, but nonetheless throws up these usability conundrums.

    Personally, with restricting the flexibility of the WordPress platform I think there is only one true “solution” – education. Educating clients & customers on how the theme you’ve supplied impacts on WordPress. Documentation. Sadly, there will still be confusion and misinterpret ion – but that’s the nature of the game we’re in. We will always need to support these people.

    • Tom

      That should be “without restricting”.

    • Tom

      Documentation. Sadly, there will still be confusion and misinterpret ion – but that’s the nature of the game we’re in. We will always need to support these people.

      You’re right. This is a tremendously underrated area of WordPress themes. When working with a previous company, we had good documentation that covered a lot of bases, but this is one area in which I need to improve on for the things I’m working on right now.

  3. Ben Wilson

    Very interesting information. Agreed with the information, Flexibility have more value than restricting the dashboard. In further scenario you can change it anytime you want.

  4. Michael

    How about a plugin that allows the developer the ability to simply deactivate standard menu options. The menu stays intact, but individual items that aren’t needed/aren’t active are just greyed out and deadened by the admin, and can be set and controlled by admins only. That should be able to be done with some CSS + PHP since they’re list items and reduce confusion. Or is that a dumb idea?

    • Tom

      I wanted to link to something like this because I think it exists, but I can’t recall it’s name right now.

      Either way, I don’t think it’s a dumb idea but I still question the best way to implement it. I mean, do you just tell the user to install at and activate it and then it just ‘automagically’ hides them and then deactivate it to reclaim it?

      I just mention that because that’s how I envision it working in it’s most basic case.

    • Damien Carbery

      How about moving the unnecessary top level menu items down the list e.g. Comments to the bottom, below Settings. Though it, like Michael’s disabling idea, could easily confuse users and certainly anyone trying to support them – “See the ‘Settings’ menu? It’s at the bottom … oh, it’s not?”

      Here’s a plugin that allows menu reordering via drag and drop (first in ‘admin menu order’ search):

  5. Jason Halle

    I want to say WordPress is in existence because you can customize it according to your requirement. So, I think if you need any change then you can change it.

  6. Bauke

    Nice article Tom.

    Totally agree with: “users may think something is broken in the theme if they see something in the dashboard that doesn’t correspond to a feature on the front-end..”. Creating a plugin that hides non-used elements is a great idea!

  7. Margesh

    As a WordPress developer I would say it will be good to develop a themes which can be used by any kind of business. These type of theme can earn more money and you have to manage & support only one theme.

    What do you want to say about it?

    • Tom

      As a WordPress developer I would say it will be good to develop a themes which can be used by any kind of business. These type of theme can earn more money and you have to manage & support only one theme.

      In order to create something like this, you’d have to create a theme that’s so versatile, it’d be able to handle an extremely wide variety of use cases that an incredibly high number of types of businesses.

      I don’t think that’s possible.

      Instead, I’m more of a fan of creating a number of themes – one for each type of business. This gives you the ability to take a deep dive into understanding the problems of a given business, solving them with a unique theme, and then allowing them to share exactly what it is they need on their site.

      If a theme tries to be all things to all businesses, then the theme has no real identity.

  8. Michael Musgrove

    “These type of theme can earn more money and you have to manage & support only one theme.”

    That also can be said about a niche theme, if you do it right. You can even charge more for a specialized theme if it’s something like an e-commerce theme or some other specialized functionality and depending on who your target market is. You also don’t end up trying to help and please everybody on the planet and their brother; you’re just dealing with a subset of customers and theme features which is often much easier as far as support is concerned. And your support reputation can make or break your business. Plus it’s easier to market because you’re focused.

Leave a Reply

© 2020 Tom McFarlin

Theme by Anders NorenUp ↑