Developing WordPress: The page template/meta fields struggle

One of the biggest hurdles when developing on WordPress for clients is making the end product as intuitive as possible for whomever will be editing the site’s content once you hand it over. Let’s face it, formal documentation takes quite a bit of work to assemble and amounts to the least enjoyable part of a project. Really, in most circumstances, small- to medium-sized sites should be plug-any-play for the client.

Really, in most circumstances, small- to medium-sized sites should be plug-any-play for the client.

The challenge I come across often is with complex page designs that contain various blocks of content. It’s cases where a page template contains several different areas of content that handling how the user manages that content becomes a bit complicated, and  the process strays from intuitive to abstract for the client. The three most common solutions I find used are as follows:

• Posts as content blocks. Even when the content areas are static and specific to just one page, often a site will ship with posts categorized by the page they are to appear on. Worse, sometimes the template actually calls specific post IDs. Template files, should never, ever, ever use specific content (or user, or taxonomy, etc.) IDs, and an options page with drop-downs is a half-assed workaround. This process makes the concept of a ‘post’ totally abstract to the user. Why can’t I edit the content in the ‘page’ editor?
• WYSIWYG Editor Formatting. TinyMCE is a decent editor but let’s face it, you simply do not rely on it to keep track of more than lists, paragraphs, and some inline formatting. Asking a client to enter code view, ever, is a sin in my book.
• Custom fields. Probably one of the better approaches, but not without its problems. Using custom fields on individual pages creates global entries in the wp_options table, which show up in all instances of that Custom Fields meta box. Why should the client have the option of entering phone_number and address_1 on the Gallery page? the global level is problematic in this case, and the custom fields interface as a whole is not as intuitive as one would like.

None of these solutions is ideal. They each have potential to confuse the client, screw up the display of the page, or result in emails to you when you haven’t included ongoing maintenance in your invoicing, but you can’t ignore because they’re a result of the clarity of what you delivered.

So, how do we fix it?

I’ve had a solution in mind for months now that I can’t find any problems with. Before I begin, let me say, I work in the template level in WordPress. I build functionality that works as plugins, but in themes – I get fairly involved with the core and its hooks, but I am not a core developer. The feasibility of this seems real to me, but it’s completely possible I’m not seeing a conflict in core implementation or hole in my logic. I welcome any and all feedback.

The same way you can use <code>add_meta_box</code> to add meta boxes in custom post types content types (really, they’re not ‘post types’, I don’t know how they got this name), we should be able to use a similar function (or perhaps the same function with a new argument using the template name) in the context of a template, and its callback to add new fields . The rest is the same as with custom content types as well – the <code>save_post</code> hook to collect your custom fields and any necessary JS or CSS included in the admin dashboard using <code>wp_enqueue_style</code> on <code>admin_init</code>.

The concept is simple, once you select a template for a page and update the page, the new fields become available. If you or the client changes the template, you can change it back without losing any data as it’s saved as meta data and is not removed when the template is changed. Within the template file now, you can use <code>get_post_meta</code> to collect your custom fields, again, the same as with custom content types. These custom fields are completely contextual to the template file you’re working in, and this file is not used unless the template is selected for a page. There are no conflicts, no confusing or unusual interfaces, and the code (if implemented as I’m seeing it) is nothing unheard of in the WP documentation.

These are quick thoughts, but the idea’s as developed as it can be for myself – I would love some insight, positive or negative, as long as it’s constructive into the development of this or reasoning why it’s unnecessary.

A slightly belated happy holidays to everyone, hope you had an excellent Christmas if that’s your thing!