So for these clients it’s often a little confusing to have “Posts” at the top of the nav menu. Here’s how you would reorder to the nav to put pages on top.

First turn on the custom ordering option:

add_filter('custom_menu_order','__return_true');

Then create a function to filter the menu order array. In the function below we’re using array_splice to cut out the menu starting at position 2 because the “posts” menu item is #3 by default. How did I know that? Just add print_r($menu) and you’ll get a dump of the menu order. After splicing the array, we iterate over the old menu array, the part we extracted ($old), using a foreach loop adding the old menu items back in.

function mc_menu_order($menu) {
// more on array_splice here: http://php.net/manual/en/function.array-splice.php
	$old = array_splice($menu,2,count($menu),array('2'=>'edit.php?post_type=page'));
	$keys = array_flip($menu);
	foreach($old as $item) {
		if(!array_key_exists($item,$keys)) {
			$menu[] = $item;
		}
	}
	unset($old);
	unset($keys);
	return $menu;
}

Then just add the api call to insert that function:

add_filter('menu_order','mc_menu_order');

Here it is all together:

//menu reorder
add_filter('custom_menu_order','__return_true');
add_filter('menu_order','mc_menu_order');
function mc_menu_order($menu) {
	$old = array_splice($menu,2,count($menu),array('2'=>'edit.php?post_type=page'));
	$keys = array_flip($menu);
	foreach($old as $item) {
		if(!array_key_exists($item,$keys)) {
			$menu[] = $item;
		}
	}
	unset($old);
	unset($keys);
	return $menu;
}

The interface is smooth and as far as I can tell so far, there’s no front end performance hit. Though, I must admit I do not use the front-end functions provided by ACF and instead prefer to rely on the standard <code>get_post_meta()</code> approach.

But there are two things specifically I enjoy about this plugin. First, it gives you the option to have your “field group” either inside an expandable meta box. This is the standard way custom fields are presented. But it also gives you the ability to add the fields right into the form with no meta box wrapping element. This gives your form some variety. (see screen shots)

The second thing I really enjoy about this plugin is the API for adding custom field types. Developers always love finding an organized API when they need one. For this specific project I need a field where the user could select a NextGen Gallery from a dropdown. All I had to do was create a class extending the acfField. Then add the following to my functions.php:

add_action('acf_register_field','ngg_register_acf_field');
function ngg_register_acf_field() {
	add_filter('acf_register_field','ngg_field',0,1);
}

function ngg_field($custom) {
	global $acf;
	$ngg = array('class'=>'acf_NGG_Gallery','url'=>PATHTODIR.'/acf_ngg.php');
	$custom['ngg'] = $ngg;
	return $custom;
   }

First checkout the files using the force option.

svn checkout --force http://vanwinkle.somesvnserver.com/trunk/ ./

This will force the checkout process to complete, but your old files will not really be overwritten. Instead they will be considered modified version of the corresponding file in the repo. So to complete the process you need to do:

svn revert -R ./

This tells subversion to “revert” the files in the existing directory to the versioned state. The -R tells it to do this recursively and the ./ tells it to start in the current directory.

Get the Links Module

wp_cache_delete($post_id,'posts');

By contrast if you’re developing with WordPress and you reach a point where you have to go beyond core and start building custom plugins there’s really no pattern to follow. Sure there are hooks and filters that allow you to customize as much as you want. But because WP is not a custom framework, it isn’t built for customization and there are no internal conventions for full-on custom modification. So each plugin you look at has a slightly different approach to accomplishing goals. The Pods CMS project attempts to create a standard for customization, but it has not yet been fully developed or fully adopted.

PyroCMS on the other hand, being CI based, strictly follows the MVC pattern and thus allows developers to anticipate the structure of any module, and replicate and override those modules if necessary. This is what custom frameworks setup to do. PyroCMS combines the code-base scalability with WordPress like features and the ability to quickly launch sites. Though, it still has a ways to go match up with WordPress on features.

This distinction is relevant for clients too. You decide to save on development costs and use a system like WordPress for your CMS. But then you start customizing everything and before you know it what you really have is a custom site attached to a WordPress install. This is fine until your developer goes on to bigger and better projects and you have to find a new one. Well, your WordPress install is too hacked and customized for average WordPress developers to handle. But because it wasn’t built on a custom framework, PHP developers will not be able to easily and quickly understand how the site was setup. Either way the cost of maintenance is going to be considerably higher than if you had gone custom in the first place.

global $current_user;

This was used to return an object containing not only the primary user fields but all the meta fields as well. So if you set a user meta field called “age” you could simply do:

global $current_user;
if($current_user->data->age > 21) {
  // the do some adult stuff;
}

But this shortcut is no longer available to developers and for good reason. As a general rule code should be efficient, meaning it does only what it has to. To load even the most superflous meta fields every time you access the basic user object is a waste of resources.

So good for WordPress, they are improving. But there are likely others like me who figured if WordPress was going to give me the info, then I was going to use it. And like me they’ll have to spend all day tracking down everywhere they used this shortcut and fixing it. Ugh.