I’m too exhausted now for a detailed write-up, but I want to jot some things down while they’re fresh. Here’s the main things that stick in my mind…

Themes

There was a lot about themes. Much discussion of the debate about the Thesis premium theme’s apparent flaunting of the WP GPL license (check Mark Jaquith’s post for the best overview of this heated debate).

WP stalwarts Michael Kimb Jones and Jonny Allbut took us around the world of premium themes, free themes, theme frameworks… and on that last note, introduced the beta of their new WP theme framework, Wonderflux.

I’m still agnostic about theme frameworks. Myself, I have a basic “theme foundation”, which I keep improving and tweaking, and is my lightweight starting point for all my custom themes.

There’s been a great discussion on theme frameworks at digwp.com, and I was interested to see how many people concur with my approach (don’t we all like loads of people agreeing with us? ;-). That said, there were some good arguments for frameworks. Most framework advocates seemed to favour Justin Tadlock’s Hybrid, which is definitely something I’m looking at. Justin’s code and attitude are usually impeccable, and everyone says his premium support rocks.

Wonderflux seems like another possible contender to check out—Jonny Allbut likewise is a fully-fledged WP believer with a great attitude and a good head for code. If I start doing larger projects more regularly for clients who are keen on easily upgrading their theme to support the latest WP features, I’ll start building with one of these frameworks. There’s a bit of a learning curve involved, but really there’s only one way to find out if it’s worth it…

One thing for my own stripped-down theme foundation, though. Jonny stressed that even if you’re not using frameworks, you should definitely be using child themes (the mechanism at the root of most theme frameworks). I suspect he’s right. I’ll be looking into this soon.

Plugins

Michael Kimb Jones’ session on good plugins was very informative, although it was a shame there wasn’t time for the audience to chip their suggestions in. The best summary is a list of the ones I thought stood out:

• Import HTML Pages. A nifty way to quickly convert a flat HTML site to WordPress.
• WP Table Reloaded. Apparently imperfect (of course) but much-needed improvement on the hideous table editing with TinyMCE.
• Mingle. Seems like “BuddyPress Lite”—social networking features for a single-site installation of WP.
• White Label CMS. Allows some client-friendly mods to the WP admin area (logos, hiding unused menus, etc.).
• WP CMS Post Control. More control over the WP admin area, configuring what boxes appear for different users.
• Gravity Forms. You pay for it, but there was a lot of positive feeling for this powerful but very user-friendly forms plugin.

BackPress

I missed lead WP developer Peter Westwood’s session on BackPress, but it sounds like a great project. It’s seems to be a library of functionality for web applications, based on WP, but stripped-down. The beauty of this is that you can now build your own apps making use of your knowledge of mega-useful WP stuff like the wpdb class, user management, taxonomies, etc.

WordCamp UK?

Unfortunately things ended on a bit of a sour note during the final discussion.

Last year in Cardiff there was a discussion about whether there should be a more “corporate” element to the gathering, with paid training sessions and seminars. WordCamp regulars rightly objected strongly, while stressing that they had nothing against this kind of thing happening—just not under the “WordCamp” banner. There was talk of splitting off some sort of “WordCon”, but I’ve not heard anything more of this.

This year, the heated debate came when we started discussing WordCamp UK 2011. Jane Wells, who’s been doing some amazing user interface work on WordPress at Automattic over the past few years, chimed in to remind us that the ethos of WordCamps is about being local and decentralized, and that a WordCamp UK is going against this. There was the strong suggestion that they (the WordPress Foundation I guess, who own the WordCamp trademark) might crack down and stop such a national gathering using the WordCamp name. There was, to put it mildly, a lot of resistance, from the eminently reasonable to the rather annoyed (thankfully the arguments never actually got ugly, just pointless).

Now, I think everyone’s intentions here are good, and I think it should all work out in the end, despite that thing about the road to Hell. Jane genuinely wants to keep a local flavour to WordCamps, a philosophy which has a tremendous amount going for it. However, I think there’s an element here of the sociogeography of America being applied in a very different country with inappropriate rigour.

WordCamp USA would indeed be a humungous thing, which would tend towards becoming depersonalized, and alienate a lot of people purely through the vast distances involved. City-based WordCamps are the obvious, natural format. Jane mentioned—to stress that this wasn’t just being down on the UK—that they have similar situations in India, China and Australia. Again, I can’t see how these countries’ geographic dynamics can be applied on this little island.

WordCamp UK has so far been held in Birmingham, Cardiff and Manchester. It’s kind of nice it not being in London. I live in London, but this is the other factor that, together with the island’s small size, changes things a bit. London dominates, often too much. Touring a nice little conference around other parts of the country seems to be a great way of bringing a good WordPress vibe to these places. And it really doesn’t feel like it’s some “central” authority bestowing itself upon the poor provinces. It feels like a localized event, infused with other parts of the country in the way that is possible in this dense, small country, and which makes it what it is.

Anyway, I don’t want to press this. I think the worst-case scenario is that what is now WordCamp UK gets “rebranded”. Hopefully if it has to break with the WordCamp trademark, it won’t break with the “semi-organized BarCamp” ethos. I actually think this is next to impossible, as the core organizers are so committed to this. If we have to “fork” WordCamp to create a touring national WordPress event, it would be entirely wrong to see it as a break with the open and informal attitude of WordCamp—they don’t have a trademark on that. There’s no reason why we can’t mix this attitude with a healthy cross-pollination of people from many different places. There were quite a few Scandinavians there this weekend, because the WordPress community there hasn’t kicked off any meetups or WordCamps yet. There’s room for this kind of thing in the UK, in Europe, because it’s good and it’s possible.

Jane seemed set in the idea that having a WordCamp UK was placing this event as “bigger” and “better” than any city-based WordCamp that was set up in the UK. I think this was her major mistake. I don’t think a soul in the room had ever even thought like this. I can immediately see what’s “better” about a completely localized meetup (which, strangely, we don’t have in London). I can also see what’s “better” about a national event. When two things are both “better”, neither’s better—they’re just different. Wouldn’t stopping one of them reduce diversity? I think it would, so it’ll probably carry on, by whatever name necessary.

I totally appreciate that I might have much more experience than some people, and I’ll have a few little hints that could save a lot of time. But sometimes people emailing me seem to be doing something that I fully confess to being guilty of, in the past and even now: shouting out for help too soon instead of stepping back and tackling the problem properly.

So, here’s a little guide I can point people to, partly in lieu of an email reply template. If you’re facing a WordPress coding problem that either looks daunting right from the start, or is driving you insane after hours of trying, the following hints can help a lot.

1. Take a deep breath

   Literally. Take few calm, deep breaths. Maybe have a break, make some tea, do some washing up, something mundane with your hands. If time isn’t too pressing, sleep on it and have a go in the bright morning light. Very often tricky coding problems solve themselves in half-sleep states, or within seconds of sitting down in front of the issue with a fresh mind.

2. Try it out!

   I feel no compunction in being withering about this, because I’m putting myself down as much as anyone. But really—how many times do we fire off a question to a list or forum asking whether XYZ will work or not when there’s something very close to hand that will tell us immediately: giving it a go! Try stuff out in a test environment. Try, tweak, try again… It’s very simple ;-)

3. Search and ye shall probably find

   I can’t tell you how many replies I’ve sent to coding enquiries which basically consist of links to Google searches. I know this has an edge of facetious impatience about it, but most times it’s a plain answer. The solutions are sometimes right there, in the first page of results of a simple search.

   I’ll mention one specific thing here, which is that although I don’t have it bookmarked, Stack Overflow posts come up very frequently in tackling coding issues, and they’re often the best. One to watch for.

4. Essential WordPress resources

   • The Codex

     It’s far from perfect, but it’s often essential, especially the Template Tags and the Function Reference.

   • 3rd-party WP reference

     There’s some good “unofficial” WP documentation sites / reworkings, including the WP Hooks Database (docs on actions and filters), a WP API browser, WP Lookup (a good interface for search WP resources), the Roadmap (not being updated it seems, but a good way of seeing the order in which files and hooks are processed for any particular WP request), and tools to search the WP source.

5. WP support forums

   Someone may have solved the issue already. If not, someone might have a moment to help…

6. wp-hackers

   This is one of the key WP development community resources, for coding issues a little more advanced than you’ll find in the forums.

7. Ask for free advice from a WP developer

   Well, I’m writing this to try and suggest other routes, so obviously this should be a last resort ;-) That said, if you’re really stuck after trying all the above, you never know. The WP community does have many people like me who, because they appreciate making a living from other people’s work given for free, will occasionally devote a little time to helping a fellow developer out just for the hell of it…

Anyway, it’s a solution to a problem that I’m very surprised isn’t built into the WP core (as an option at least), and isn’t addressed by any easily found plugin or code already out there. As we know, WP provides a good “password strength meter” on the user profile page, which is great as strong passwords are (or should be) one of the first lines of defence against attacks on your site. But it’s just an indicator—there’s nothing stopping someone using “password” as their password, or something dumb like that. All you need is one Administrator or Editor with a dumb password, and the whole site is highly vulnerable.

How about a little enforcement?

The code below basically replicates the WP core password meter check, translated from JavaScript to PHP, and uses it to validate passwords that are entered.

// Enforce strong passwords
function slt_strongPasswords( $errors ) {
	$enforce = true;
	$args = func_get_args();
	$userID = $args[2]->ID;
	if ( $userID ) {
		// User ID specified - omit check for user levels below 5
		$userInfo = get_userdata( $userID );
		if ( $userInfo->user_level < 5 ) {
			$enforce = false;
		}
	} else {
		// No ID yet, adding new user - omit check for "weaker" roles
		if ( in_array( $_POST["role"], array( "subscriber", "author", "contributor" ) ) ) {
			$enforce = false;
		}
	}
	if ( $enforce && !$errors->get_error_data("pass") && $_POST["pass1"] && slt_passwordStrength( $_POST["pass1"], $_POST["user_login"] ) != 4 ) {
			$errors->add( 'pass', __( 'ERROR: Please make the password a strong one.' ) );
	}
	return $errors;
}
add_action( 'user_profile_update_errors', 'slt_strongPasswords', 0, 3 );

// Check for password strength
// Copied from JS function in WP core: /wp-admin/js/password-strength-meter.js
function slt_passwordStrength( $i, $f ) {
	$h = 1; $e = 2; $b = 3; $a = 4; $d = 0; $g = null; $c = null;
	if ( strlen( $i ) < 4 )
		return $h;
	if ( strtolower( $i ) == strtolower( $f ) )
		return $e;
	if ( preg_match( "/[0-9]/", $i ) )
		$d += 10;
	if ( preg_match( "/[a-z]/", $i ) )
		$d += 26;
	if ( preg_match( "/[A-Z]/", $i ) )
		$d += 26;
	if ( preg_match( "/[^a-zA-Z0-9]/", $i ) )
		$d += 31;
	$g = log( pow( $d, strlen( $i ) ) );
	$c = $g / log( 2 );
	if ( $c < 40 )
		return $e;
	if ( $c < 56 )
		return $b;
	return $a;
}

A few notes:

• Initially, in slt_strongPasswords(), which is hooked to the user_profile_update_errors action, we check whether we're editing or creating a user here. This enables a check on the user level / role. Here, I'm only enforcing the strong password for "executive" users, i.e. those whose role lets them significantly affect the site. I'm taking this to be Editors (or, in the old style, Level 5) and above. I'm well aware that roles and capabilities in WP, and possible modifications of that system, mean that this may not be a one-size-fits-all solution. Obviously, adapt as necessary for your system---and do chip in here with any suggestions for better / different checks. If you want to enforce strong passwords for all users, just delete or comment out lines 4-17.
• I've translated the WP core JavaScript function that runs the password strength meter here into PHP. If you root around in the core source (/wp-admin/js/user-profile.dev.js, you'll see that the value 4 is returned for "strong" passwords. Here, where there is enforcement, I'm limiting allowed passwords to "strong" only. Again, tweak this if you want to---perhaps different strengths enforced for different user roles.
• One slight hole I know is here is if someone changes a user's password at the same time as changing their role from something like Subscriber to Administrator. A weak password would get through this. Also, an account with a weak password could just be changed to an Administrator, and if no new password is entered, again, the check wouldn't be triggered. I'm assuming that people on the editing other's accounts will be trusted and know what they're doing. But still, it's an area where this code could definitely be improved---certainly it'd be necessary before making this a plugin.

Let me know if this is useful and if you find any bugs or suggestions for improvement!

Anyway, I’ve just cracked a minor issue I’m working on thanks to this post and this thread. I’m posting the solution here for my quick reference as much as anything…

Problem: how to check if a WordPress post_date (from a $post object) is from a day in the future? Solution:

$postDate = strtotime( $post->post_date );
$todaysDate = strtotime( date( 'Y-m-d' ) );
if ( $postDate > $todaysDate ) {
	[ post is from the future! ]
} else {
	[ post is from today or the past]
}

However, I just had some problems getting some jQuery to run on the login / registration form. I used wp_enqueue_script like a good WP developer but… no go. Where’s my jQuery?

It seems the answer lies in the fact that after scripts are enqueued in a normal WP page, they get spit out by something inside the call to wp_head(). I guess you could add wp_head() to the login header, but who wants all those redundant plugin scripts and styles that (presumably) aren’t even meant to be there.

After a bit of diggiing around it seems that the solution is the wp_print_scripts() function. So, to get jQuery working on the login form, put these lines in the code you hook onto login_head:

wp_enqueue_script( 'jquery' );
wp_print_scripts();

OK, it’s fine (often easier) to use the keyboard to navigate drop-downs. But not everyone knows how to, and even so, with a large amount of pages, selecting the right parent can become a pain.

I think I adapted the following code from a plugin or someone else’s post. Thanks whoever you are, but frankly I’m so busy at the moment I’ve forgotten where it came from! Anyway, if you drop the following into your custom theme’s functions.php, you’ll get a new “Create child” link under every page listed in WP admin, when you hover over the title:

function slt_childPageAction( $actions, $page ) {
	$actions["create-child"] = '<a href="/wp-admin/page-new.php?parent_id=' . $page->ID . '" title="Create a new page with this page as its parent">Create child</a>';
	return $actions;
}
add_filter( 'page_row_actions', 'slt_childPageAction', 10, 2 );
function slt_setChildPage() {
	global $post;
	if ( $post->post_type == "page" && $post->post_parent == 0 && isset( $_GET["parent_id"] ) && is_numeric( $_GET["parent_id"] ) )
		echo '<script type="text/javascript">jQuery( document ).ready( function($) { $("#parent_id").val("' . $_GET["parent_id"] . '"); } );</script>';
}
add_action( 'edit_page_form', 'slt_setChildPage' );

The first bit adds the page action link. The second bit adds some jQuery to the right edit screen to set the specified parent, if it’s been passed. I couldn’t find another way to set the drop-down… Well, it works!

Custom fields are really flexible. However, they’re not perfectly user-friendly. For instance, if no post or page is currently using a custom field that you’ve built functionality on, the user has to enter the name as well as the value of the field the first time it’s used. The drop-down of field names is dynamically gathered from the fields currently in use. Also, sometimes you want to make things easier for clients by having inline tips, and inputs that suit the field (e.g. a checkbox or select drop-down instead of just a plain text entry).

So, I set about piecing together a way to take over the Custom Fields meta box…

First off, if you’re not developing custom themes, and you want a flexible plugin that will do this sort of thing, including an easy interface for defining custom fields, what I’ve got here isn’t for you. You might want to check out Custom Field Template, Flutter, or Magic Fields. Really, the power in any of those blows the code below out the water. My concern here is some lean, only-what-you-need code that you have total control over.

Before we begin, here’s a taster. This is a grab from a page edit screen on the project I’ve developed this code for:

I started off working with Function’s Custom Write Panels code, but their approach ended up being most concerned with post “metadata”. It’s all stored in one field in the postmeta table, in a serialized array. Which is great if you just need a clump of different values to output for any particular post. My needs are more diverse, and I often access individual fields for various reasons.

(TIP: If you store custom fields separately, as I will, and do end up wanting to grab them all at once, use get_post_custom().)

One more shout. I don’t know PHP objects very well, I’m absorbing it as I go. My class structure for this code was taken from the very useful WordPress Plugin Template from Pressography.

OK, let’s see what we’ve got. I’ll go through it step-by-step. This code is designed to go into your custom theme’s functions.php file—though if you wouldn’t have guessed, it might not be for you! (N.B. It must not be placed into /wp-includes/functions.php—see comments below.)

if ( !class_exists('myCustomFields') ) {

	class myCustomFields {
		/**
		* @var  string  $prefix  The prefix for storing custom fields in the postmeta table
		*/
		var $prefix = '_mcf_';

First a simple check to prevent class clashes, and the definition of the first property. This is the prefix that we’ll use for the meta_key when we store values in the postmeta table.

An important point to note here is that if you put an underscore at the start of a meta_key, the custom field will be “hidden”. That means it won’t show up in the default Custom Fields meta box. This code will include the option to hide that default box anyway, but there might be situations where you want to keep that in place for other reasons, alongside your custom fields box. In this case, it’s good to keep your fields in your box with this method.

		/**
		* @var  array  $customFields  Defines the custom fields available
		*/
		var $customFields =	array(
			array(
				"name"			=> "block-of-text",
				"title"			=> "A block of text",
				"description"	=> "",
				"type"			=> "textarea",
				"scope"			=>	array( "page" ),
				"capability"	=> "edit_pages"
			),
			array(
				"name"			=> "short-text",
				"title"			=> "A short bit of text",
				"description"	=> "",
				"type"			=>	"text",
				"scope"			=>	array( "post" ),
				"capability"	=> "edit_posts"
			),
			array(
				"name"			=> "checkbox",
				"title"			=> "Checkbox",
				"description"	=> "",
				"type"			=> "checkbox",
				"scope"			=>	array( "post", "page" ),
				"capability"	=> "manage_options"
			)
		);
		/**

Now we define our custom fields. I’ve set up a little system that’s quite flexible, and included examples of three common field types. Obviously, you can extend this however you want. The field types are up to you. I’ve been using custom types that create, say, drop-downs of users of a certain role, things like that.

Anyway, the basic values set for each field are:

• name: This gets used with the prefix to create the meta_key for the field.
• title: This is for the form’s <label>.
• description: This is a bit of descriptive text that goes under the field input, to help remind the user what it’s for.
• type: The types above happen to correspond to HTML form input types, but they don’t have to.
• scope: Where should these fields get used? Here it’s simply about whether they go on post or page screens, but again, you can make your own scopes up to restrict the fields to certain sections of your site, pages using certain templates, etc.
• capability: Which capability is required to edit the field? If you don’t understand WordPress capabilities, Justin Tadlock has an excellent introduction to users, roles and capabilities.

		/**
		* PHP 4 Compatible Constructor
		*/
		function myCustomFields() { $this->__construct(); }
		/**
		* PHP 5 Constructor
		*/
		function __construct() {
			add_action( 'admin_menu', array( &$this, 'createCustomFields' ) );
			add_action( 'save_post', array( &$this, 'saveCustomFields' ), 1, 2 );
			// Comment this line out if you want to keep default custom fields meta box
			add_action( 'do_meta_boxes', array( &$this, 'removeDefaultCustomFields' ), 10, 3 );
		}
		/**
		* Remove the default Custom Fields meta box
		*/
		function removeDefaultCustomFields( $type, $context, $post ) {
			foreach ( array( 'normal', 'advanced', 'side' ) as $context ) {
				remove_meta_box( 'postcustom', 'post', $context );
				remove_meta_box( 'postcustom', 'page', $context );
				//Use the line below instead of the line above for WP versions older than 2.9.1
				//remove_meta_box( 'pagecustomdiv', 'page', $context );
			}
		}
		/**
		* Create the new Custom Fields meta box
		*/
		function createCustomFields() {
			if ( function_exists( 'add_meta_box' ) ) {
				add_meta_box( 'my-custom-fields', 'Custom Fields', array( &$this, 'displayCustomFields' ), 'page', 'normal', 'high' );
				add_meta_box( 'my-custom-fields', 'Custom Fields', array( &$this, 'displayCustomFields' ), 'post', 'normal', 'high' );
			}
		}

Now there’s the class’s constructor, which basically adds the action hooks for outputting the new meta box, saving values when the form’s submitted, and removing the default Custom Fields meta box if necessary.

Then there’s the functions to remove the default box, and to create the new one. In this code, it’s assumed that the new box will be there whatever on post and page screens. If you have a system where you only need it on one or the other, or have more complex conditions, you’ll need to adapt the createCustomFields() function.

Note that older versions of WordPress will need a slightly different line of code to remove the default box on page screens. (Thanks to Bryan Casteel for this fix!)

		/**
		* Display the new Custom Fields meta box
		*/
		function displayCustomFields() {
			global $post;
			?>
			<div class="form-wrap">
				<?php
				wp_nonce_field( 'my-custom-fields', 'my-custom-fields_wpnonce', false, true );
				foreach ( $this->customFields as $customField ) {
					// Check scope
					$scope = $customField[ 'scope' ];
					$output = false;
					foreach ( $scope as $scopeItem ) {
						switch ( $scopeItem ) {
							case "post": {
								// Output on any post screen
								if ( basename( $_SERVER['SCRIPT_FILENAME'] )=="post-new.php" || $post->post_type=="post" )
									$output = true;
								break;
							}
							case "page": {
								// Output on any page screen
								if ( basename( $_SERVER['SCRIPT_FILENAME'] )=="page-new.php" || $post->post_type=="page" )
									$output = true;
								break;
							}
						}
						if ( $output ) break;
					}
					// Check capability
					if ( !current_user_can( $customField['capability'], $post->ID ) )
						$output = false;

Here’s the start of the output of the new custom fields box. We used wp_nonce_field() to improve security, then start our loop through all the defined fields.

The first check is on the scope of the field, which is an array of strings indicating the context in which they should be used. Outputting defaults to false, then gets set to true if any of the scope conditions are fulfilled. As I said earlier, you can define your own scopes for particular needs—the sky’s the limit.

Then there’s a quick check on the capability.

					// Output if allowed
					if ( $output ) { ?>
						<div class="form-field form-required">
							<?php
							switch ( $customField[ 'type' ] ) {
								case "checkbox": {
									// Checkbox
									echo '<label for="' . $this->prefix . $customField[ 'name' ] .'" style="display:inline;"><b>' . $customField[ 'title' ] . '</b></label>&nbsp;&nbsp;';
									echo '<input type="checkbox" name="' . $this->prefix . $customField['name'] . '" id="' . $this->prefix . $customField['name'] . '" value="yes"';
									if ( get_post_meta( $post->ID, $this->prefix . $customField['name'], true ) == "yes" )
										echo ' checked="checked"';
									echo '" style="width: auto;" />';
									break;
								}
								case "textarea": {
									// Text area
									echo '<label for="' . $this->prefix . $customField[ 'name' ] .'"><b>' . $customField[ 'title' ] . '</b></label>';
									echo '<textarea name="' . $this->prefix . $customField[ 'name' ] . '" id="' . $this->prefix . $customField[ 'name' ] . '" columns="30" rows="3">' . htmlspecialchars( get_post_meta( $post->ID, $this->prefix . $customField[ 'name' ], true ) ) . '</textarea>';
									break;
								}
								default: {
									// Plain text field
									echo '<label for="' . $this->prefix . $customField[ 'name' ] .'"><b>' . $customField[ 'title' ] . '</b></label>';
									echo '<input type="text" name="' . $this->prefix . $customField[ 'name' ] . '" id="' . $this->prefix . $customField[ 'name' ] . '" value="' . htmlspecialchars( get_post_meta( $post->ID, $this->prefix . $customField[ 'name' ], true ) ) . '" />';
									break;
								}
							}
							?>
							<?php if ( $customField[ 'description' ] ) echo '<p>' . $customField[ 'description' ] . '</p>'; ?>
					<?php
					}
				} ?>
			</div>
			<?php
		}

Now the output—pretty self-explanatory!

		/**
		* Save the new Custom Fields values
		*/
		function saveCustomFields( $post_id, $post ) {
			if ( !wp_verify_nonce( $_POST[ 'my-custom-fields_wpnonce' ], 'my-custom-fields' ) )
				return;
			if ( !current_user_can( 'edit_post', $post_id ) )
				return;
			if ( $post->post_type != 'page' && $post->post_type != 'post' )
				return;
			foreach ( $this->customFields as $customField ) {
				if ( current_user_can( $customField['capability'], $post_id ) ) {
					if ( isset( $_POST[ $this->prefix . $customField['name'] ] ) && trim( $_POST[ $this->prefix . $customField['name'] ] ) ) {
						update_post_meta( $post_id, $this->prefix . $customField[ 'name' ], $_POST[ $this->prefix . $customField['name'] ] );
					} else {
						delete_post_meta( $post_id, $this->prefix . $customField[ 'name' ] );
					}
				}
			}
		}

	} // End Class

} // End if class exists statement

// Instantiate the class
if ( class_exists('myCustomFields') ) {
	$myCustomFields_var = new myCustomFields();
}

Finally, a function to save the values when the form is submitted. The nonce is checked, then we loop through all the fields, checking that the capability is there and the field has been submitted. Then, we either add / update the field value if there is one, or delete it. You might want to just add / update, and store empty values for fields that apply to a post or page, but don’t have anything set. I thought I’d err on the side of keeping the database lean.

Then we instantiate the class, and that’s it.

The full code

Below is the code in full. To use it:

1. Paste it into your functions.php.
2. Change the $prefix if you want.
3. Adapt the $customFields array to define your fields.
4. If you’ve added your own scopes, add case statements for them around line 82.
5. If you’ve added your own field types, add case statements for them around line 105.

I’ve been adapting certain bits as a write this post, making the bits that are specific to my use of the code more general for this example, so forgive me if there’s any bugs that have crept in. Let me know if you find any problems with the code!

if ( !class_exists('myCustomFields') ) {

	class myCustomFields {
		/**
		* @var  string  $prefix  The prefix for storing custom fields in the postmeta table
		*/
		var $prefix = '_mcf_';
		/**
		* @var  array  $customFields  Defines the custom fields available
		*/
		var $customFields =	array(
			array(
				"name"			=> "block-of-text",
				"title"			=> "A block of text",
				"description"	=> "",
				"type"			=> "textarea",
				"scope"			=>	array( "page" ),
				"capability"	=> "edit_pages"
			),
			array(
				"name"			=> "short-text",
				"title"			=> "A short bit of text",
				"description"	=> "",
				"type"			=>	"text",
				"scope"			=>	array( "post" ),
				"capability"	=> "edit_posts"
			),
			array(
				"name"			=> "checkbox",
				"title"			=> "Checkbox",
				"description"	=> "",
				"type"			=> "checkbox",
				"scope"			=>	array( "post", "page" ),
				"capability"	=> "manage_options"
			)
		);
		/**
		* PHP 4 Compatible Constructor
		*/
		function myCustomFields() { $this->__construct(); }
		/**
		* PHP 5 Constructor
		*/
		function __construct() {
			add_action( 'admin_menu', array( &$this, 'createCustomFields' ) );
			add_action( 'save_post', array( &$this, 'saveCustomFields' ), 1, 2 );
			// Comment this line out if you want to keep default custom fields meta box
			add_action( 'do_meta_boxes', array( &$this, 'removeDefaultCustomFields' ), 10, 3 );
		}
		/**
		* Remove the default Custom Fields meta box
		*/
		function removeDefaultCustomFields( $type, $context, $post ) {
			foreach ( array( 'normal', 'advanced', 'side' ) as $context ) {
				remove_meta_box( 'postcustom', 'post', $context );
				remove_meta_box( 'postcustom', 'page', $context );
				//Use the line below instead of the line above for WP versions older than 2.9.1
				//remove_meta_box( 'pagecustomdiv', 'page', $context );
			}
		}
		/**
		* Create the new Custom Fields meta box
		*/
		function createCustomFields() {
			if ( function_exists( 'add_meta_box' ) ) {
				add_meta_box( 'my-custom-fields', 'Custom Fields', array( &$this, 'displayCustomFields' ), 'page', 'normal', 'high' );
				add_meta_box( 'my-custom-fields', 'Custom Fields', array( &$this, 'displayCustomFields' ), 'post', 'normal', 'high' );
			}
		}
		/**
		* Display the new Custom Fields meta box
		*/
		function displayCustomFields() {
			global $post;
			?>
			<div class="form-wrap">
				<?php
				wp_nonce_field( 'my-custom-fields', 'my-custom-fields_wpnonce', false, true );
				foreach ( $this->customFields as $customField ) {
					// Check scope
					$scope = $customField[ 'scope' ];
					$output = false;
					foreach ( $scope as $scopeItem ) {
						switch ( $scopeItem ) {
							case "post": {
								// Output on any post screen
								if ( basename( $_SERVER['SCRIPT_FILENAME'] )=="post-new.php" || $post->post_type=="post" )
									$output = true;
								break;
							}
							case "page": {
								// Output on any page screen
								if ( basename( $_SERVER['SCRIPT_FILENAME'] )=="page-new.php" || $post->post_type=="page" )
									$output = true;
								break;
							}
						}
						if ( $output ) break;
					}
					// Check capability
					if ( !current_user_can( $customField['capability'], $post->ID ) )
						$output = false;
					// Output if allowed
					if ( $output ) { ?>
						<div class="form-field form-required">
							<?php
							switch ( $customField[ 'type' ] ) {
								case "checkbox": {
									// Checkbox
									echo '<label for="' . $this->prefix . $customField[ 'name' ] .'" style="display:inline;"><b>' . $customField[ 'title' ] . '</b></label>&nbsp;&nbsp;';
									echo '<input type="checkbox" name="' . $this->prefix . $customField['name'] . '" id="' . $this->prefix . $customField['name'] . '" value="yes"';
									if ( get_post_meta( $post->ID, $this->prefix . $customField['name'], true ) == "yes" )
										echo ' checked="checked"';
									echo '" style="width: auto;" />';
									break;
								}
								case "textarea": {
									// Text area
									echo '<label for="' . $this->prefix . $customField[ 'name' ] .'"><b>' . $customField[ 'title' ] . '</b></label>';
									echo '<textarea name="' . $this->prefix . $customField[ 'name' ] . '" id="' . $this->prefix . $customField[ 'name' ] . '" columns="30" rows="3">' . htmlspecialchars( get_post_meta( $post->ID, $this->prefix . $customField[ 'name' ], true ) ) . '</textarea>';
									break;
								}
								default: {
									// Plain text field
									echo '<label for="' . $this->prefix . $customField[ 'name' ] .'"><b>' . $customField[ 'title' ] . '</b></label>';
									echo '<input type="text" name="' . $this->prefix . $customField[ 'name' ] . '" id="' . $this->prefix . $customField[ 'name' ] . '" value="' . htmlspecialchars( get_post_meta( $post->ID, $this->prefix . $customField[ 'name' ], true ) ) . '" />';
									break;
								}
							}
							?>
							<?php if ( $customField[ 'description' ] ) echo '<p>' . $customField[ 'description' ] . '</p>'; ?>
						</div>
					<?php
					}
				} ?>
			</div>
			<?php
		}
		/**
		* Save the new Custom Fields values
		*/
		function saveCustomFields( $post_id, $post ) {
			if ( !wp_verify_nonce( $_POST[ 'my-custom-fields_wpnonce' ], 'my-custom-fields' ) )
				return;
			if ( !current_user_can( 'edit_post', $post_id ) )
				return;
			if ( $post->post_type != 'page' && $post->post_type != 'post' )
				return;
			foreach ( $this->customFields as $customField ) {
				if ( current_user_can( $customField['capability'], $post_id ) ) {
					if ( isset( $_POST[ $this->prefix . $customField['name'] ] ) && trim( $_POST[ $this->prefix . $customField['name'] ] ) ) {
						update_post_meta( $post_id, $this->prefix . $customField[ 'name' ], $_POST[ $this->prefix . $customField['name'] ] );
					} else {
						delete_post_meta( $post_id, $this->prefix . $customField[ 'name' ] );
					}
				}
			}
		}

	} // End Class

} // End if class exists statement

// Instantiate the class
if ( class_exists('myCustomFields') ) {
	$myCustomFields_var = new myCustomFields();
}

UPDATE 18/11/09: I’ve just found an important issue with using the save_post hook. Alex King explains it here. The executive summary is that when the saveCustomFields function above is added to the save_post hook, it’s now set to receive 2 arguments—the post ID, as before, plus the post’s data. Using the passed $post argument, the save function checks that the post_type is “page” or “post”. This stops the save code being run for autosaves or saving revisions, which could create duplicate postmeta fields.

UPDATE 5/3/10: I’ve been alerted to a recent change in WordPress 2.9.1+ that affects the code in the removeDefaultCustomFields function to remove the default Custom Fields box on page screens. The change is highlighted in the above code.

But… WP_User_Search is only loaded when you’re inside the WP admin area. What about front-end template code?

I decided to track down the SQL that WP_User_Search comes up with for the search (using $wpdb->queries), and write a custom function wrapper which will work the same way wherever.

I’m not quite sure if there’s any advantage to including the use of WP_User_Search as well as the back-up SQL, as they pretty much do the same thing. I dunno.

Anyway, here’s the code. This is for pasting into your theme’s functions.php file. It’ll return an array of user IDs.

function getUsersByRole( $role ) {
	if ( class_exists( 'WP_User_Search' ) ) {
		$wp_user_search = new WP_User_Search( '', '', $role );
		$userIDs = $wp_user_search->get_results();
	} else {
		global $wpdb;
		$userIDs = $wpdb->get_col('
			SELECT ID
			FROM '.$wpdb->users.' INNER JOIN '.$wpdb->usermeta.'
			ON '.$wpdb->users.'.ID = '.$wpdb->usermeta.'.user_id
			WHERE '.$wpdb->usermeta.'.meta_key = \''.$wpdb->prefix.'capabilities\'
			AND '.$wpdb->usermeta.'.meta_value LIKE \'%"'.$role.'"%\'
		');
	}
	return $userIDs;
}

The idea came from work with various clients where certain pages started to get moved around, or just vanished. A page can “move” by having its parent page or the slug changed. Sometimes clients would delete a page and replace it with an updated version which had a slightly different slug.

Of course, many of these things just stem from usually harmless habits picked up from working with files on a computer. But on a website, you want to persist your URLs as long as possible. Unless absolutely necessary, pages should be kept with the same permalink, to avoid breaking links and to maximize PageRank and such like.

So, I created this plugin that lets you either lock all pages, or just particular pages. A page being “locked” means the slug can’t be edited, the parent can’t be changed, and it can’t be deleted. (Although, of course admins can still do these things.)

There’s a little more to it than that, but not much. It’s relatively simple. I’ve not yet got it going on any production sites, so technically it’s still in beta. But I’ve given it enough testing now to feel it should be announced. And yes, when I find a moment and I’ve tested it on production sites, I’ll prep it for release on the wordpress.org plugins repository.

Anyway, do check it out and let me know what you think…

Ideally, all active plugins should provide an “Am I being used?” option (alongside the usual “Deactivate” and “Edit” links on the WP plugins page). This would scan the system and detect whether or not there’s any current content, widgets, etc. that depend on the plugin being activated.

This might not always be 100% testable. In such cases, part of the test should include alerts regarding ways in which the plugin might be in use that are only manually detectable.

However, this kind of mechanical detection would help a lot when you’re scanning the list of plugins on a site, wondering whether or not all the active plugins are actually needed. Encouraging this kind of functionality might go a long way to helping reduce needless plugin overheads on WP installations.