When you build a plugin or theme, I’d encourage you to really think about whether your settings page is really needed. Have you added the settings page just because it’s the normal thing to do? Maybe because users expect there to be a place to go and “configure” the plugin? Perhaps you just didn’t think about not including it? It’s true, settings pages are very, very standard in themes and plugins, but I challenge the idea that they are always needed.
I am going to show you an example plugin (one that I wrote) and walk you through why no settings page is needed.
Let me introduce you to Sugar Event Calendar: it is a free plugin (with paid upgrade) that I wrote for adding a simple event calendar and management system to your WordPress site. When writing it, I wanted the plugin to be very, very light weight, and also very simple. When a new user installs it, they should be able to have their event calendar setup with real events in less than five minutes. I believe I achieved that, and I also believe it is in part because there is no settings page, none at all.
If you do a search for “Event Calendar” on WordPress.org, you will find a lot of options, and nearly every one boasts a settings page, many of them listing it as a feature.
What exactly is the purpose of a settings page? Well, that’s simple: a place to configure the options of the plugin.
What kind of options does a simple events calendar plugin need? Several:
- An option to choose the day of the week that is the start day (usually Sunday or Monday)
- An option to set the date format shown on events
- An option to set the time format shown on events
- Perhaps an option to choose the style of the calendar (if options are provided)
These all seem like valid options, right? Absolutely! But did you know that each of these (excluding the style option) is available as a WordPress core option already available in the main Settings section of the WordPress Dashboard?
When you build a plugin or theme, make sure that you are leveraging the settings already made available to you by WordPress core.
Sugar Event Calendar manages to not have a settings page because it utilizes the options already provided by core. Instead of creating another place for a site owner to configure yet another date format, I chose to simply use whatever was already set. And I did the same thing with the time format, as well as the week start day.
To use these options in your plugin or theme, just call get_option() with the appropriate option ID:
- Date Format: date_format
- Time Format: time_format
- Week Start Day: start_of_week
What about styling? Obviously many, many plugins and most themes include optional styles that users can choose from. How does one make these available without a settings page? Quite simply, I don’t, at least not with Sugar Event Calendar. I opted for something much simpler: no optional styles at all.
Perhaps it is the minimalist in me, but I really, really prefer plugins that load very, very little CSS on the front end, not because of load times but because I would much rather have the plugin adopt the styles of my theme. That’s the point of a theme after all, isn’t it?
Sugar Event Calendar has 21 lines of CSS, which is just enough to ensure that elements are properly laid out and have some very basic styling. The rest is handled by the theme. By doing it this way, Sugar Event Calendar integrates with almost every theme perfectly. The only themes, in fact, that it doesn’t work well with are themes that haven’t accounted for all or most of the standard HTML elements, but it even works pretty well with those.
This is an approach that I have adapted with my Easy Digital Downloads plugin as well, as has the very, very popular bbPress plugin.
The next time you write a plugin or theme, really think about whether your settings page is necessary.
For themes, I don’t think it’s necessary. Especially with the Customizer features of WordPress.
I agree. The theme customizer is awesome and a truly great way to avoid an unneeded settings page.
I never go overboard on my themes for my clients since our sites we develop are not for mass distribution or for any market place. Having 85 fonts, colours, sizes to choose from only confuses and bloats the interface.
However… Do to the nature on how we build our themes I have found some very legitimate uses of a theme options panel (especially for call to action configurations on a home page for example).
Its rare we offer more then 4 to 5 options per site and they’re typically always justified. So I do agree having an option for your Google analytics code which will most likely never need to be changed is simply overhead, yet in my work habits a simple straight forward themes panel has been a saving grace:)
Absolutely. Theme options (and plugin options) are definitely great to have in many, many cases. My point is simply that developers should seriously consider whether they are actually needed. If they are needed, fine! Nothing wrong with that at all.
Do you think it is unreasonable or preferred to put settings into a configuration file instead of adding the overhead of option pages, etc for a plugin?
If the file is designed to be opened and modified to configure it, then no, I wouldn’t recommend that. If you are simply making the options available for advanced users because normal users will never need them, then great.
WIth themes I really think it comes down to the fact that customers believe they NEED the options. If you have two similar themes, they’re likely to choose the one that provides a ‘Theme Options Panel’. Even if they have no intention of really using the theme options, they want it and will pay for it.
However, the Theme Customizer is definitely a game changer and something that theme authors should be leveraging in their themes. It’s definitely a better solution than including Theme Options.
Personally I don’t think the customers sense of need is a good reason to build something. Customers thought they needed hundreds of short codes and other features, but these have turned out to be something that plagues the industry.
There is a large responsibility for product producers to help teach the customers about what makes a good product.
Last time I checked bbPress had a settings page and a CSS file with more than 800 lines. I do, however, agree with you that themes generally don’t require a settings page.
It does indeed, but as I walked through in my presentation at WordCamp Louisville, bbPress only has the settings that are necessary. For how much the plugin does, it could easily have pages and pages of settings, but it doesn’t, in fact, it only has about 15 options.
Be aware that a different format for a calendar is often useful. If your date format for articles is
l, j. F Yyou probably don’t want that in a rather condensed like a calendar.You might not need a separate page for that, the section
'general'can be extended. But it should be possible to use the date format that fits best where you need it.(Side note: Please enhance the contrast of the
textarea, I had to disable the stylesheet to read my own text …)That’s a very good point, but personally that’s what filters are for: providing means to change options that the vast majority do not need. My example plugin uses the default date formats for all dates, but dates are also all passed through a filter to allow them to be changed.
Thanks for the note on the textarea.
I’m just finishing my Twenty Twelve child theme today and I rolled any custom settings right into the Customizer. It’s wonderful being able to get modular interactivity in a built-in live-preview environment like that — so much better than any theme settings page I could muster on my own. Plus, users gets instant gratification which is a great “selling” point.
What’s your take on printing CSS vs putting it in a stylesheet? I try to keep it to a minimum, probably because I think it’s just kind of tacky to print it in the source.
The customizer really is awesome.
I would always suggest using a stylesheet. By doing so and assuming you have enqueued it, you provide others a method for removing it completely.
First, I agree with you – I only think it’s worth adding addition pages or options if they are absolutely needed. Don’t introduce something that’s already available somewhere in the WordPress core.
The thing is, I don’t think developers pay that much attention to what’s already available, or they aren’t exactly sure how to retrieve those values that ship with WordPress (sounds a bit lame, but believe it … I’ve seen it).
To the point about the Theme Customizer, I think that it’s a huge improvement that allows users to see exactly what’s available to customize an existing theme before installing it, but I don’t think it negates the user of settings pages.
Case in point: One of the things we tried very hard was to keep the options page for Standard very simple. It only includes what’s needed (such as, say, a layout change). Because the Theme Customizer has an API, we added our option for the layout to it.
Anyway, the bottom line remains: adding something to a UI that’s already relatively complex is costly, shouldn’t be treated lightly.
In an earlier comment I already agreed with what Pippin said. What is absolutely necessary, though, is debatable.
I am the author of an events plugin for BuddyPress. During the life of the plugin I was asked to modify it so it can serve different purposes than just events, so I added options to edit the slugs of the various plugin components, therefore making it possible to use the plugin for things like showcasing trips or camping grounds.
These options aren’t strictly necessary, but they open up a lot of possibilities to put a plugin to alternative uses.
I’m almost finished with a complete rewrite. While I approximately halved the available options, I still kept the slug editing around, just because it allows for a more complete customization. bbPress is another example that lets you modify slugs, btw.
All I’m basically saying is that you should have a very good reason for every single option, rather than only include absolutely necessary options.
Absolutely agree.
Great one! When i created the plugin called Freelancer Widgets Bundle i applied this method. Someone asked me if it was possible to add the timezone to the opening hours widgets, and i was about to add a specific field for this entry, and i remembered that you wrote this post, so i just used the wordpress default timezone. So much simplier!
About customization, i created CSS classes for every single element outputted by the widgets and added to every widget a “Custom CSS” zone (a textarea) where users can customize their widgets without having to modify any file.
I don’t know if i used the best practices but i think it’s not that bad. Thanks Pippin!
It always pays off to remember the default options 🙂
Hi, just read this post and I immediately knew an exception where one should have a settings page (since the exception is me). My company uses a multi language WP install, Dutch and English. Therefore I’m really happy with settings pages where I can adjust the date_format, time_format
and start_of_week. All three are different in dutch and English, so I’d even require a settings page for each calendar.
Leaving out code and/or functionality is an art though and each situation needs different things removed. The difficulty lies in finding the balance between the common and the exceptional situation.
After reading your post, I’d vouch for optional settings pages.
That is a perfect example of when settings are definitely necessary. Note, I’m not saying they’re never needed, just that many plugins / themes could do without.