Simon Battersby

I’ve spent a lot of time this morning looking into an issue with a client site migration where Page Builder data was lost after the migration.

I have migrated many many WordPress sites by exporting the database, replacing the old URL with the new URL in the exported SQL and re-importing. Never had an issue. But in this case I did, and it’s related to how Page Builder stores data. This data is serialized, and the serialization stores both the data and its length. So a snippet of stored data looks like this:

s:160:"<p><img class="alignleft size-full wp-image-2348" src="http://test.co.uk/wp-content/uploads/2014/05/Tulips.jpg" alt="Tulips" width="200" height="150" /></p>"

Super…so if you run a global replace on the domain name you end up with this:

s:160:"<p><img class="alignleft size-full wp-image-2348" src="http://production.co.uk/wp-content/uploads/2014/05/Tulips.jpg" alt="Tulips" width="200" height="150" /></p>"

Which looks fine, but it isn’t because the serialization is now incorrect as the length of the serialized string has changed from 160 characters to 166 characters. Result: lost Page Builder data.

The correct update should be:

s:166:"<p><img class="alignleft size-full wp-image-2348" src="http://production.co.uk/wp-content/uploads/2014/05/Tulips.jpg" alt="Tulips" width="200" height="150" /></p>"

Clearly doing this is impracticable and fortunately there’s a plugin that handles this which is WP Migrate DB.

Working on a client project which applies a hierarchical custom taxonomy to a custom post type I needed to find the lowest level set for the post. Assuming that there is only one hierarchy applied to the post the following does the trick, for categories (running on the single post page):

$categories = get_categories();
$parents = array();
if($categories){
	foreach ($categories as $category){
		$ids[] = $category->term_id;//read the category ids into an array
		if ($category->parent) $parents[] = $category->parent;//read the parent ids into an array
	}
}		
$low_categories =  array_diff ($ids,$parents);//get the ids which are not parents
$lowest_category = array_shift($low_categories);//read the first id (just in case there's more than one)

If you’re working with a custom taxonomy called, say, ‘classification’ then this becomes:

$post_classifications = get_the_terms($get_the_ID,'classification');
if($post_classifications){
	foreach ($post_classifications as $post_classification){
		$ids[] = $post_classification->term_id;
		if ($post_classification->parent) $parents[] = $post_classification->parent;
	}
}		
$low_class =  array_diff ($ids,$parents);
$classification = array_shift($low_class);

Hope this helps someone else…

Had a bit of a head-scratcher on this one this afternoon…

I have a couple of custom post types set up, category and product, and a number of custom field attached to each of these, managed by Elliot Condon’s outstanding Advanced Custom Fields plugin. In this case, I have a Relationship field defined on product, which allows the user to assign a product to one or more category. All very lovely, but I then started on a situation where I wanted to show all products which were related to a given category.

The WP codex is a little light on examples, here, but I eventually triumphed with the following:

$args = array( 
   'post_type' 		=> 'product', 
   'posts_per_page'	=> -1,
   'meta_query'  	=> array(
			      array(
				     'key'           => 'category',
				     'value'         => '"'.$category.'"',//quotes to make sure category 23 does not match category 123, 230 etc
				     'compare'       => 'LIKE'
			      )
			   )
);
//get products
$wp_query = new WP_Query( $args );

To explain this a little, ‘category’ is the meta_key assigned to the field on product, and $category is the ID of the category that I’m passing in. It took me a little while to understand the SQL generated here. What happens is that meta_query casts the serialized data into characters, like this, where $category = 23:

SELECT wp_posts.* FROM wp_posts INNER JOIN wp_postmeta ON (wp_posts.ID = wp_postmeta.post_id) WHERE 1=1 
AND wp_posts.post_type = 'product' 
AND (wp_posts.post_status = 'publish' OR wp_posts.post_status = 'private') 
AND ( (wp_postmeta.meta_key = 'category' AND CAST(wp_postmeta.meta_value AS CHAR) LIKE '%\"23\"%') ) 
GROUP BY wp_posts.ID 
ORDER BY wp_posts.post_date DESC

Once I realised what was going on it then becomes straightforward to use LIKE to find matching records. However, there’s a potential gotcha in there, which, in my example, would manifest if there was another category with and ID of 123, 230, 2300 etc etc. Without the quotes wrapped around my $category variable here, then the query would return products linked to any of these categories as well. It seems as if meta_query should allow an ‘in_array’ type comparison here, as the existing approach feels a bit clunky.

This morning I spent a little time constructing an ajax call from a front-end page (not an admin page) using wp_ajax. As is my wont, I tested this in Firefox and all was well. I used the WP codex.

Then I tried it in Opera and it failed, no response whatsoever, just a 0 in the ajax response. Seemed odd that Opera should have a problem, tried it in Chrome, same thing. Lots of Googling later, saw loads of similar questions being asked, no answers…

I then looked at the code in wp_ajax, and all became clear…

I had entries in my functions.php as follows:

 add_action('wp_ajax_myfunction', 'myfunction');
 
 function myfunction() {
    //stuff
 }

So if I pass an action of ‘myfunction’ to wp_ajax it should call the hook at the top of the above code, which in turn calls myfunction(), right? Only if you are logged on to WordPress at the time! If you aren’t logged in, wp_ajax calls the hook wp_ajax_nopriv_myfunction. And that’s why it worked for me in Firefox, because I was also logged on through Firefox. Nowhere is this mentioned in the codex, that I can see.

Having identified this it’s then simple to add another hook to your functions.php:

 add_action('wp_ajax_nopriv_myfunction', 'myfunction');

Hope this saves someone an hour or so…