Tag: plugins

Posted On

I guess there’s sort of a tradition for WordPress developers where they start out by forking code they don’t really understand and then release it upon the world while not fully grokking how it works or how to maintain it.

There’s probably not much of a better way to learn how this stuff works in the first place. (If you know of one, certainly let me know.)

When transitioning this site to use HTTPS recently on the front-end, there was a problem with existing legacy content not conforming to the new URI scheme. In an effort to solve this problem, I did what any self-respecting novice coder would do: I asked everyone I knew who is smarter than me for help.

I was led by my colleagues on the WordPress.com VIP to a code snippet that was written at Code for the People to handle exactly such a problem. It filters content to ensure that the URI scheme matches the scheme that’s set in a given site’s options. It’s been running on this site for some time now and I’m happy to say that it appears to work quite beautifully.

Assuming that others would be able to use this as well, I’m releasing the plugin on GitHub and with a reference page here, encouraging issues and pull requests as you might feel moved to create them. I can’t promise that I’ll know what to do with those requests, but I’ll do what I can to keep it properly maintained.

I hope you do indeed find it useful.

Posted On

Yet another reason I like working with Automattic is that we regularly hold internal Hack Days, where anyone in the company who has an inkling can take a day and set it aside to work on a pet project, presenting what’s done at the end.

Last Hack Day, I made some basic changes to the Gravatar site, which was a fun challenge and taught me a lot about how our development environment functions. (Background: calling me a “developer” is a pretty big stretch; I’m still very basic in what I can do.)

The first part of any Hack Day is finding the problem you want to tackle, and I have something I’ve been wanting to solve for my personal blog for some time now. Generally, the only time I get for writing on my personal blog is at night, often quite late, when most of the people I know are not actively reading things. I also tend to write in big batches, where I’ll put up five or six posts in a relatively short timeframe.

What I would like to do is have a plugin that would:

  • Have a “deferred” post status that would place a post into a queue. First in, first out.
  • Deferred posts would be cron-published. The cron would publish only between certain hours of the day, and would maintain a certain amount of temporal spacing between posts, maybe with a small amount of randomness to make it look less robotic.
  • Authors should be able to publish immediately if they want to (hence having a separate status for the deferred posts).
  • It will work with Jetpack and specifically Publicize.

There are already a couple of existing plugins that try to scratch this itch, but neither of them has been updated in a while and on looking at them I don’t think they are exactly what I want.

I’m pretty certain I won’t be able to get this all done in one day just because I don’t have all the knowledge I think I need to do it. But I’m going to look at the existing work around the idea and see what I can do. I have a feeling this is something that would be useful to other people as well.

Posted On

Today’s been busy enough that I haven’t had the opportunity to put up some new work on it, but over the weekend, I was able to whip up the code to put together the custom post type I’d like to use for podcasts. (My original post on the project is here.)

My guides for this were the well-exampled Codex entry, Justin Tadlock’s posts on the matter, and Konstantin Kovshenin’s excellent posts as well. My code is structured after the example in the Codex with a little bit of experimentation:

# Let's get things started and fire up the custom post type for Podcasts.
add_action('init', 'simple_podcast_init');
function simple_podcast_init()
{
	$labels = array(
		'name' => _x('Podcasts', 'post type general name'),
		'singular_name' => _x('Podcast', 'post type singular name'),
		'add_new' => _x('Add New', 'podcast'),
		'add_new_item' => __('Add New Podcast'),
		'edit_item' => __('Edit Podcast'),
		'new_item' => __('New Podcast'),
		'view_item' => __('View Podcast'),
		'search_items' => __('Search Podcasts'),
		'not_found' => __('No podcasts found'),
		'not_found_in_trash' => __('No podcasts found in Trash'),
		'parent_item_colon' => ''
	);
	$args = array(
		'labels' => $labels,
		'public' => true,
		'publicly_queryable' => true,
		'show_ui' => true,
		'query_var' => true,
		'capability_type' => 'post',
		'taxonomies' => array('post_tag', 'category'),
		'hierarchical' => false,
		'menu_position' => 5,
		'supports' => array('title','editor','author','thumbnail','excerpt','comments','revisions')
	);
	register_post_type('podcast',$args);
}

This successfully registers the custom post type and its behaviors (though I’m not certain I like the taxonomies and may need to move to something else in the future), but there remains a problem: upon activating the plugin, any attempt to view a podcast results in a 404 from the permalink.

I’ve seen references elsewhere to flushing the rewrite rules, but it’s not clear to me where in the process this should go or how it’s supposed to be called. My understanding is that I don’t want to do that every time the plugin initializes, because that’s not being a good steward of server resources. (Of course, if I visit the panel at Settings > Permalinks, everything works just like it should.)

Unfortunately, I’ve not yet seen an example of code that would properly reset the rewrite rules when this is turned on. Here’s what I tried and failed with:

# Because we're adding a rewrite, we need to flush the rules on activation.
	function simple_podcast_flush_rules()
{
		global $wp_rewrite;
		$wp_rewrite->flush_rules();
}
register_activation_hook( __FILE__ , 'simple_podcast_flush_rules' );

Does anyone reading this have a suggestion for where I might be going wrong? I eventually had to step back from it and won’t get a chance to try again until later.

Playing more with custom post types has also revealed a small flaw in my designs: the podcasts won’t “mesh” with the regular posts on the blog. Their taxonomies (as far as I can tell) can’t be shared, and the podcasts won’t display in the main feed of the blog, either.

Then again, this may or may not be a concern, depending on how one would structure the site.

Posted On

I’ve been using WordPress for a very long time, and I’ve squeezed a lot out of it over those years. I’ve learned how to build entire sites using it, I’ve learned how to make it do little tricks, and I’ve learned how to work with themes to bend it slightly to my will. There’s one aspect of WordPress tinkering that I’ve avoided that whole time because it’s just been too intimidating, but I’ve decided that I need to push myself to learn some new stuff, and there’s no better way than to just dive in and see what I can do.

So it’s time for me to try writing a plugin. This is a frightening thing for me, but I have a plugin that I’d like to create. The plan is mostly-formed in my mind, and I know what I want to do; now I just need to figure out how to get those things to happen by writing it.

I’ve been working with podcasting and WordPress for a good while now. There are a lot of options for podcasting plugins for self-hosted WordPress. Unfortunately, I feel that most of them are trying to do too much and have too many options. They’ve become more difficult to use. Old ones have disappeared into development history, others have changed developer hands over time, and still others have claimed to be the biggest, baddest podcasting plugin on the block.

The goal here is simplicity. It doesn’t have to be a very complicated addition to a WordPress installation, and new tools are available with the upcoming release of WordPress 3.0 that can be leveraged to build something that’s even easier to use. I’ll be posting source as I work with it here. If you have feedback or can teach me a better way to do things, I welcome it, as I think I will need the help.

Let’s start with some goals for the plugin:

  1. It will use custom post types to separate podcasts from regular posts.
  2. It will allow podcast enclosures to be manually specified—only one per post, as iTunes ignores subsequent enclosures.
  3. It will provide an administrative panel for specifying iTunes feed metadata.
  4. It will alter and/or create RSS feeds and autodiscovery to make subscribing to it easy, either directly or through iTunes.
  5. It will look, feel, and act like it’s been part of WordPress all along—a consistent user experience.

That’s the basic set of needs for a podcasting plugin; leave a comment if you think I missed something.

I’ll admit that I may not have the skills I need to pull this off. It’s definitely going to mean a lot of reading, a lot of tinkering, and a lot of making mistakes and backing up to try again.