Here’s my situation. I have a bunch of sites versioned with Git via Beanstalk. I commit to the repository my custom theme, all the plugins (I occasionally hack plugins), and a few files in the root (e.g. robots.txt and .htaccess). I don’t version the WP core files.

There are other developers working on these sites, too. We all have development copies running locally (the master branch), and there are branches for the staging and production servers. I created this plugin because I wanted to make sure no one upgraded plugins on the staging and production servers, making them out of synch with the dev master branch. Plugins should be upgraded locally (and tested), then pushed to staging for testing, and thence to production.

So, this plugin detects whether or not we’re in a development environment by searching for a particular configurable string in the HTTP_HOST (default: “localhost”). If this string isn’t present, the stuff that does the disabling kicks in. By default it disables plugin/theme upgrades and file editing, but you can also set things to disable core upgrades, or enable plugin/theme changes. There’s also a configurable option to show notices explaining why plugins etc. can’t be upgraded. Check the readme for details.

I’ll wait a while to put the plugin on the wordpress.org repository. Meanwhile, feedback very welcome! Post general comments here; if you find a genuine issue, use the GitHub issue tracking.

• Developer’s Custom Fields
• Lock Pages
• Simple Events
• Force Strong Passwords

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.

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!

UPDATE 6/2/12: Some people have reported issues with this code that I haven’t had time to investigate. If it’s not working for you, I’ve been told this function does this trick as well.

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!