A Mission Statement

One of the things that I constantly struggle with is the difference between all the different things that this site could, or perhaps should, be and what really drove me to make it in the first place. So this is a small public statement (for myself first and anyone else second) about what this site is and isn’t which will hopefully help me better understand and focus on it’s reasons for existing and what my goals are for it.

If there’s a single reason I maintain a website devoted to working with WordPress, it’s this: WordPress is the best tool that currently exists for internet publishing, and my primary goal today is to be an internet author (and by extension publisher). My goal, with all things I create is to make better WordPress tools that help internet publishers to makes better looking, more approachable internet content. Even if no one but me ever finds value in the things I create and share here, the tools and learning I put here will have helped me to become a better internet publisher.

It’s not about making money. It’s not about making the kind of things that get me copious internet traffic. It’s not about getting people to hire me to do things with WordPress for them. It’s about making better, more approachable, and thus more read, internet sites using WordPress. That’s it.

The Right Way to Style WordPress Plugins

From the time I first touched WordPress until a few days ago, I styled plugins wrong. Heck, I put my PHP in the wrong place too, so obviously there’s a lot I was doing poorly. None the less, in the hopes of saving someone some headache, here’s what I believe to be the best way to deal with CSS for any type of plugin today.

Quickly though, here is the basic progression of how I’ve tried to add CSS to plugin output in the past.

  1. Doing it purely inline with <style=" ... ">. (This does have a very small place on the internet — when you truly want to apply a unique style to a single element — but I wasn’t using that.)
  2. Adding bare CSS with an action hook to wp_head. I was just spitting it all in the head of theme making the files bigger, and the source more convoluted.
  3. Appending my own .css file with a script I found somewhere and didn’t really understand.
  4. What I’m about to show you: Appending my own .css file, but allowing the theme to replace it by putting sensibly named alternative in it’s style directory.

Essentially, for that Post Meta Box plugin I mentioned in the aforelinked post, I wanted to be able to modify the basic styling but not affect all the places I’m trying to use it. So, I did what made the most sense to me, copied the master CSS file (postmetabox.css) to my active themes directory and modified it there. And because this script I’m about to give you is so smart, that became the active styling without any problems. So here it is:

(A quick note: I’ve kept all references to “pmb”, my shortcut for making things local to my Post Meta Box plugin. If you’re using this function, I’d do a find and replace with whatever shorthand you use to refer to your plugin. I could have find-and-replaced it to “my-plugin,” but we’re smart people, so I’ll spare us that unnecessary step.)

add_action('wp_print_styles', 'add_pmb_stylesheet');

function add_pmb_stylesheet() {
	$theme_style_url = get_stylesheet_directory_uri() . '/postmetabox.css';
	$theme_style_file = get_stylesheet_directory() . '/postmetabox.css';
	$pmb_style_url = plugins_url() . '/post-meta-box/postmetabox.css';

	if ( file_exists($theme_style_file) ) {
		wp_register_style('themepmb', $theme_style_url);
		wp_enqueue_style( 'themepmb');
	}
	else {
		wp_register_style('pmb', $pmb_style_url);
		wp_enqueue_style( 'pmb');
	}
}

First and foremost, that add_action call is (half of) the proper way to append any stylesheet in WordPress. There are many other things you can do that will function for you (the aforementioned wp_head method is probably the worst of them). Essentially, all it’s doing is calling my function when it gets to any place it typically reaches for style sheets.

So what our function does is hand it the right style sheet. And which stylesheet is right depends on whether or not the user has created one for their current theme, or if they just want to rely on ours. So essentially, we’re just looking to see if the user has created the file to hold their own stylesheet ($theme_style_file), if they have, we use that. If they haven’t, we use our own.

There’s nothing in here that a seasoned PHP and WordPress person should be stunned by, but there’s a lot of little bits that your average tinkerer will not have known about. Like that PHP can easily check if a file exists — that function’s in every version of PHP ever — but does it with local addresses, so you need to know where the style sheet is both locally and internet-wise. And the commands wp_regiester_style and  wp_enqueue_style — which round out the proper way to add a style sheet — were completely unknown to me until I ran across a little tutorial (by I think Justin Tadlock, though after 20 minutes of looking I gave up on definitively finding who it was).

I wondered for some time about the possibility of keeping some sensible defaults for my plugin’s visual output and always using them, but if for some reason the user wants to overwrite what seem to me to be sensible defaults I want to make that easy. And since I think most anyone inspired to modify my styling would take the sensible advice to copy the original file and put it in their theme and modify it there, that’s what we’re allowing for.

It’s entirely possible that another years of dinking around with WordPress will convince me that this method is as foolish, or outdated, or bad, as my previous methods, but the more I think about that the less likely it seems to me.

Don’t Put it in the Theme

If there’s one lesson I can think of that I wish I’d learned sooner in the whole WordPress plugin and theme area it’s this: unless you can make a convincing argument that it belongs in the theme, it doesn’t.

Over the weekend, I finally did some work I’d been meaning to for a while. I moved the “post meta data” — tags, similar posts, last and previous post links, etc — which I used to have in the sidebar of Frozen Toothpaste back to the bottom of the posts. (Every post on the site will show it, but this is a shorter one.) It seems obvious to me (now; there’s a then when it wasn’t) that this is the right place for it to be, there for when someone has finished with one post and can easily get a good “next action” right there, rather than scrolling back to the top and then looking to the sidebar.

All of that’s tangential to the point that when I started to build this new “post meta box” I went to start writing the code for it into my current theme. But I’ve meant to change my theme for nearly a year, and it occurred to me that it would really suck to have to move all this code over next time I change the theme.

So I went with the obvious solution to this problem, and the best answer to the generic question of “Well, then where should I put code that does stuff in my theme?” I made a plugin.

Some of this is simply personal preference and coding style. There’s probably a reasonable argument that could be made for keeping at least some of the code that makes those post meta boxes appear local to the theme. I’m convinced it’s possible that you could convince someone of that argument. But I doubt you could have convinced me that’s what I should do for me. And that’s really all that matters. If you can’t convince yourself it belongs in the theme, it doesn’t. If you’re able to convince yourself, do whatever you like.

To most people who spend a significant amount of time futzing with WordPress plugins and themes, this is probably self-evident. But I struggle to recall a time when I didn’t make at least a few poor decisions because I’d never heard the pretty damn good advice: if it doesn’t obviously belong in your WordPress theme, don’t put it in your WordPress theme.

WordPress, Money, and Freedom

I see a creeping scourge overtaking the free ethos of the WordPress community, and I don’t like it. It’s not necessarily menacing, or threatening, or even really a scourge (as I know I just called it) but it’s a thing I don’t like and it took a plugin I’ve used for years being discontinued for me to more clearly see the problem.

WordPress as a whole — the community more than the tool — is less-free now than it was a year ago, and less so still than it was five years ago. That’s the nature of what I see as the problem. But the reason I’m so tentative to call it a problem is that WordPress is also a far better tool now than it was a year ago, and certainly far more than it was five years ago. And like it or not, I think this fundamental creeping unfreedom has, at the least, contributed to the rate at which WordPress has become a better tool than it has ever been.

In my estimation, the first foot-fall of this unfree menace (again, I say that but don’t wholly mean it) were the “premium” themes. Someone, I think it was Brian Gardner, had the reasonable thought that rather than making money solely by purpose-building WordPress themes for clients paying $500 and north, they could fill a market-gap with a well-made theme priced around $100. For users who wanted more than a free theme could give them, but less than hiring a designer would, they got a product that pretty well sat that gap.

One could debate endlessly whether there are more or less good free themes being made today, but judgement about that is inherently subjective and thus not worth making. What is almost certainly true is that free themes are no longer the only non-exclusive themes that exist. And while I, as a rather poor person certainly preferred it when all themes I could hope to use were free-as-in-beer, it’s not an unmitigated catastrophe that they aren’t.

It is worrying how likely it is that because “premium” themes aren’t free-as-in-beer, they’re not building on each other. Being harder to get makes them less likely to be publicly modified and enhanced by others, and to be used to make other similar themes better. Again, we need to balance these facts with the fact that there are more better-quality themes generally, etc, but the effect is not negligible.

Now the other day, the WordPress.com Stats plugin declared to me it has been discontinued in preference to Jetpack, which Automattic portrays as the plugin to “blast-off” into the fun world of WordPress.com features. It’s also, almost certainly, going to give Automattic a convenient place to get self-hosted WordPress users to enter the world of paying for some features, as has always been the available on WordPress.com.

Again, this isn’t ransom or anything. It’s a completely sensible — even admirable — business move, but it’s not exactly fostering freedom and building better software for all users. How many features might not be built into the core of WordPress because Automattic has a money-making Jetpack feature that does the same thing? (Is the reason there is no backup functionality in the WordPress core that VaultPress exists?) Questions like this always contain some alarmism, but that doesn’t mean we should just ignore the potential for a conflict of interest.

These type of vague but indefensible concerns are precisely why I bristled at the thought of replacing what was a relatively lean and fast plugin with the colossus that is Jetpack. I have no concrete reason to think the WordPress core will suffer so Automattic can make more money, but that fact that a I’m seeing more and more avenues by which this could come to pass definitely gives me pause. And that, I guess, is all I’m really trying to say.

A WordPress Plugin to Pester Delinquent Posters

I’ve been keeping a posting schedule here for a few months, and I’ve been using it over there for over a year. And the whole time I’ve been doing so it felt a little constrictive. I’d have the next post all polished and ready to publish, but I was scared to break the schedule because where would I be without publishing dates to provide a sense of order?

It was while I was giving this idea some further consideration recently that I  recalled a plugin that was featured on WPCandy. When I first saw Blog Update Reminder I couldn’t really think of a reason I would use it. But giving some thought to trying to update my blogs more frequently it suddenly occurred to me that it would be pretty cool if I could just get some kind of alert that it had been a while since I’ve posted and maybe I should.

And this is exactly what Blog Update Reminder does. If you haven’t published a post to a blog in a set interval of days, it sends you an email that says something to the extent of, “Hey, maybe you should update.” It does this everyday until you satiate it, which I’m not sure I love, but better to know too much than too little.

It’s also worth noting that, at least for now, scheduled posts count toward the good. That is: if I have a post scheduled for a week from now and I set my pester interval to two days, I won’t get bothered until two days after I have no more scheduled posts (nine days). So you could cheat the system by scheduling a post far away and never publishing. But it’s a tool meant for your benefit, not your pain, so I’m not sure that really gets scored as a problem.

Mostly I like the idea of the plugin as a way to keep me honest. The game can be built so that with scrupulous posting I’ll never see a reminder. Such that when I see the reminder I know that I’ve lost the game. It’s only when I’ve failed to maintain the frequency with which I intend to post that I’ll get reminders (or notifications of defeat).

Substance-wise, I only have two potential niggly points about the plugin. The first is the name. Anytime I see someone uses the word “update” with any proximity of the word WordPress, I think of the need to keep my blog software up-to-date for security and feature reasons, not publishing stuff on my blog. I’d have called this plugin something like “No Post Pesterer”. Yes it’s a trivial point, but I warned you these were niggly.

The other issue is that I can’t know what the email message will say short of editing the plugin or falling delinquent myself. Again niggly, but I’d love to be able to send a test email to myself, and easily set the email message to say:

Hey Loser,

You’ve been neglecting your responsibility to yourself and your readership by not updating [blogname] in [dayssince] days. Remember, you think you should post every [setinterval] and you’re letting yourself down by not keeping up that rate.

Obviously coding the ability to easily customize the message text is a nontrivial task, and probably not really worth it for the modest benefit it provides. The stock text is a little more formal than I am with myself, but that never did anyone any harm. And editing it in the plugin itself is hardly rocket science.

Overall, I’m excited by this plugin that I didn’t understand initially. I think it’ll be a great excuse for me to see if I can keep myself posting to my blogs with a reasonable frequency with just this single modest crutch. And if you think you could use such a crutch, this seems like a good one.