Web Development

WordPress REST API returns error when updating quoted JSON data

My particular situation involved updating a user via REST API with a custom registered user meta. The meta updates correctly the first time, and any time there is a change. However an error is thrown if the user update includes the unchanged user meta (i.e. I’m updating the user’s first name, but my solution includes all fields with each update). The user meta value was a quoted JSON object, but this also applies to other serialized values. This also occurs with custom meta for other types besides users, like posts or comments.

The server returns a 500 HTTP status, with the following response:

{“code”:”rest_meta_database_error”,”message”:”Could not update meta value in database.”,”data”:{“key”:”my_custom_meta_key”,”status”:500}}

Credit for identifying this bug goes to Corey Salzano. Corey’s solution is to first pull the data, and if there’s no change, omit it in the update request. I didn’t want to add another request to the server, so I came up with a server-side solution. It is provided below with no guarantees!

// Fix for WP REST API meta error when sending updated encoded JSON with no change
add_filter( 'update_user_metadata' , function ( $value , $object_id , $meta_key = false , $meta_value, $prev_value ) {

	$meta_type = 'user';
	$serialized_meta_keys = array( 'my_special_custom_key' );

	if ( defined('REST_REQUEST') && REST_REQUEST && in_array($meta_key, $serialized_meta_keys) ) {

		$meta_cache = wp_cache_get($object_id, $meta_type . '_meta');
 
		if ( !$meta_cache ) {
			$meta_cache = update_meta_cache( $meta_type, array( $object_id ) );
			$meta_cache = $meta_cache[$object_id];
		}
 
		if ( isset($meta_cache[$meta_key]) ) {
			if ( $meta_value === $meta_cache[$meta_key][0] ) return true;
		}
	
	}
	
	return $value;
}, 10 , 5 );

// Fix for WP REST API meta error when sending updated encoded JSON with no change

add_filter( 'update_user_metadata' , function ( $value , $object_id , $meta_key = false , $meta_value, $prev_value ) {

$meta_type = 'user';

$serialized_meta_keys = array( 'my_special_custom_key' );

if ( defined('REST_REQUEST') && REST_REQUEST && in_array($meta_key, $serialized_meta_keys) ) {

$meta_cache = wp_cache_get($object_id, $meta_type . '_meta');

if ( !$meta_cache ) {

$meta_cache = update_meta_cache( $meta_type, array( $object_id ) );

$meta_cache = $meta_cache[$object_id];

}

if ( isset($meta_cache[$meta_key]) ) {

if ( $meta_value === $meta_cache[$meta_key][0] ) return true;

}

return $value;

}, 10 , 5 );

Note that you will have to change the hook update_user_metadata and $meta_type and $serialized_meta_keys for your particular situation.

reCAPTCHA Scrolling Issue on iOS

The problem occurs when an iOS user succeeds in verifying a Google reCaptcha (with or without the additional challenges); the window scrolls down way past the CAPTCHA, which can be very confusing for users. It was brought to my attention because some users at a site I manage were confounded when they were scrolled to a login form below a registration form…they thought it was some vicious loop! ?

This issue is documented at Google Groups, GitHub, and stackoverflow. The latter link is where most of the code below is sourced from, so credit to Jacob Cruz.

This was all within the context of a Gravity Forms form, using their native CAPTCHA field. I placed the code shown below in an HTML field after the CAPTCHA field.

<script>
// reCAPTCHA div container ID is hard coded below
window.scrollCaptcha = false;
document.getElementById('input_1_8').setAttribute('data-callback','scrollFixCaptcha');
function scrollFixCaptcha(a) { if(window.scrollCaptcha) { jQuery("html, body").scrollTop(window.scrollCaptcha); } }
document.addEventListener("scroll", function() {
	var el = document.getElementById('input_1_8');
	var theTop = window.pageYOffset || document.documentElement.scrollTop || document.body.scrollTop;
	var elemTop = el.getBoundingClientRect().top;
	var elemBottom = el.getBoundingClientRect().bottom;
	var isVisible = (elemTop >= 0) && (elemBottom <= window.innerHeight);
	if(isVisible) { window.scrollCaptcha = theTop;  }  
});
</script>

// reCAPTCHA div container ID is hard coded below

window.scrollCaptcha = false;

document.getElementById('input_1_8').setAttribute('data-callback','scrollFixCaptcha');

function scrollFixCaptcha(a) { if(window.scrollCaptcha) { jQuery("html, body").scrollTop(window.scrollCaptcha); } }

document.addEventListener("scroll", function() {

var el = document.getElementById('input_1_8');

var theTop = window.pageYOffset || document.documentElement.scrollTop || document.body.scrollTop;

var elemTop = el.getBoundingClientRect().top;

var elemBottom = el.getBoundingClientRect().bottom;

var isVisible = (elemTop >= 0) && (elemBottom <= window.innerHeight);

if(isVisible) { window.scrollCaptcha = theTop; }

});

</script>

Filemaker and MySQL Floats in Relationship

I’ve been connecting a Filemaker Pro solution with a WordPress website for a client. In a matching relationship to a Gravity Forms table (rg_lead_detail) I was matching a local field with the Gravity Forms column “field_number” which is defined as a float. I noticed that the relationship was only matching whole integers, not numbers with decimals like “1.3”.

Researching this problem led me to this article about MySQL float columns not being precisely recorded:

If you store the number 1.3 in a float column of your database table, MySQL actually stores the number 1.2999999523162842.

My quick solution was to create two calculation fields, one high and one low based on the local field. The high calculation added 0.05 to the field, and the low field subtracted 0.05. This assumes the field only goes to tenths.

It works for this application, but I don’t see it working for solutions needing precision and accuracy to multiple decimal places.

WordPress 3.7.1 Update Causing Errors

Upgrading to WordPress 3.7.1 broke a lot of backend (admin, wp-admin) pages. I got 404 Missing and sometimes 500 Internal Server Errors for themes.php, and options.php. No quick fixes were working…

Upgrading PHP from 5.3 to 5.4 solved all issues.

WordPress.org states that the minimum PHP version required is version 5.2.4 or greater. I was using 5.2.11 and upgraded to 5.3.15. Good luck!

Change Media Attachment Post in WordPress

When you upload an image or other media to a WordPress site via the “Add Media” button on a post (or page or custom type) edit page, that media is linked to that page. You can still insert that media on another post, or in a gallery on another post, but it is “forever” attached to the original post. I say “forever” because WordPress stock gives you no options for reattaching it (or detaching it.) This may be desired for many situations often involving 3rd party plugins. Your options are re-upload the media to the new post, alter the MySQL database directly or find a plugin that adds this functionality. Below is quick code that adds a link on the Media page for each Media Item.

Credit for this code goes to Andy Potanin via the WordPress forums here. Add it to your theme’s function.php file at the end. I just tested it with WordPress 3.5.1…

add_filter("manage_upload_columns", 'upload_columns');
add_action("manage_media_custom_column", 'media_custom_columns', 0, 2);

function upload_columns($columns) {

	unset($columns['parent']);
	$columns['better_parent'] = "Parent";

	return $columns;

}
 function media_custom_columns($column_name, $id) {

	$post = get_post($id);

	if($column_name != 'better_parent')
		return;

		if ( $post->post_parent > 0 ) {
			if ( get_post($post->post_parent) ) {
				$title =_draft_or_post_title($post->post_parent);
			}
			?>
			<strong><a href="<?php echo get_edit_post_link( $post->post_parent ); ?>"><?php echo $title ?></a></strong>, <?php echo get_the_time(__('Y/m/d')); ?>
			<br />
			<a class="hide-if-no-js" onclick="findPosts.open('media[]','<?php echo $post->ID ?>');return false;" href="#the-list"><?php _e('Re-Attach'); ?></a></td>

			<?php
		} else {
			?>
			<?php _e('(Unattached)'); ?><br />
			<a class="hide-if-no-js" onclick="findPosts.open('media[]','<?php echo $post->ID ?>');return false;" href="#the-list"><?php _e('Attach'); ?></a>
			<?php
		}

}

add_filter("manage_upload_columns", 'upload_columns');

add_action("manage_media_custom_column", 'media_custom_columns', 0, 2);

function upload_columns($columns) {

unset($columns['parent']);

$columns['better_parent'] = "Parent";

return $columns;

}

function media_custom_columns($column_name, $id) {

$post = get_post($id);

if($column_name != 'better_parent')

return;

if ( $post->post_parent > 0 ) {

if ( get_post($post->post_parent) ) {

$title =_draft_or_post_title($post->post_parent);

}

<strong><a href="<?php echo get_edit_post_link( $post->post_parent ); ?>"><?php echo $title ?></a></strong>, <?php echo get_the_time(__('Y/m/d')); ?>

<br />

<a class="hide-if-no-js" onclick="findPosts.open('media[]','<?php echo $post->ID ?>');return false;" href="#the-list"><?php _e('Re-Attach'); ?></a></td>

<?php

} else {

<?php _e('(Unattached)'); ?><br />

<a class="hide-if-no-js" onclick="findPosts.open('media[]','<?php echo $post->ID ?>');return false;" href="#the-list"><?php _e('Attach'); ?></a>

<?php

}

WP E-Commerce Using Incorrect Timezone

I noticed incorrect dates in the sales log, as well as incorrect expiration calculations for coupons… Not great things. WP E-Commerce appears to ignore the WordPress settings and use the server settings via PHP.

Quick fix solution, credit goes to Babelscribe.com

Set the server timezone by adding this to the header file of your theme:

<?php date_default_timezone_set ('Pacific/Auckland' ); ?>

Time zones are detailed here:

http://www.php.net/manual/en/timezones.php

I just added it to the top of the theme’s function.php, seems more appropriate than any header template. Obviously you must adjust the argument for your timezone.

This instantly fixed and updated dates displayed everywhere in WP E-Commerce.

Creating a WP e-Commerce plugin: Settings Page API (fix)

Recently I’ve been developing a WordPress plugin to extend WP e-Commerce, a free storefront plugin. I used to use osCommerce, a robust PHP solution for shopping carts and heavily customized it. I was looking at this implementation of osCommerce (a great effort) as a WordPress plugin, but it was like reinventing the wheel–not worth it. WP e-Commerce is a native WordPress plugin, works well, has a huge user base and is (mostly) easy to extend.

The WP e-Commerce developers are kind enough to provide documentation for developers of plugins. Their page on “Settings Page API” describes the process of adding a tab to the WPEC settings page. While mostly straightforward there are two points that tripped me up:

The class WPSC_Settings_Tab_PLUGIN_SLUG extends WPSC_Settings_Tab needs to be inside the plugin tab function being described. This issue was mostly a result of my own dimness…
This one seems to be a typo. The action hook tying in your plugin tab function as described is:

1

add_action( 'wpsc_load_settings_tab_class', 'my_plugin_settings_tabs');

However while using this action hook, my plugin settings tab was not accessible directly, only through an AJAX call after the settings page was already loaded. Also, I was using the optional public function callback_submit_options() to handle the form submission myself, and this was non-functional! Using the following hook fixed all this and resulted in a settings tab that functioned identically to the default tabs:

add_action( 'wpsc_register_settings_tabs', 'my_plugin_settings_tabs');

It’s this the main query?

The main query in a WordPress site is the query based on the URL being accessed. When you access this post’s single page, the URL indicates the main query is the text you are reading right now. The “Recent Posts” widget on the sidebar is generated from a query, but not the main query.

There are a few methods to test for the “main query”. As of WordPress 3.3, there is a new way:

$query->is_main_query()

Examples: Using pre_get_posts hook | Using posts_where hook

There’s the old way (which is the basis for the above method):

1 2	global $wp_the_query; if( $wp_the_query === $query)

In situations where I wanted to alter the content of a post (in the loop) if it was the main query, the above methods didn’t work reliably. I attempted to hook into the pre_get_posts action and set a global variable, which I would then test in the content filter function. I reasoned that the variable would be set to true before the loop, and then set to false if another query was called after that. The results however were always false.

My solution was to set a global variable with the post ID in a wp_head action, then test that against the post ID while in the loop (every time the_content filter is called.) Code below…

add_action( 'wp_head', 'main_query_test', 0 );

function main_query_test() {
	global $main_query_test, $post;
	$main_query_test = $post->ID;
}

add_filter('the_content', 'my_content_filter');

function my_content_filter($content) {
	global $main_query_test;
	if ($main_query_test == get_the_id() && is_singular()) {
		$main_query_test = null; // Prevent a second instance
		// do content filtering
	}
	return $content;
}

add_action( 'wp_head', 'main_query_test', 0 );

function main_query_test() {

global $main_query_test, $post;

$main_query_test = $post->ID;

}

add_filter('the_content', 'my_content_filter');

function my_content_filter($content) {

global $main_query_test;

if ($main_query_test == get_the_id() && is_singular()) {

$main_query_test = null; // Prevent a second instance

// do content filtering

}

return $content;

}

Now it’s quite possible this is not the most direct, efficient or reliable method. I welcome your comments if you have suggestions or concerns.

Displaying Custom Post Types by Term

It’s documented, it’s used, but it wasn’t obvious to me. After hunting around, I finally found what I needed in the first place I looked: the WordPress Codex.

This is the wp_query argument needed to display posts assigned a particular term:

'tax_query' =&gt; array(array(
			'taxonomy' =&gt; 'site-categories',
			'field' =&gt; 'slug',
			'terms' =&gt; 'telephony'
		    )
	        )

'tax_query' => array(array(

'taxonomy' => 'site-categories',

'field' => 'slug',

'terms' => 'telephony'

)

Using the term ID as a cat ID wasn’t working. I came across the above here, and used it in two simple loops to display the custom posts under category headers.

An error has occurred. Please try again later.

Want to display posts in a nested hierarchy? This goal led me to what is probably a cleaner solution. The following code is adapted from Hierarchical Category List with Post Titles, and blended with the code above.

function my_custom_post_type_terms() {
	global $wp_query,$paged,$post;
	$temp = $wp_query;
	$wp_query= null;
	ob_start();
	$args = array(
			'orderby' => 'name',
 	 		'order' => 'ASC',
 	 		'taxonomy' => 'custom-taxonomony-slug'
 			);
	$categories = get_categories($args);
  	foreach($categories as $category) :
  		if (!$category->parent) { ?>
  			<h2 class="title"><?php echo $category->name; ?></h2>
  			<?php process_cat_tree($category->term_id);
  		}
  	endforeach;
	$wp_query = null; 
	$wp_query = $temp;
	$content = ob_get_contents();
	ob_end_clean();
	return $content;
}
function process_cat_tree($cat) {
	global $wp_query,$paged,$post;
	$args = array('tax_query' => array(
		array(
			'taxonomy' => 'custom-taxonomony-slug',
			'field' => 'id',
			'terms' => $cat,
			'include_children' => false
		)
	), 'numberposts' => -1, 'orderby' => 'name', 'order' => 'ASC');
	$wp_query = new WP_Query($args); ?>
	<ul class="sites-list">
	<?php while ($wp_query->have_posts()) : $wp_query->the_post(); ?>
              <li>
                   <p><a href="<?php the_permalink(); ?>"><?php echo the_title(); ?></a></p>
                   <?php the_content(); ?>
               </li>
	<?php endwhile; ?>
	</ul>
	
	<?php $next = get_categories(array(
 	 		'taxonomy' => 'custom-taxonomony-slug',
 	 		'parent' => $cat));
	if($next) :
		foreach( $next as $category ) : ?>
			<h3 class="sub-cat-title"><?php echo $category->name; ?></h3>
 			<?php process_cat_tree( $category->term_id );
 		endforeach;
 	endif;
}

function my_custom_post_type_terms() {

global $wp_query,$paged,$post;

$temp = $wp_query;

$wp_query= null;

ob_start();

$args = array(

'orderby' => 'name',

'order' => 'ASC',

'taxonomy' => 'custom-taxonomony-slug'

);

$categories = get_categories($args);

foreach($categories as $category) :

if (!$category->parent) { ?>

<?php process_cat_tree($category->term_id);

}

endforeach;

$wp_query = null;

$wp_query = $temp;

$content = ob_get_contents();

ob_end_clean();

return $content;

}

function process_cat_tree($cat) {

global $wp_query,$paged,$post;

$args = array('tax_query' => array(

array(

'taxonomy' => 'custom-taxonomony-slug',

'field' => 'id',

'terms' => $cat,

'include_children' => false

)

), 'numberposts' => -1, 'orderby' => 'name', 'order' => 'ASC');

$wp_query = new WP_Query($args); ?>

<?php while ($wp_query->have_posts()) : $wp_query->the_post(); ?>

<li>

<?php the_content(); ?>

</li>

<?php endwhile; ?>

</ul>

<?php $next = get_categories(array(

'taxonomy' => 'custom-taxonomony-slug',

'parent' => $cat));

if($next) :

foreach( $next as $category ) : ?>

<?php process_cat_tree( $category->term_id );

endforeach;

endif;

}

It’s in action here under Sites…

Conditional Display of Widgets in WordPress

Many times I’ve needed to display or hide a widget based on some condition. Usually that condition is which page is being served. That’s easy enough with my own widgets by wrapping the output in an if statement employing a built-in WordPress Conditional Tag. The same can of course be done by directly editing 3rd-party widgets/plugins.

What if you need to change the behavior of a 3rd-party widget, but don’t want to alter it’s code? There’s a great plugin called Widget Logic that can help you do just that. The only caveat is that it directly runs code that you input. That opens up a security hole by executing code stored in the database. Not always a show stopper, but when developing for clients I try to play it safe.

Almost all the code and comments below are borrowed directly from the Widget Logic plugin. I’ve greatly simplified it to effect only the widget(s) and condition(s) hard coded. Also I removed the filtering function, as I was only using this to hide or show a widget. If you want to alter the output of a widget, it’s a pretty simple copy and paste from the original plugin to the second function.

// CALLED ON 'dynamic_sidebar_params' FILTER - this is called during 'dynamic_sidebar' just before each callback is run
// swap out the original call back and replace it with our own
function widget_restrict_widget_display_callback($params)
{ 
	global $wp_registered_widgets;
	$id=$params[0]['widget_id'];
	if ($id == '/*INSERT WIDGET ID HERE*/' && /*INSERT CONDITIONAL TAGS HERE*/) {
		$wp_registered_widgets[$id]['callback_wl_redirect']=$wp_registered_widgets[$id]['callback'];
		$wp_registered_widgets[$id]['callback']='widget_restrict_redirected_callback';
	}
	return $params;
}
// the redirection comes here
function widget_restrict_redirected_callback()
{
	echo '<h1> </h1>';
}
// redirect the widget callback so the output can be buffered and filtered
add_filter( 'dynamic_sidebar_params', 'widget_restrict_widget_display_callback', 10);

// CALLED ON 'dynamic_sidebar_params' FILTER - this is called during 'dynamic_sidebar' just before each callback is run

// swap out the original call back and replace it with our own

function widget_restrict_widget_display_callback($params)

{

global $wp_registered_widgets;

$id=$params[0]['widget_id'];

if ($id == '/*INSERT WIDGET ID HERE*/' && /*INSERT CONDITIONAL TAGS HERE*/) {

$wp_registered_widgets[$id]['callback_wl_redirect']=$wp_registered_widgets[$id]['callback'];

$wp_registered_widgets[$id]['callback']='widget_restrict_redirected_callback';

}

return $params;

}

// the redirection comes here

function widget_restrict_redirected_callback()

{

echo '<h1> </h1>';

}

// redirect the widget callback so the output can be buffered and filtered

add_filter( 'dynamic_sidebar_params', 'widget_restrict_widget_display_callback', 10);

Find the unique widget ID by inspecting the source of a page displaying the widget, like:

Insert the ID into the space specified. Next add in some conditional tags in the space specified like:

(is_page(739) || is_single())

1	(is_page(739) \|\| is_single())