Get it All

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!

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.

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.

This plugin is deprecated and no longer maintained by the developer.

The new 2.7 version of WordPress MU is pretty awesome and I’m glad to have it running on both of my sites right now. There’s a lot 2.7 has to offer in terms of usability boosts, and while I balked at the redesign when it first started, I have to confess that there is much to love about the new layout.

However, one thing that’s been nagging me is the new Admin Bar functionality. It suffers from two things, in my opinion:

  1. It’s a blog by blog setting, not sitewide. This is fine for sites where you want savvy people to start blogging on your network. It’s less so for community based sites like mine, where the idea is a sort of news magazine site where consistency is key.
  2. Because plugins can add their own top-level menus, the Admin Bar can get a bit crowded and I’d like the option to add or subtract items from the list as I see fit. Again, it would be nice to have these settings happen globally rather than by site.

While I have not worked out the second problem just yet, I thought I’d go ahead and post my modified code to this site which allows site-wide settings rather than by-site. It also tucks the Admin Bar settings under the Admin section rather than Options.

There’s nothing magical here: all I did was change every occurrence of “get_option” and “update_option” to “get_site_option” and “update_site_option.” Then, I just modified the menu statement to look like the following:
// Register the settings page
function AddAdminMenu() {
add_submenu_page('wpmu-admin.php', __('WordPress Admin Bar', 'wordpress-admin-bar'), __('Admin Bar', 'wordpress-admin-bar'), 'read', 'wordpress-admin-bar', array(&$this, 'SettingsPage') );

Download the file here and replace the one currently sitting in /wp-includes/wordpress-admin-bar/

Meanwhile, I’m going to work on tweaking the plugin to make it more flexible for MU as I go.

I’ve been struggling to understand exactly how the cron functions of WordPress work.

I’ve been working on a plugin for some friends of mine that need a mailing list manager, this plugin in turn requires the ability to schedule tasks. So, I spent a long time puzzling over the various bits of documentation and posts on other blogs about WP-Cron, pouring over code and experimenting with my own, until I finally got a working plugin.

And while I’m sure that the information that is out there now about Cron functions is adequate for some, it’s clear to me that others may need a different set of explanations, which is where this blog post comes in. I’m going to attempt to lay out the WP-Cron world in a different way in hopes of improving slightly on what’s out there.

Let me start by saying that the best article I’ve read on the subject of crons is definitely “Timing is everything: scheduling in WordPress,” by Glenn Slaven. I highly recommend that, even before reading this article, you take a gander at that one. There are really just a few things on which I would like to expand and revise slightly, because they threw me off. I’m also slightly reorganizing the order of discussion into something more akin to a step-by-step set of instructions.

Editor Update: Ack! Looks like this other article is no longer available. Sorry, everybody!

The Scenario

The example we’re going to work with is the mailing list manager plugin I’m developing. We’re not going to get into too much of the actual code of that plugin, but the scenario is doubtless a common need. We’ll be assuming that we’re working with a blog which has many, many users. (real world example: 400+) We want to keep our users up to date with periodic email blasts. Rather than those blasts being separated from the regular content, we want to specify that certain posts will become both posts on the site and email messages.

But of course, sending emails out to 400+ recipients at once is going to make the SMTP server very, very suspicious. In order to avoid problems with the mail server, we need to throttle the messages by sending blasts every twenty minutes ((or at least, approximately twenty minutes, remember that WordPress cannot be exact about timing)) until the last user group has been emailed. To do this, we will be using the wp_schedule_single_event() function within the WP-Cron suite of tools.

Scheduling: What You’ll Need

In order to schedule an event of any kind, you’re going to need a few basic components. We’ll get into more detail further down the line, but it’s important to be able to identify the landmarks as we proceed:

  • Your Cron Function ~ This is the actual function that does the stuff you want when the scheduled event is fired
  • A Custom Action Hook ~ Here’s where we get into the nitty-gritty of how WordPress operates. It’s very simple, actually, but understanding how to create custom action hooks is key to understanding WordPress cron functions. And a great deal more about WordPress!!
  • Your Scheduling Function ~ This is the function that initially assigns the scheduled task.

Your Cron Function

[php]my_scheduled_function([$arg1, [$arg2, [$arg3. . . ]]])[/php]

This function lies at the heart of your scheduling world! It is here that you put all the stuff you want to get done at a specified time. In our example, this is where you actually send the email to your latest batch of users. Note that this function can include an arbitrary number of arguments. We’ll get into how you pass those arguments on to the function later. For now, just notice that this is a standard function like pretty much any other. In fact, in the case of the mailing list manager I created, it’s as simple a function as you could ask for:

[php]function bhd_cron_send($sender_email, $subject, $mail_text, $send_headers) {
wp_mail($sender_email, $subject, $mail_text, $send_headers);

It’s probably advisable to create your function and make sure it works without adding in the cron functionality first. This is because a) there’s no need adding extra complexity to the system until you’re sure the function works and b) you’ll need to know how many arguments will need to be passed to the function and in what order.

Your Custom Action Hook

This is what really threw me. I’ve never created my own custom action hooks and never really understood them, but you’ll need to in order to get things done with cron, so this is important. Creating a custom hook is as simple as typing the following:

[php]add_action(‘my_custom_hook’, ‘some_function’ [, $priority, [$num_args]]);[/php]

WordPress assumes that anything added as the first argument exists without any additional registration of that new hook. In other words, ‘my_custom_hook’ actually is the declaration of the action hook in this example. The second argument should be a valid function name and will be the function associated with ‘my_custom_hook’ whenever ‘my_custom_hook’ is invoked anywhere in the system.

Obviously, since you’re writing your custom action, you’ll also need to invoke that custom action somewhere. That’s the last piece of the puzzle, which is explained down the page a bit.

But before we leave this topic, it’s worth pointing out that, just like any other action, it’s entirely possible to hook more than one function into the custom action you’ve created. It’s also possible to invoke the hook somewhere else in your code, separate from your Cron function. This bit of WordPress theory may prove helpful to you down the line, so it’s just an FYI.

The last two arguments of the add_action function are important. Recall the number of arguments you needed for your scheduling function. That’s the number you’re going to want to put in the $num_args add_action parameter. Otherwise, add_action doesn’t look for and doesn’t accept any arguments provided, which will doubtless render your function either inoperable or ineffective.

Late Update: Per jeremyclark in the comments, this is not really the reason to mess with priority! Thanks Jeremy! If you’re function is particularly computationally expensive (if it’s complex and relies on a lot of processing), it might be worth it to back the priority down a bit. You can do this by setting the $priority argument. The default is 10. In our case, the actual function is trivial, so this is what the add_action looks like for our mailing list:

[php]add_action( ‘bhd_cron_send_hook’, ‘bhd_cron_send’, 10, 4 );[/php]

Your Scheduling Function

Finally, there is the function which will do the scheduling. Depending on the complexity of your plugin, this may not be very complex at all. But the one thing that is required of your function is that it bundle up all the arguments to your cron function into an associative array in the proper order. In our example, the parameters for our sending function are $sender_email, $subject, $mail_text, $send_headers. Thus, we create an array like so:

[php]$mail_bundle = array(
‘sender_email’ =&amp;gt; $sender_email,
‘subject’ =&amp;gt; $subject,
‘mail_text’ =&amp;gt; $mailtext,
‘send_headers’ =&amp;gt; $send_headers

Next, we need to assign the scheduled task. For this, we use our custom action hook. Now we understand why it was so important to pay close attention to the number of parameters and their order: the hook only allows you to set the number of arguments and the function – which is now removed by one degree of separation from the schedule – needs those arguments sent to it in the proper order. We call the WordPress scheduling function like so:

[php]wp_schedule_single_event(time()+$time, ‘bhd_cron_send_hook’, $mail_bundle);[/php]

The first argument is simply the Unix system time plus an interval of seconds after which we would like the scheduled task to be fired. Since we want the first of our batch email events to happen twenty or so minutes after the post has been published, $time was defined as follows:

[php]$time = rand(1000, 1200);[/php]

“Wait,” you say, “why the random number?”

If you look at the multi-dimensional array of scheduled events created by the WP-Cron system, you will find that the primary key for identifying events is the Unix timestamp. The second-level identifier is an MD5 of the arguments. In our example, it’s possible that someone could inadvertently set up the cron events twice by correcting the post after they’ve published it: both events fire the ‘publish_post’ event, which the mailing list uses to start it’s process.

However it happens, the possibility is that two events could have exactly the same timestamp and arguments, which would mean that one overwrites the other in the array. To avoid this, I included the slight randomization, which only alters the schedule by a maximum of three minutes.

So, now let’s look at the entire process in code (with some pseudo-code) in order to understand how everything fits together:

// Description: Our scheduling function. Sends the email in 50-recipient chunks
function bhd_schedule_message($sender_email, $subject, $list, $headers, $mailtext) {
// Establish our random time interval between the publishing of the post and the first email blast:
$time = rand(1000, 1200);
for($x = 0; $x $sender_email,
‘subject’ =&amp;gt; $subject,
‘mail_text’ =&amp;gt; $mailtext,
‘send_headers’ =&amp;gt; $send_headers
// schedule the email blast, increment the $time variable by twenty minutes for the next loop:
wp_schedule_single_event(time()+$time, ‘bhd_cron_send_hook’, $mail_bundle);
$time = $time + 1200;

// Description: here is our actual cron job.
function bhd_cron_send($sender_email, $subject, $mail_text, $send_headers) {
wp_mail($sender_email, $subject, $mail_text, $send_headers);

// Description: Finally, here is our custom action.
add_action( ‘bhd_cron_send_hook’, ‘bhd_cron_send’, 10, 4 );[/php]

Note: we have not included the function that will be called when the post is published, because of course we’re not dealing with adding actions onto that particular hook. But for reference’s sake, such a function would look something like this:

[php]add_action(‘publish_post’, ‘my_mailinglist_function’);[/php]

This plugin no longer supported by the developer.

Download Here

The WPMU Site-Wide Latest plugin provides two widgets for your site. The first, labeled “Newest Post,” creates an 80-word teaser of the single most recently published blog post on any public blog across the entire site. The second, called “Recent Posts,” creates a list of the most recently updated blogs with their most recent posts, one post per blog. Both plugins provide a vehicle for those using the standard Gravatar plugin to obtain and display the Gravatar of the post author in each case.

The teaser widget takes the post title as the title of the widget, whereas the listing widget allows you to set your own title. Both allow you to ignore blogs, if you wish. The list widget also allows you to specify how many blogs you want to display and an offset. This is in case you use both together, that way the most recent comment is in the “Newest Post” widget and the next most recent begins the list in the “Recent Posts” widget.

The plugin also uses the WP-Cache, and both widgets allow you to set a time-out.

WP-Functions Used in This Plugin:



Unzip, upload (to either /mu-plugins or /plugins, your preference), activate and configure. Simple as that!

So, I’m getting very close to my October 1st release date for the DragonFlyEye.Net v5.0 launch, and I’m getting quite nervous.  I’ve gathered together most of the plugins I want to incorporate for the first launch, organized a lot of my plan of attack and begun lining up bloggers to join the network.  But there’s really nothing quite like pre-release jitters to get you going!

There are a few items I need to tack down between now and next weekend (when I’ll be doing the transitioning because my traffic is the lowest on the weekends).  For one, I’ve been working on a CSS substitution plugin that allows users to use the same theme (there is only one available, for consistency’s sake), but select from a list of custom color schemes and also import their own images for the header.  Most of this plan has gone fine, but I’m having difficulties with – of all things – adding the menu into the WordPress admin bar.  For some reason I don’t get, it’s harder than it sounds.  There are two panels added into the bar for this plugin, and one is working fine, but the other is a real pain.  It’s there, but when the data is submitted, it goes nowhere.

I’m also going to need to explore the wonderful world of bbPress and WPMU integration.  There are lots of individual posts on both the MU forums and the bbPress forums about getting this done, but they’re all quite incomplete.  <a href=”″>This post</a>, however, includes a guy’s whole Config.php file, so I’m hoping at least to get some clues from it.

Plus, I want to have a decent set of support docs available for bloggers, so I don’t have to constantly field the same questions or worse yet, administer accounts for people who aren’t getting the process.  I haven’t had a whole lot of time to work on that because of the plugin woes, but I’m trying.

Still another thread that I’m trying to weave into this “Coat of Many Platforms” is getting Google sitemaps to work with MU.  I wouldn’t have thought this a huge deal, but as it turns out, it’s at least as elusive as the bbPress/MU integration. The trouble is: because the directory of each blog is virtual (meaning, it doesn’t actually exist as a folder on the server), all the sitemaps need to be stored in the blogs.dir folder.  Since Google and others don’t accept sitemaps which do not reside in the root directory of their schemas, it requires a here-to-fore elusive mod_rewrite directive that will point visiting bots to the right file.  No one seems to have been able to tackle this quite correctly, and the one sitemap plugin on does weird things with redirected files that I positively do not get and don’t have time to analyze.

I’ve decided (literally, just as I’ve been typing this post) that a basic sitemap in the root, dynamically pointing out the locations of all the blogs on the network, will need to suffice.  Thus far, that has been all I’ve ever really used for my site, and I’ve still managed to dominate the stack rank for Rochester-centric keywords.

So, yeah.  I’m getting a little nervous, but it’s a good thing.  This is the kind of thing I live for: building, building, building and then putting it all on the line in one big launch!

For those of you concerned with getting bombarded with new blogs built by strangers you don’t want on your network, but would still like to leave the registration process open to others, I’ve created a simple set of hacks that will allow this to happen. A caveat, however: you’ll need to have some little app on the same server that does MD5 encryption, so you know what you’re going to use as session phrases.

I say “session phrases” as opposed to “passwords,” because I would like to disabuse anyone reading this of the notion that this is any kind of real “security” per se. Rather, this is a simple way to keep nusance registrations at bay while still allowing users to register as subscribers to blogs, and also send invitations to those you’d actually like to have a blog. The basic MU wp-signup.php form doesn’t really distinguish and rather allows anyone to get a blog on your network. Yikes! This is the kind of thing you’d at least want the option to override.

This article moved to the Plugins blog >>

When setting up your WordPress MU environment, it can be difficult to determine whether you want a plugin to go into the /mu-plugins or the /plugins folder. I’ve discussed the difference between the two locations in the past. At this point, I’m talking about deciding which to use based on the knowledge of how they work.

From my perspective, it makes no sense to include any more plugins than necessary across all blogs on your site. All you’re doing is front-loading the page load process and slowing the entire site down. Moreover, having to maintain code that not everyone uses makes no sense, especially if in doing so, you risk crashing your whole site with one bad upload. The best option for both efficiency and stability is to limit available plugins both as mandatory and optional plugins. Continue reading