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.