Category Archives: WordPress

PSA: Don’t (necessarily) Trigger a Save from a Save in WordPress

I know what you’re thinking. John got caught in an endless loop, and now he’s sharing his stupidity with us.

Good guess. Normally you’d be right. This is not the case this time, though.

Say you need to process some data and it takes a while. Normally you’d render the data in a shortcode, but you don’t want to run all that churn on the front end while your readers are waiting. Makes sense to process the data and inject it on save so it’s just in the content, right?

Yeah, actually! That’s a great idea!

Maybe something like this?

NOOOOOOO. Don’t do that. I see you, thinking you’re clever, removing the function from its hook and re-adding it. Well your function might not be the only one hooked into a save. Now what do you think about that, huh? Not so smart, now, are we?

What you want is the wp_insert_post_data filter:

wp_insert_post_data runs before the database is updated and lets you modify post data before the update or insert happens. It has an optional 2nd argument containing the old post data as well, so you can check what’s been updated too, if necessary.

Upcoming changes to my WordPress fork

As you’re likely to know, I maintain a fork of WordPress that adds composer support. I won’t really go into any of the background or reasoning behind the origins of this fork, although that would probably be a good topic for a future blog post.

wp-composerI’m mainly just announcing some changes that are coming down the pipeline for the fork. If you follow me on twitter, you may have already seen much of this, so you probably have an idea of most of what I’m going to say.

I’m planning on re-forking WordPress into a new repository (probably named wordpress-core with the same change to the composer package) and turning johnpbloch/wordpress into a meta package that requires both the core package and the core installer package. This will allow me to keep the fork clean of any implementation details, including assumptions about how and where the user wishes to install WordPress itself.

So what does this mean for the composer package if you’re already using it? Nothing, hopefully. The only difference will be that the core files will get moved into a sub-package.

I want to explain my reasons for this change a little bit.

First of all, why am I fixing something that doesn’t appear to be broken? Well, because it’s too brittle, which is sometimes just as bad as broken. When I set this up, I threw together a bash script to keep it up to date. This script runs every 15 minutes on my server. It is fairly complex and difficult to extend or fix. I also want to rewrite it to be much more targeted in its work.

I would like to change the repository to be a real fork of the upstream mirror at git://core.git.wordpress.org/. This will allow me to simply use git’s built-in remotes functionality to fetch upstream changes without losing contributor information, etc. Some people have gotten the wrong idea in the past regarding my motivations for maintaining a fork of WordPress and even accused me of doing it primarily to improve my contributor graph on github 1. While it’s true that haters are going to hate, I’d rather distance myself from even appearing that way, even if I had a good reason for not doing a true fork the first time around. Now that I know my issues with doing a fork from the official source have been resolved, I’m happy to make that change.

Finally, I just don’t think it makes a whole lot of sense to tie my installer to the core package. Not everybody will need it for their installation profile and/or workflow, so it makes no sense to require it across the board.

Notes:

  1. This is, of course, not true. I don’t even pay attention to my contributions graph. The vast majority of my work is done in private repos for work. I’ve never considered those graphs to be a worthwhile metric for that reason. Without my WordPress fork my public contributions graph would most likely be in the low hundreds while my private graph would still be in the thousands.

Note To Self: Keep Transient Names Short

In case anybody has this problem: I was trying to set a transient for a certain plugin and using an API key in the transient. This seemed like a great idea, since the transient would automatically be invalidated if the user ever updated their API key. Super simple.

But the transient wouldn’t set. No matter what, I’d hit my breakpoints inside the ‘if not set’ code block.

Well, as it turns out, if you set an expiration time, WordPress will also set a secondary transient option: _transient_timeout_{$transient_key}. That’s a lot of extra characters padding the left side of that option name! 19, in fact.

So with only 64 characters allowed in the option_name column of wp_options to begin with, you need to limit your transient names to 45 characters or fewer. In my case, the api key I was working with was 36 characters, which left me just 9 characters with which to uniquely prefix my transient.

I had 17.

Oops.

TinyMCE Advanced as a Network Activated Plugin

If you’ve ever needed the TinyMCE Advanced plugin by Andrew Ozz, you know that the configuration process can be somewhat tedious.

If you’ve ever had to install it as a network activated plugin on a multisite installation (especially one with more than just a few sites), you probably thought about ditching the plugin altogether.

At work, I’m in the process of building a multisite installation that will consist of more than a dozen sites and they need this plugin. Being the lazy coder I am, I came up with this quick script to force TinyMCE Advanced to use site-wide options rather than options on a per-site basis.

Continue reading

WordCamp San Francisco 2011

Ok, so I know this is actually kind of late. Ok, so it’s really late, but I wanted to share some of my thoughts from attending WordCamp San Francisco back in August.

WordCamp San Francisco was a hugely inspirational event for me. First of all, actually getting to meet so much of the community in real life was unreal. Many of the people I met I’d interacted with on Twitter or elsewhere online. Most I’d never interacted with at all. I’d never been around so many people who share my passion for WordPress. It was positively infectious.

Continue reading