As you would expect from a powerful content management system, WordPress has a lot of settings. By default there are no less than seven different settings screens for you to work through. From setting your site’s title and tagline to your permalinks, WordPress has you pretty well covered.
As such, you might be forgiven for not wanting to see even more options to tweak or modify your WordPress site. But in reality, there are plenty of things I would like to do that are not possible via the available default settings. The kind of things that you have to do yourself manually, or download individual plugins for. Not all of us want to get our hands dirty with code (or know how to), nor do we want to install plugins that only provide a single solution to a minor issue.
Wouldn’t it be better instead if a plugin were developed that packaged and presented a number of common desired WordPress settings that are not available by default? That is exactly what WordPress Helpers sets out to do.
Introducing WordPress Helpers
According to the plugin’s page on WordPress.org, WordPress Helpers “opens up the missing settings you wish were in WordPress”. If you want a full overview of the plugin and have 30 minutes to spare, check out this comprehensive presentation by one the developers, Steve Bruner:
Otherwise, here’s a list of the top features available via WordPress Helpers:
- Remove the frontend admin bar
- Edit the backend admin bar
- Quick and easy maintenance mode
- Admin messages
- Set default text editor
- Remove visual editor
- Remove unwanted elements from the template header
- Remove unwanted widgets (goodbye Calendar!)
- Allow shortcodes in widgets
This plugin is especially helpful for WordPress developers that work with clients. As you can see from the above options, it includes a whole load of ways in which you can implement restrictions (such as disabling the theme switcher) to stop inexperienced WordPress users from unwittingly breaking their site.
WordPress Helpers is built upon the PIKLIST Rapid Development Framework that aims to make plugin development easier. This isn’t particularly relevant to you — all you need to know is that you must install the PIKLIST plugin in order for WordPress Helpers to work.
You can access WordPress Helpers via Tools > Helpers:
As you can see, the various options are broken down into individual tabs, a la the default WordPress settings screen. Upon installing and activating WordPress Helpers, you’ll want to browse through each tab to discover what is possible. You may find something that you didn’t even know you wanted to do (as I did).
A Must-Have for WordPress Users?
Personally, I would remove a bunch of the default WordPress settings and include plenty from WordPress Helpers — such as the ability to edit and remove the admin bar, shortcodes in widgets, text editor display options, and so forth. Whilst it isn’t a “must-have” plugin, WordPress Helpers can make your life a whole lot easier and enable you to make some rather useful tweaks to your WordPress site. And as I said previously, if you are working with clients, it can be a godsend.
With that in mind, I’d love to know what you think about extra settings for WordPress. What options would you add to WordPress in order to mould it into something that you prefer to work with? Let us know in the comments section!
Elliott Richmond
Neat! Going to have a good look at this for upcoming projects.
Steve Bruner
Hi Tom–
Thanks for reviewing our plugin. You did a really great job.
We are developers as well, and used most of this code on our clients websites. It just started to become a hassle placing it in functions.php, so we put it in a plugin. We found it incredibly useful, and thought the community could benefit.
Thanks again!
Steve
Mike Schinkel
Hi Tom,
Looks like Options, not Decisions, which is appreciated. 🙂
-Mike
Shea Bunge
I gave WordPress Helpers a try back when it was Reviewed on WPMU.org. At first, the plugin sounded really good.
My problem is that it is reliant on some ‘bloated’ framework, which is not needed to change the WordPress settings at all. It’s just used to add the options page. And on top of that, the framework creates a new top-level menu in my dashboard. 😡
A lot of people might not agree with me on this, but I think that it’s better to take the filters and hooks out of the plugin’s code, and then add them to functions.php or use the Code Snippets plugin. This way, you’re only using code that you actually need, and you can rid of the rest.
That said, I wouldn’t have a problem with this plugin if it was self-reliant and used WordPress’s own methods of doing certain things (like adding tabs to options pages) instead of re-inventing the wheel.
Just keep in mind that this is my opinion and my problem, so if you disagree with me completely, then that’s fine. 😀
Tom Ewer
Top level menu? I must have missed that — I accessed it via Tools > Helpers.
You’ll have no argument on me RE Code Snippets — you know I love it. But for people who don’t like to get their hands dirty with code, or want a quick and easy way to set up new client sites, I think this is a viable solution.
Cheers,
Tom
Shea Bunge
I like that actual plugin as well – I just don’t like the fact that it is based on a plugin framework. The framework is one one who adds the top-level menu, and it really isn’t needed for a relativity simple plugin such as this. Perhaps I’ll give WordPress Helpers another go.
Steve Bruner
Hi Shea–
I understand your reluctance, but, I think “bloat” is an excessive term to call Piklist. Without Piklist, WordPress Helpers would be 3x as large… still smaller than Piklist, but also much larger.
Piklist is a framework that does things the WordPress way… it just makes it much, much easier. In this case, it not only creates the Settings pages (using the WP Settings API), it creates the conditionals (with jQuery) and also has a few helper functions that made things dead easy (check out the Piklist key_path function).
As for TABS, if you know a WordPress function to create them on settings pages please let us know and we’ll implement. Piklist currently does it the way most tutorials recommend.
Stay tuned with Helpers… we will be implementing more features!
Mike Schinkel
Hi Shea,
I hope Tom doesn’t mind me jumping in here to satisfy my curiousity but if you don’t mind I’d love to explore the concern you have for the Piklist framework being “bloated?”
My reason for asking is that I build plugins too and currently plan on releasing several things in 2013 that could be characterized as “frameworks”; WordPress-specific APIs that plugin developers would use to build their own plugins. So I’m interested in learning about user perception related to plugins.
When you say it is bloated is it because:
1.) You’ve been told that too many plugins is a bad thing and assume that it would cause your site to load slower?
2.) You don’t like the fact “Piklist” must be separately installed and then is visible as an additional plugin in the admin in the list of active plugins?
2.) You don’t like the fact it adds a “PikList” menu to the left-hand admin menus?
4.) You’ve reviewed the source code for “PikList” and know specifically that it has code that would slow your site down?
or
5.) Some other reason I haven’t considered?
Alternately what if Piklist were simply embedded in WordPress Helpers so as not to require you to install and activate it and if it did not include the Piklist menu yet still contain exactly the same code otherwise? Would you still feel it’s bloated and if yes, why and would there be something that Piklist could differently so you wouldn’t object to it as bloated?
Thanks in advance for helping my understand your perspective; if I’m going to release frameworks I certainly don’t want to release ones that would cause end-users to feel plugins that use them are bloated.
-Mike
P.S. Also, I might follow up with some more questions after you reply, if Tom and you don’t mind.
Shea Bunge
I wasn’t really accusing Piklist of being bloated, it was just a general remark. I guess that it’s that you have to install two plugins for one, and that second plugin manifests over your admin with the top level menu. I wasn’t being too serious with my comment; it was just a minor concern that I thought I would voice.
As for (1), I am aware that you can have ten plugins consisting of a few lines of code, and the impact will effectively be be the same as one plugin with heaps of code and multiple file includes.
In my opinion, the framework should be ‘invisible’. That means no top-level menu and no second plugin. Bundling the framework into the plugin itself would be ideal. You could implement some logic to check if the framework has already been loaded (by another plugin) and skip loading the bundled version.
I don’t particularly mind installing a framework in order to use another plugin. I was really thinking from a client or WordPress beginner’s point of view. As a developer, I prefer to build self-relent plugins. If I need some specific functionality which can be found in another plugin, I usually copy the code from that plugin and modify it to suit my needs.
If you would like to ask some more questions, you can either reply to this comment, or get in touch with me on my website.
Mike Schinkel
Hi Shea,
I really appreciate your reply; your answer gave me what I was looking for. If I understand you the issue with bloat is the fact that it shows up visibly for end users to see and that it requires extra work to set it up and manage. If it were hidden from the end user it would otherwise be fine.
Speaking of checking to see if the plugin has already been loaded, I’ve literally just finished implementing a library for (almost) exactly that, called Imperative. It’ still very much alpha for general use and has yet to be documented but I am about to use it in a client’s plugin onto WordPress.org. It actually manages embedded code as other “libraries” (my term) vs. “plugins” proper, but for the most part there’s no reason a plugin couldn’t be used as a library (i.e. a package of code that is embedded within a directory of a plugin and otherwise invisible to the user.)
If you are interested in seeing the code for Imperative it’s on GitHub although there are currently no examples posted of it’s use. Soon though.
Frankly I’m really hoping that Imperative or something similar to Imperative gets included in WordPress core soon and I’ll be advocating that on Trac once I have time to document it. I think it would really help move WordPress forward if plugin developers could start collaborating on and sharing API level libraries rather than being solely depending on the core team’s interest in moving forward with the state of the art in APIs that can be used in WordPress.
And thanks a bunch for your link to contact you but fortunately I think you fully answered my questions. If you wanted to contact me for any reason though, you can do so here.
-Mike
P.S. Your site was down with a 503 error when I checked the link. Might want to fix it?
Sarah alawami
Wow. looks good. I’ve wanted something like this for the year I’ve used wp. I triple hate editing that functions.php file or what not just to make stuff go by by. This looks cool. Will try it on one of my other sites once it’s back up as right now it is not. thanks for this you guys.
Tom Ewer
No problem Sarah 🙂