Get it All
Together

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

I just thought I’d write a note about the new Favorite Actions bar in the new version of WordPress. This seems to have been designed as a way to mollify the concerns of the people who used to like the old layout of the administration areas better. But it’s a handy little shortcut to important things and of course, there’s a natural tendency as a plugin developer to want to utilize this space for your own plugin.

In fact, I was looking up how to do this very thing when I happened upon this page. The author cautions, quite rightly, that using this shortcut bar too much will end up clogging the thing and making it useless.

So, it seems to me that the responsible solution for plugin developers who want to make use of this new space would be to make it an option of your plugin which is always disabled by default. Doing so would allow your plugin users to make their own choices about which options to include in the favourites and which to leave as standard options. It is, after all, called a “favorite” actions bar.

In fact, I am hoping that future iterations of the WordPress core will include options to make this bar genuinely customizable according to your own preferences. The combination of a customizable favorites list and optional inclusion of plugin functions would represent the best of all possible worlds for this easily abused space.