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!

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.

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.

Edit Relationship

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

upgrade_wordpressUpgrading 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…

 

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:

  1. 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…
  2. This one seems to be a typo. The action hook tying in your plugin tab function as described is: 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):

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…

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:

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.

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.

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.

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: