Get it All
Together

One of the most important concepts in the world of WordPress web development is that of the parent/child relationship between themes. The parent/child relationship is a scenario in which a “parent” theme represents the final source of all code: if you cannot find a given file in a theme declared a “child” of one parent, then you should be able to find that file in the parent. The purpose of this relationship is to allow the child theme to extend and enhance the parent theme as suits a given website’s needs, while still maintaining the base level functionality of the parent theme. This failover system further augments WordPress’s excellent Template Hierarchy structure, guaranteeing a suitable template layout file for any request.

When properly understood and executed, this parent/child relationship allows developers to build complex parent themes from which all manner of new websites can be built in the child theme. Doing so is a sure-fire way to maximize the learning curve of your software: new techniques and interfaces can become available to the next project, instead of stuck in a single-site solution.

In my case, my parent theme is really just a toolbox of functionality and layout helpers with almost no usable layout of it’s own: it provides the toolbox and a few baseline layouts like a generic archive and single-post page. All the implementation of that toolbox happens in the child theme. I have even augmented the parent/child relationship a bit by providing failover support for JavaScript files and non-layout files in my theme.

That said, I’m always looking for better ways to make use of this relationship. So I was pretty excited when I found out that Advanced Custom Fields comes with the option to save it’s field declarations as local JSON files. I’d previously been doing all the work of creating Custom Post Types – and their backend interfaces – more or less by hand. But having worked with ACF for a bit, I realized it was a more efficient means of adding meta fields by miles.

Now it seemed, I’d found a way to statically create the fields I needed for my base CPTs and have them extend and be extended by a child theme. Perfect!

Not So Perfect, Yet.

Now, I’m pretty particular about my directory structure for my plugins. I like things organized more like the PSR2 standard prefers and fortunately, the WordPress-Core standard also recommends something similar. With that in mind, ACF’s default location for local JSON does not suit me. I’d rather not have an /acf-json directory in the root of my theme. Instead, I’d prefer to have my ACF-specific JSON files live somewhere in the /Library/ directory of my theme.

But there is a solution for this! Advanced Custom Fields provides filter hooks in that part of the code that saves and retrieves JSON, as they explain in the documentation for local JSON. Those hooks are ‘acf/settings/save_json’ and ‘acf/settings/load_json’. So my first attempt to move the JSON to my desired destination looked like this:

The persistent problem I ran into with this setup was that ACF seemed always to be confused as to which directory it should be saving and recalling from. If you read through that code, it at least attempts to establish the same parent/child relationship as WordPress uses for standard template files. New changes to Custom Fields should always be stored in the current (most often, the child) theme directory. When pulling JSON to populate fields, a child theme’s /Library/Acf-Json folder should be used first, followed by the parent theme.

But in practice, after successfully changing a field name in a child theme, the Custom Fields admin pages would show the correct new name and the Write Post screen would display the old name. Those fields did not present the option to “synchronize” themselves, so there seemed to be no real fix. This was all discussed with the forum help at ACF here.

After a bit of digging and considering and reading the actual ACF files in question (/advanced-custom-fields/includes/wpml.php, if you’re interested), I decided that rather than simply add my own code to the acf/settings/save_json hook, I would remove the default function completely. By doing this and using array_push to be sure I was saving the directories in the correct order, I was able to achieve the the correct functionality. So I commit this blog post for the benefit of those who find themselves similarly challenged by this super-helpful but perhaps less than well-documented feature of Advanced Custom Fields:

As much as I love WordPress, I am continually frustrated with the pace at which forms get created. That’s because, while WordPress seems to have thought of everything else, the most basic part of creating interactive websites seems to have been ignored: the forms.

Yes. There are front end form builders like Ninja Forms. But while they all work well within their own context, much of the customization of the forms either requires additional, paid-for plugins or simply isn’t possible due to constraints of the plugins themselves. Besides which: I’m not often building front-end forms, but rather forms to add metadata to posts or set configuration variables for the site.

What I have wanted and needed was something like CakePHP’s FormHelper: an interface that simplifies the process of outputting HTML5-valid forms and inputs. Something that allows me to specify the settings for an input, and puts the aggravating process of laying out the form in it’s own hands. And so I created EasyInputs: A Forms generator for WordPress.

The plugin is still in early stages of development. But so far, I’ve been able to clean up and cut down on code for one of my other projects significantly. And besides speed and accuracy, there are a couple of key advantages to building forms in this way. For a start, if you’re trying to keep your WP code as close as possible to PSR2 standards, adding values to an array is a lot more convenient than sprintf’ing the long HTML code associated with forms. Secondly, the code output from my plugin is significantly clearer than a rat’s nest of escaped and unescaped HTML code.

WP-Scholar’s Person CPT with escaped HTML:

WP-Scholar’s Person CPT with EasyInputs:

This is just a relatively basic example. The plan is to support every HTML-valid input including <datalist>, <keygen> and <output>. Right now, these new elements are missing. I’ll be updating that shortly (perhaps before you even read this!), along with some basic HTML security: every EasyInputs text input will include the maxlength attribute.

I know that the WordPress devs are working on some sort of fields API. But as I’ve observed it, the development process still banks too heavily on bringing those fields into the WP regime, which may satisfy the needs of the WordPress team, seems too rigidly focused. Developers don’t need a complete solution for every little thing, they need simple tools that do simple things well. That’s the aim of this development project.

Please have a look at the latest stable tag and tell me what you think!

I’m sure I’m not alone among developers who are continually frustrated by the lack of imagination shown for implementing the Customizer in WordPress. Sure, I have praised its existence and support its use to replace the labyrinthine system of developer-created admin pages. But then once I got into serious development work, I quickly found that having all the HTML controls handed to you means having the ability to decide how they get rendered taken away from you.

For example, I’d like to give users of my core theme the option to define the number and content of columns on their site. Doing so obviously means creating repeating fields: first, you define the user-specified number of columns, then you produce enough identical fields as necessary to define each column. In my case, that meant providing an ID, column width at various responsive sizes and of course, the content of the column.

Yes. I could certainly decide that no one needs more than four columns and just assign each column it’s own static block of controls. If there’s no Column 4, then those settings are just ignored. But this is a sloppy way to build a UI that is going to naturally lead to some confusion when changing settings never seem to have any effect. Better, then to just have dynamically created settings blocks. One drawback: the Customizer API has no repeating fields and doesn’t even include a vehicle for a button that doesn’t submit, leaving you without the option to create a JS-driven solution.

After months of frustration, I eventually found Kirki. Now, we are talking! I currently include Kirki as a Composer package into the core of my base theme, but it’s also available as a plugin for those who would be more comfortable with that solution. From the Kirki homepage:

Kirki is a Toolkit allowing WordPress developers to use the Customizer and take advantage of its advanced features and flexibility by abstracting the code and making it easier for everyone to create beautiful and meaningful user experiences.

So, it’s not an entirely new API or a replacement. It simply harnesses the power already manifest in the Customizer, but gives it a few gooses that make it a whole heck of a lot easier and more flexible to use.

Using Kirki

Kirki frees you to create forms that properly express what your theme does, rather than having to build all that functionality into your theme or worse than this, simply allow your theme to be driven by the limitations of the current Customizer UI. A full spectrum of HTML5 form elements is introduced, along with a plethora of more exotic controls. Especially useful for me – beside the repeater control – were the multicheck and radio-image controls. But there’s so many more that I’d like to play around with! Maybe for some custom implementations, I suppose.

Replacing the existing Customizer API calls with the Kirki API calls was a snap in fact, about the only confusion was that there was so much less code than before, I had to keep checking that I’d actually gotten all the controls passed over:

[php] // Icon Fonts:
Kirki::add_field( ‘hn_reactive’, array(
‘type’ => ‘multicheck’,
‘settings’ => ‘icon_fonts’,
‘label’ => esc_attr__( ‘WeLoveIconFonts’, ‘hn_reactive’ ),
‘section’ => ‘icon_fonts’,
‘priority’ => 10,
‘choices’ => ReactiveCustomizer::$icon_fonts,
) );[/php]

I use nine fonts from WeLoveIconFonts.com, so as you might imagine, a huge selection of code simply disappeared when this Kirki version replaced it. Who doesn’t love that??

As for building repeatable blocks of controls, this too is a simple matter:

[php]/*
// Columns:
*/
Kirki::add_field( ‘hn_reactive’, array(
‘type’ => ‘repeater’,
‘label’ => esc_attr__( ‘Column Definitions’, ‘hn_reactive’ ),
‘section’ => ‘hn_layout_defaults’,
‘priority’ => 9,
‘settings’ => ‘column_contents’,
‘default’ => array(
array(
‘content’ => ‘post_data’,
‘small’ => ‘9’
),
array(
‘content’ => ‘default’,
‘small’ => ‘3’
),
),
‘row_label’ => array(
‘type’ => ‘text’,
‘value’ => ‘Column’
),
‘fields’ => array(
‘col_id’ => array(
‘type’ => ‘text’,
‘label’ => esc_attr__( ‘CSS Column ID’, ‘my_textdomain’ ),
‘description’ => esc_attr__( ‘Any XHTML-compatible ID you like’, ‘my_textdomain’ )
),
‘content’ => array(
‘type’ => ‘select’,
‘label’ => esc_attr__( ‘Content’, ‘my_textdomain’ ),
‘description’ => esc_attr__( ‘Specify what kind of content will go in this column’, ‘my_textdomain’ ),
‘choices’ => $this->content_choices(),
),
‘small’ => array(
‘type’ => ‘text’,
‘label’ => esc_attr__( ‘Cols at small’, ‘my_textdomain’ ),
‘description’ => esc_attr__( ‘How many grid columns this column takes up at small and up sizes.’, ‘my_textdomain’ ),
),
‘medium’ => array(
‘type’ => ‘text’,
‘label’ => esc_attr__( ‘Cols at medium’, ‘my_textdomain’ ),
‘description’ => esc_attr__( ‘How many grid columns this column takes up at medium and up sizes.’, ‘my_textdomain’ ),
),
‘large’ => array(
‘type’ => ‘text’,
‘label’ => esc_attr__( ‘Cols at large’, ‘my_textdomain’ ),
‘description’ => esc_attr__( ‘How many grid columns this column takes up at large and up sizes.’, ‘my_textdomain’ ),
)
)
) );[/php]

I have so far found Kirki to be exactly the tool that I need, until of course WordPress comes up with their own solution.. and who knows when that will be?

For nearly as long as there has been a WordPress, themes have included a functions.php file. This file provides a lot of extra, for lack of a better word, “functionality” to your WordPress blog. And while so much else about WordPress has changed over the years, it is quite remarkable how little about the functions.php file has evolved.

This is particularly true in light of WordPress’ ability to create child themes. Child themes are separate themes which extend the functionality of their “parent” themes by overriding key theme files. A child theme may only have a style.css file, to refer back to the parent. Or it might include a single.php file, because in the case of this one theme, you want all the functionality of the parent, but you’d like single posts and pages handled differently.

The trouble is: while a template file can override it’s parent, the WP functions.php file just basically loads the namespace with a bunch of free-floating functions, usually prepended with the name of the theme. There isn’t any “overriding” a function in PHP; the only thing you can do is write another function with still another name or prefix. That’s not very efficient use of the namespace and a recipe for confusion.

Instead, what I decided to try was putting my entire list of functions inside a class. Call it ParentFunctions. Inside this class, I also included a self-named initialization function that would do the adding of filters and actions as necessary. Then, all I need to do is instatiate my object – and be sure to call the “global” in each file where its necessary – and I’ve got an extensible model from which to create child themes.

Let’s look at ParentFunctions:

Among the advantages, here, is that our namespace is much cleaner. So is our code: instead of having to trawl through a couple dozen prefix_function_name entries, I can get straight to function_name. But better still, if I want to modify how a function works in a child theme, that’s even easier:

Using classes in your WP functions.php file provides a cleaner, easier interface for extending your themes for whatever you need.

As always, WordPress continues to hustle through, onwards and upwards, towards their latest release. Looks like there will be a lot of concentration on media uploads in this new version, based on the polling data. Even cooler is the newest “trash can” feature for deleting posts:

via WordPress › Blog » 2.9 Features Vote Results.

Lower ranked features aren’t off the radar, but may take lower priority than some other (non-media) features we have in the works. One of my favorite 2.9 features is in trunk now, and changes the way we delete content. Goodbye, annoying popup asking me if I’m sure I want to delete a comment/post/etc. Hello, fast and quiet removal into a trash can, from which the content can be retrieved if it was deleted by accident. Think Gmail style. We’re also hoping to work on improving page management, though that has a number of technical issues that may cause it to be a 3.0 feature instead.

Back on the media thing, it would be nice if they expanded the media API to allow us developers to access the Media Library outside of posts. This might, for example, allow us to build themes with custom header images that users could upload to their Libraries and select on a config page. For myself, I would love to be able to update the DFE News Harvester plugin to include the option to use an image from the user’s Media Library.

The question is: how much of what they choose to do going forward is based on popular vote? Much of the WP community is non-developer, so while their opinion is important, its not the best way to push the platform in new directions.

I’m hoping a list of new features will be released ahead of development, just so we can take a peek.

I’m starting to discover reasons for which I might like to use a “Sticky” post on my WordPress blogs: posts which stay stuck to the top of your post roll on your home page. Sometimes, it’s better to have a small introductory post greet your visitors than to send them to a static home page with very little content.

But now that they have the sticky concept down, it’s time they added a filter option to the Edit Posts screen, as I suggested in the below Ideas page:

WordPress › WordPress Ideas — Idea: Display ‘sticky post’ icon on Edit Posts page.

An interesting discussion of the DOCTYPE declaration in WordPress themes. Seems to me that Alex is spot-on with this: you can’t claim a theme as XHTML 1.1 compliant because you can’t know what gets added to it by the end user. Sure, the *theme* might be strict as a school marm. But if the end user chooses to add all manner of sloppy JS widgets for MySpace and whatever else, the final result is not going to be strict at all.

I confess that, even with my own blogs, the “strict” doctype is probably over-selling a bit. Some times – even most of the time – the blogs are not going to be XHTML 1.1 compliant simply because I am constantly experimenting with plugins. Whether those are my own plugins which are currently in a state of disrepair or those I’ve downloaded from WordPress.com just to mess with, there is always the possibility of being out of standard.

And to be honest, while being XHTML compliant is a goal, its more of an ideal than a practicality under the circumstances. For professional paid gigs, that’s another story. But for this little site, well, I don’t call it my hobby horse for nothing!

}8{D>

It’s one of those bad habits we find hard to break as WordPress enthusiasts: installing plugins and then forgetting about them. This is especially true when you’ve installed them through the WordPress admin panels and then deactivated them because you decided you didn’t like them.

Well, now I’m getting very close to done with the new theme for DFE and I’ve got to go through all these plugins to find out what I’m keeping and what I’m not. You have to be very careful that the plugins you’re using do not conflict with one another or with template functions, and this new template is also going to be introducing a number of new functions and plugins both.

Because I’ve found that it just makes more sense to keep some things as template functions. I’ve not really bothered to play around with template functions because I’ve always seen the template as a display-only set of code. Indeed it is, but if there is additional processing to be done on display that isn’t needed anywhere else, WordPress provides the function file to deal with this. It’s not entirely MVC, but then, what is? Perfect systems don’t always work in an imperfect world.

Like eliminating unused plugins, moving display-altering functions to the template is about making things more efficient. If WordPress forces your server to spend time it doesn’t need to reading plugin files you’re not using, you take a hit on your performance. If you have functions which only operate on the display level, but which are contained in plugins, then each time any admin page is run, the plugin has to be turned on despite the fact that it will never be used. We’d like to avoid this, if at all possible.

On the other hand, adding huge volumes of code to your functions.php file has a similar effect: every time the front-end of your website is launched, you bog your system down with code. So, you need to balance what you use in the functions.php file and what you use as a plugin very carefully and make sure you’re using the most efficient code possible.

The WP folks are announcing the latest version of WordPress will be released some time later this month.  Granted, there’s not a lot left in the month and they’re only just beta testing now, but nevertheless they plan on releasing this month.  The new features are exciting to contemplate, but especially helpful to us developers is the new Widget schema:

via Version 2.8 « WordPress Codex.

WP_Widget is a class that abstracts away much of the complexity involved in writing a widget, especially multi-widgets.

They’ve basically created a new class from which all new plugin widgets can be produced.  This is, as noted, especially helpful when you want to have more than one instance of the plugin on the page at any one time.  The process for this has previously been laborious enough that I haven’t bothered to write any such thing into any of my plugins.  Of course, such labor-intensive duplication is silly when you use a language capable of near-OOP programming and apparently the powers that be WordPress now agree.

For those who are serious about cataloging and displaying news from across the Internet in one blog, I’ve created the DFE News Harvester Plugin. DFENH allows you to register a variety of news feeds, read them within WordPress, select the articles you’d like to publish and publish them as posts in a blog.

DFENH also works with WP meta data to provide a number of bits of data that you might want in a news article, such as a title, a secondary “teaser” title, an image with credit and a brief summary. It’s up to you how you want to actually use this metadata on your site: DFENH does not offer any method of displaying metadata on the site.

Another feature of DFE News Harvester is it’s ability to automatically create tags for each article based on it’s title. When a list of articles is submitted for publication, DFENH automatically breaks the title up by words, eliminates unnecessary words like “by, the, if, etc” and creates tags for each of the remaining keywords.

This is a plugin which will work in either WordPress or WordPress MU. However, this is not a plugin meant to run in the /mu-plugins folder and I have not tested it for that use.

To install, simply download from WordPress.org, drop the entire /dfe_news_harvester folder into your wp-content/plugins folder and activate through the Control Panel of your blog.

Is This a Splog Plugin?

You can use this plugin however you like, but I would submit that there are far more efficient methods of creating a splog than this plugin provides. This plugin is geared towards providing updated news content in a way that is administration-heavy, relative to splogging tools. It does not harvest content off the original website by itself, it does provide a method of renaming links and providing your own summary of articles.

I trust that everyone who uses this plugin does so with the utter-most respect for original content on the web!

Download this plugin