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.

There’s quite a few fixes and changes in this version. I’ll try and detail the most significant changes here in this post.

Cleaning up

0.6.1 switched from using “yes” for checked single checkboxes (and an empty value for unchecked) to storing either “1″ or “0″. This is because the string “0″ evaluates to false, but “no” evaluates to true! However, the switch may have caused some issues if anyone has code like this:

if ( slt_cf_field_value( 'checkbox-field' ) == 'yes' )
      [do some stuff]

I did! There’s not much I can do automatically to fix this, so I’ve included an alert at the top of admin screens that directs people to a new page for tools for this plugin under Tools > Custom Fields data. There’s a cleanup tool here that:

1. Converts any old “yes” / empty checkbox values to “1″ and “0″
2. Deletes any empty values for fields defined through the plugin (0.7 now only creates meta table entries for fields with a value to store)
3. Deletes any meta table entries for fields that have the prefix used by the plugin, but which are no longer defined

Needless to say, I’ve included plenty of warning to back up data before doing this. But once the tool has been run, enough attention should have been drawn to the potential issue with checkbox code (above), and the alert disappears.

The Google map geocoder and jQuery autocomplete

There had been an issue in that the handy address-finding geocoder field that is include with gmap fields used jQuery UI’s autocomplete. Turns out that this had been dropped from the version of jQuery UI in the WP core since 3.0—only I didn’t notice because I habitually use the Use Google Libraries plugin, and Google’s jQuery UI does include autocomplete.

WP 3.0 switched to suggest, and converting to this didn’t look like a simple case of switching functions. In the end, it turns out that WP 3.3 will ship with “jQuery 1.6.4 and jQuery UI 1.8.16. [...] the full UI including widgets and effects.” So autocomplete will soon be there for everyone again. Until then, Developer’s Custom Fields includes the geocoder field via JS, on the condition that autocomplete is present.

Scope defaults to all

The scope parameter now, instead of being required, defaults to an empty array, which will apply the field to all items within the box’s scope.

Globally disable functionality

Some people have requested the ability to globally disable features like the gmap and file field types, which come with a load of JS and other stuff. Now you can do with using constants in wp-config.php, e.g.:

define( 'SLT_CF_USE_GMAPS', false );
define( 'SLT_CF_USE_FILE_SELECT', false );

Both values default to true.

Documentation and issue tracking

I was going to shift most stuff for this plugin to GitHub with this version, but that’ll have to wait until I get more time to work out git for myself. For now, full documentation is now here on this site.

If you find a bug in the plugin, please raise an issue via GitHub. And if you’re not sure your problem is a genuine issue with the plugin or not, just start a WP forum thread.

Other highlights

Other important changes include:

• Added terms as an options_type for populating multiple value fields with taxonomy terms
• Added a notice field type for text-only notices to the user
• Added an above-content settings for the box context parameter, to place boxes on post edit screens above the content editor
• Added except_posts and except_users options to the scope field parameter, to exclude certain posts or users that would otherwise be included
• Added $file_attach_to_post parameter for file field types, so you can choose whether a file uploaded on a post edit screen is attached to that post or not
• Minified JS and CSS (full versions loaded when SCRIPT_DEBUG is true)

You can see the full list of changes in the changelog.

parse_url

parse_url is a PHP function that takes a full URL and returns an array populated with all the components, e.g. the host, the path, the query string, etc. For dealing with the query string you might also want to look at parse_string.

There’s also http_build_query, which I think the following two WP functions make use of.

add_query_arg

add_query_arg is incredibly useful if you want to add something to a URL’s query string without affecting the query parameters already in place. It defaults to the current URL, and you can either just add a key / value pair, or give it an array of key / value pairs to add.

remove_query_arg

remove_query_arg is simply the reverse of add_query_arg.

All together, manipulating URLs becomes a much simpler process with these handy functions!

If you check the Codex on Roles and Capabilities, you’ll see that there’s certain capabilities that are, by default, only assigned to admins.

Now, roles can be customized (most easily and reliably, I find, with Justin Tadlock’s Members plugin). That’s why it’s advised that, when checking whether a user can do something or not, you check what capabilities they have, not what role they’re in (usually using current_user_can).

So, as detailed by Mark Jaquith, if you want to check whether someone is an admin, you check against a capability that is by and large assigned only to admins—e.g. manage_options. True, someone might have customized their roles so, for instance, authors have the manage_options capability. But that’s stupid, and it’s their problem. As a plugin author, if you limit admin-only stuff to users with manage_options, you’ve done your job pretty well.

Checking for manage_options is obviously most suited to checks for editing options or settings. For other admin-only bits that are a bit more technical, I often use update_core. I often create a “Super Editor” role, which is pretty much like the default Editor role, but with manage_options (so clients can adjust site and plugin settings, but not upgrade or do other more technical things).

Now, as I mentioned, I’m discovering a number of plugins that use edit_plugins as a check for the plugin settings page. The thing that brought this to my attention as a problem is that I like to include this line in my wp-config.php file:

define( 'DISALLOW_FILE_EDIT', true );

You can see in the core that if this is set, it steps in on capability checks and blocks everyone from editing plugins, themes, or other files. I never use this feature of WordPress—it can be very risky on production servers, and is largely pointless on dev servers. And I certainly don’t want my clients using it. So I block it.

Unfortunately, as you’ll have guessed, this also blocks eveyone from editing the aforementioned plugins’ settings. Not good!

Initially I thought these plugin authors were using edit_plugins as a generic “admin-only” check, in the way that I use update_core. I slowly realized that they might be using it under the impression that they’re being appropriate, i.e. that edit_plugins refers to editing anything to do with plugins, e.g. settings. However, as the core and the Codex testify, that’s not true. This capability refers to editing plugin files.

Unless you’ve got a good reason to do otherwise, the capability you should use to check if the user should access your plugin settings (usually passed to add_options_page) is manage_options.

By all means choose something else if it’s related to the functionality you’re protecting. If your plugin include some kind of exporting functionality, check against the export capability. But if you do need a more generic “admin-only” capability to check against, use something unlikely to be disabled, such as update_core. The very handy DISALLOW_FILE_EDIT constant means that edit_files, edit_themes and edit_plugins are all a bad choice for checking if you’re dealing with an admin.

And come along to the next meeting!

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;
}

But it doesn’t seem to handle custom post type URLs. So I wrote a little workaround…

function slt_url_to_postid( $url ) {
	// Try the core function
	$post_id = url_to_postid( $url );
	if ( $post_id == 0 ) {
		// Try custom post types
		$cpts = get_post_types( array(
			'public'   => true,
			'_builtin' => false
		), 'objects', 'and' );
		// Get path from URL
		$url_parts = explode( '/', trim( $url, '/' ) );
		$url_parts = array_splice( $url_parts, 3 );
		$path = implode( '/', $url_parts );
		// Test against each CPT's rewrite slug
		foreach ( $cpts as $cpt_name => $cpt ) {
			$cpt_slug = $cpt->rewrite['slug'];
			if ( strlen( $path ) > strlen( $cpt_slug ) && substr( $path, 0, strlen( $cpt_slug ) ) == $cpt_slug ) {
				$slug = substr( $path, strlen( $cpt_slug ) );
				$query = new WP_Query( array(
					'post_type'			=> $cpt_name,
					'name'				=> $slug,
					'posts_per_page'	=> 1
				));
				if ( is_object( $query->post ) )
					$post_id = $query->post->ID;
			}
		}
	}
	return $post_id;
}

I’ve had to alter it a little from the code I’m using. My code works, but if I’ve goofed in getting it ready for public consumption, please let me know!

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?

Here’s how:

add_filter( 'get_user_option_managenav-menuscolumnshidden', 'slt_nav_menus_columns_hidden' );
function slt_nav_menus_columns_hidden( $result ) {
	if ( in_array( 'description', $result ) )
		unset( $result[ array_search( 'description', $result ) ] );
	return $result;
}

These Screen Options are stored in user preferences, so you need to filter a specific user option. Look here to see where this filter is being applied in the core. You’ll see the option that’s passed here. The $screen->id is basically the admin file being viewed, with .php stripped off. These pointers should get you going working out how this all works to adapt the above code.

The callback hooked onto the filter just checks to see if description is in the list of hidden fields, and takes it out if it is.

Hey presto, the description field is always on!

I did my first WordCamp talk, ‘Beyond the 5-minute Install’, which was aimed at beginners who wanted to know the non-standard but nigh essential things to do when installing WordPress to make things secure and hunky dory. There were also tips to make things easier for developers. It went down pretty well—thanks to everyone who bothered to say hi and give me feedback! I’ve posted the slides here on SlideShare. There’s not much text there, and I don’t think the talk was recorded. I might get round to writing an accompanying tutorial, but don’t hold your breath! Hopefully it’ll be of some use for people who weren’t there, as well as a good reminder for those who were. To grab the code snippets, copy from the SlideShare transcription, but beware of the syntax and any funny characters—grab the code from there, but check against the slides. Let me know if you’ve any problems with the code.

There were a bunch of great talks, though the really good stuff was in the panel discussions, the “site doctor” session, and down the pub. Rather than do a run-through of the actual talks, I’m just going to rattle through the highlights of what I learned:

• Responsive web design. I really need to get my shit together and learn this stuff properly! I suspect how soon this happens will be dictated by how soon I work on a project that has a significant mobile audience. Let’s see.
• SEO is dead. Well, of course it’s not dead. We still need to do the basics. But those basics, which have served people who know them so well so far, are pretty much common knowledge now. The edge is in generating organic conversations about your stuff. My guess is this makes it harder for this stuff to be “forced”—but those giving it a go will be more and more insidious.
• LinkedIn. Apparently this is a hot place for business networking. I’ve always just had a profile there because I may as well. If I was looking for business contacts, given what people in the know were saying, I would definitely be working my profile more.
• schema.org is big news. Google, Microsoft and Yahoo! have put differences aside for this specification for structured data for search engines. Bearing in mind some caveats, this is really interesting.
• WordPress menus have a description field! Who knew? Robert O’Rourke did. All you have to do is fold out the Screen Options when you’re on the menus page, and switch on the description. Great!

I guess the large amount of non-WordPress-specific stuff in the above list reflects my growing knowledge of all things WordPress. But I also think it’s to do with WordPress’s growing maturity. There’s always things to discover about it; but the platform is settling down a bit, with much core “full CMS” functionality now in place, and people are thinking more about what they are doing with the platform, rather than the platform itself.

But hey, there’s always space at a WordCamp to find out about some juicy plugins you’ve not heard of before! Here’s my discoveries:

• Jigoshop: “A WordPress eCommerce plugin that works.” Not tried it, but it looks interesting.
• EG Attachments: I’ve got a bit of code that does this—lists files attached to a post. But this looks good, I might use it.
• Front End Editor: Wow. Crikey. This is interesting. It’s a front end editor. Lets you edit, WYSIWYG style, on the front end. I’d be wary of something like this, but it’s written by some guys who know their WordPress stuff. One to watch.
• Very Simple Post Images: Only on github for now, this was being developed at WordCamp, and is a very promising improvement to the WordPress images / gallery management interface.
• WP Document Revisions: Also still in development, also very promising.

Many thanks to all the organisers for pulling of another brilliant weekend, and thanks to Richard Boakes for getting it all sorted in Portsmouth. See you next year!

Coming up, there’s more WordPress London Meetups a one day WordPress & business event in Brighton on 23rd September. Hopefully see you there, too.

The code has been part of my custom themes for a while, and I realized it should be a plugin as I’ve been preparing my talk for this weekend’s WordCamp (eek!). Anyway, the basic idea is that it enforces the password strength indicated by the little meter on the WordPress user edit screen. It only forces strong passwords for users who can do stuff, i.e. change the live site in some way.

There’s all sorts of scope for options, etc., but this has been serving me well for a while. All in good time. For now, it’s an easy way to combat one of the largest vulnerabilities in client sites: people who use weak passwords.