To me the difference between user, theme developer and developer is clear:
- the user is the client, the one that will get a finished theme or site in its hands and that will probably access WordPress backend with an Editor role most of the time and as an Admin role at times.
- the theme developer, in an Headway-centric vision, is the one using Headway blocks and their options to create the layouts required for the agreed upon theme to become reality.
- the developer is the one creating and maintaining plugins, among those Headway blocks, that both the theme developer and the user will benefit from.
The way I do it
It’s standard practice for me to create an extra user role in WordPress site to add a role between the Editor and the Administrator, that extra role I call the “Manager” and will grant that user the capability to edit theme options. In WordPress terms the edit_themes and edit_theme_options are added to the default Editor role.
The reason I do it is because giving a user that just wants to change the theme background the possibility to change theme altogether and install and remove plugins that might be part of current site implementation really feels dangerous: to me it ruins the “hands-off” approach a WordPress site offers for the client that paid the theme developer to create, in the first place, a simple theme.
The user should be dealing with content and some esthetic options, corralled inside the design boundaries, only.
Theme options
Headway comes with options for the theme developer at design time but with no options, beside the standard ones (site title, tagline, navigation and static front page), at user time. Hence the user will not get the options to, say, set the body background for the current, made with Headway, theme. And I do not think directing or forcing a user to meddle with the visual editor is the way to go: it could easily get lost as well.
Connecting the dots
I’ve used Customizr theme recently for a client work and, once the Manager user was created, the client took great pleasure in the possibility to customize theme appearance. A look at that theme will make clear how safely and logically that works. I, the theme developer, win in giving the client a theme he can customize to a point where the overall layout is not destroyed and the client wins being able to choose color, background, logo and so on.
That’s not the case with an Headway standard installation and that’s quite limiting due to the fact that theme options, the one the client can fiddle with in its Manager role, should be added and took into account into the theme itself. By their nature those make no sense in a plugin: they really should come baked with the theme.
To make a practical example:
- the site manager should be able to set the theme all-around color couple (like “orange and black”)
- the theme developer should be able to work independently of the chosen value working instead with “dark color” and “light color”.
Getting code practical
Whatever the user side and the theme-developer side of an option are both will access the same theme option to an end: the user to customize and the theme developer to actually present content. Say the user is given the option to show or not show the featured image in the post preview (a very common option in a theme): that choice will have an impact on the preview layout and a theme-developer should be able to take that into account being able to decide, in the visual editor, how the current block will react to that; Headway default content block will leave that choice to the theme developer while the user will have to call the theme developer to make such a choice: not my idea of a WordPress theme.
In the next post(s) I will try to build a block that will hopefully allow such double-sided cooperation.