I’m really excited about the forthcoming Roots plugins. I’ve already used the H5BP .htaccess plugin for a while, so I had a look at the Roots Wrapper Override plugin.
I am probably being very slow here, but can someone explain what it actually does and why I would need it?
Is the $10 for use on one site or unlimited sites?
Thanks for the feedback. I’ll be adding a video to demo the plugin next week.
The plugin is there to complement the Roots wrapper and works in a similar way to the custom page templates, allowing you to easily choose which wrapper-selected templates get loaded on a per page/post basis. It’s a real time saver and easy enough for most clients to handle.
In the admin, it will search for all the available template files and create a meta box on the add/edit pages with a drop down for the user to select their desired template. i.e. all
base-*.php will be selectable for the base file, and all
templates/sidebar-*.php files will be available for the sidebar. It supports nice names using PHP comments or displays the filename.
The chosen template will be saved as hidden meta data, and in the front end, a filter is run that will ensure this template gets loaded ahead of the templates chosen automatically by the wrapper; hence the name.
It’s easily extendable without editing the plugin files, so you can have control over any other page elements loaded by the Roots wrapper. The example above allows the end user to control a pre-defined banner area; great if you have a combination of adwords and page specific sponsors/affiliates.
It works for pages, posts and also supports custom post types.
If you want to reuse the whole thing and expect support then I would encourage a sale per domain; it’s usually an easy up-sell to clients so everyone would be making money.
There’s no serial to limit installs as I wouldn’t want to impact performance. Also, as with all WordPress plugins, the PHP source is technically GPLv2 or later. So you could strip the source and use it on as many sites as you like but you’d need to keep the copyright notice in tact, replace the README.md with your own text and support it yourself.
If you have any more questions let me know.
Thanks, Nick. This makes a lot more sense.
I’d probably need to see it working in practice, but how does it work with different post types (pages, posts, custom post types). For example, it might not be a good idea for a client to select “gallery” when it is an “event” post type! Can you restrict which templates appear for a particular post type?
I assume we can change the meta box name from “Roots Wrapper Overrides”. The words Wrapper and Override won’t mean much to most clients I don’t think.
One project I am working on can have up to 2 sidebars. Some pages are full width, some have a left sidebar, some a right sidebar and some have both. How does this cope with that?
Thanks for clarifying the cost and what it covers. Certainly, I would have no problem factoring in the cost of the plugin in what I charge a client. I tend to have a live, development and staging version of each website, so as long as I could use the plugin with one license I would be very happy.
I counted four points, I’ll address each in turn:
There’s no administration panel at the moment because of the bloat. But it’s incredibly easy to initiate the plugin on a per post type (or per user level) basis. So you could easily have different sections available on different post types, or just remove the base file option on pages that you don’t want/need the option given. I put these kind of settings in the
The plugin name and the short support text is translatable, but I’ll add an easier way to change this in the next iteration. I’m also open to other feature requests, provided they don’t over complicate matters or slow it down. The whole point is the plugin is for developers to install and customise, but straightforward for end users to operate.
Again possible, but only by customising the initiation. I looked into activating the sidebar override according to the
Roots_Sidebar class, but the lack of conditional tag support in administration made it problematic. I may revisit this in future versions but it won’t be incorporated unless it’s fully working and without nasty hacks.
I’m a developer too and would never penalise best practices; use it on as many development or staging boxes as you like. As long as each production site is paid for, I’ll be happy. I’d also be happy for (and would expect) the dev to use it on their own production site in addition to one client production site, with one purchase.
Just purchased this yesterday, served me well on a local site but when I moved it to a server based multisite it’s kind of hiccuping. It installs perfectly fine on the network and even loads up the meta box on the page screen but when I try to set the page to a different base it will not stick. After publishing the drop down automatically switches back to no override.
Let me know if you can offer any guidance.
I’ve sent you a PM with my email address. If you can contact me over the weekend that would be great.
Just to let you know I purchased a few days ago too. I installed it without any issues. I’ve yet to have a proper play with it though. I’ll let you know how I get on. Thanks!
The issue was with file validation on a multisite with domain mapping; I doubt it will come up again!
It’s fixed in 0.9.1 which will be released by Monday. It will also feature the title customisation options requested by @iagdotme.
Cool! Looking forwards to it.
By the way, will we be notified of future updates by email?
Yes. Future updates will be emailed. You should be able to re-download the latest version on Gumroad too.
Edit: Version 0.9.1 should now be making its way to you across the 'net.
Just downloaded and installed. Looks good so far, and great that you can edit the text. Thanks!
Terrific update Nick, the plugin is working like a charm and offering the exact functionality I was looking for. I really appreciate your support over the weekend and I am certainly looking forward to working more with roots wrapper override plugin.