I’ve just created a small WordPress plugin, Control Live Changes. It’s currently only on GitHub. It helps manage the disabling of core and plugin/theme changes when you’re working with a Version Control System.

Archive for the category ‘WordPress’
My plugins on GitHub
I’ve just put all my WordPress plugins onto GitHub:
That’s all the ones that I’ve released via the wordpress.org plugins repository. On GitHub you’ll also find SLT Global, which is basically my collection of snippets that I want running on every WordPress project I deploy.
Custom Fields plugin update for WP 3.3
I’ve just released version 0.7.1 of Developer’s Custom Fields. It should be showing up on the repository and in your WP admin very soon.
It fixes a couple of bugs, one to do with the version number storage, and a more important one for anyone using Gmaps. Because of the attempt to exclude the Gmaps functionality when it’s been turned off with SLT_CF_USE_GMAPS, the [slt-cf-gmap] shortcode wasn’t working. This should be fixed now.
Also, I’ve made the WYSIWYG field type play well with the nice new WP 3.3 wp_editor function. When you upgrade to 3.3 you’ll also be able to pass values to the $settings parameter of this function with the wysiwyg_settings field parameter. Follow the source to the editor method of the WP_Editor class for details of what settings you can pass through. Thanks to katoen on the wordpress.org forums for the heads up!
There are some other things I’m hoping to address very soon. I just had to release this asap because of the Gmaps shortcode fix and the compatibility with 3.3.
Developer’s Custom Fields 0.7 released
I’ve just released 0.7 of my Developer’s Custom Fields plugin, which is now available for download from wordpress.org or automatically via your WordPress plugins page.
There’s quite a few fixes and changes in this version. I’ll try and detail the most significant changes here in this post.
Manipulating URLs in PHP and WordPress
A quickie post about a few functions that I’ve only recently discovered, and really wish I’d discovered sooner! One is a PHP function, two are WordPress core functions. Both help immensely when you’re dealing with URLs.
The WordPress edit_plugins capability
I’ve been finding more and more WordPress plugins that, when they check if the current user should be allowed to view / edit the plugin’s settings page, check whether the user has the edit_plugins capability. I think this is a bad practice; let me explain why.
WordPress core 101
Last night’s London WordPress meetup was good. Hosted by a company called Headshift, we got a quick-fire run through beginner, intermediate and advanced-level topics. Emily Weber gave an overview of how, as a non-techie, she got the social networking site yeah! Hackney going using BuddyPress. Keith Devon heroically compressed WordPress theme development into 20 minutes. And Chris Adams gave an equally succinct tour of the WP core. This is an important topic for budding WP developers, I think. Do check out Chris’ slideshow for some good pointers about where to look to start to understand the important aspects of the process that the core goes through when processing a request:
And come along to the next meeting!
Add wmode parameter to WordPress oEmbeds
OK, so we know how to solve the Flash and z-index problem, right? But how to make WordPress add the solution—the wmode parameter—to its auto-embedded videos?
This should help:
add_filter( 'oembed_result', 'slt_wmode_opaque', 10, 3 );
function slt_wmode_opaque( $html, $url, $args ) {
if ( strpos( $html, '<param name="movie"' ) !== false )
$html = preg_replace( '|</param>|', '</param><param name="wmode" value="opaque"></param>', $html, 1 );
if ( strpos( $html, '<embed' ) !== false )
$html = str_replace( '<embed', '<embed wmode="opaque"', $html );
return $html;
}
Get post ID from custom post type URLs as well
url_to_postid is a great core WordPress function. Give it a URL (from your own site!) and it’ll return the ID of the post or page it refers to. I’m using it so clients can paste a URL into a custom field (easy for them), then I can get other stuff related to the content using the ID (easy for me).
But it doesn’t seem to handle custom post type URLs. So I wrote a little workaround…
Force display of description field in WordPress menus
A very small but very good discovery I made at this year’s WordCamp Portsmouth was thanks to Robert O’Rourke. I never knew that if you folded down the Screen Options at the top of the Appearance > Menus admin screen in WordPress, you get a few extra fields for menu items. They’re hidden by default.
The big one for me is “Description”. I’ve often used a menu for managing the items (i.e. posts and pages) that are featured in a carousel on the home page of a site. I wrote my own code to populate the menu query with information from the posts the menu items refer to—specifically, a description or extract to use as teaser text. Well, this little discovery that I can allow clients to set (or override) the teaser text right there while they’re managing the carousel “menu” is small; but I think little things like this really help clients when they’re busy managing their site.
But if you have to explain to them to open Screen Options and check a box to do something that might be important, it’s two steps forward and one step back. A bit better, but not ideal.
What if you could force “Description” to be checked?
Welcome! I build websites - mostly based on the brilliant, free & open 
