Strictly AutoTags Fit For WordPress version 3.9.1

Strictly AutoTags Fit For WordPress version 3.9.1

By Strictly-Software

A couple of posts ago I told my users of my plugin that they should be careful if upgrading to WordPress version 3.9.1 as they have totally re-written their core database file wpdb.php to handle a newer format for MySQL queries MySQLi.

They have also added in some good functionality such as their own version for my own fix for their "MySQL Server has gone away" error which just loops for 5 times while trying to re-connect to the database if the connection has been lost. Almost an exact copy of my own idea!

Anyway I was a bit wary about the change but after going over the code in the file I can see they have branched everything out so that if your plugin is still using the older MySQL code-base it will still work.

Basically anything to do with MySQL has an IF statement to check whether the user is using mysqli or not. If not they still run with the older version of the code.

Therefore after a slight issue yesterday which you can read about here: WordPress Forum where a user who was using BOTH Strictly AutoTags AND Strictly TweetBOT ran into an error with JUST the TweetBOT plugin.

There was no mention of Strictly AutoTags which I guess he would have mentioned as he said in the first line he was using BOTH the plugins and the two were working in conjunction with each other. Therefore after some scanning of the code I am 99% sure there isn't a problem with the code and it would be safe to do an update to WordPress 3.9.1.

The issue yesterday was that WordPress had extended their Prepare function so that it ran a test to see if any % signs existed in the SQL statement it raised an error if they didn't. Why they did this I don't know but I removed the prepare function from the offending SQL statement and now Strictly TweetBot works fine with WordPress 3.9.1.

Also I notice in the main section of the plugin page people have put in the compatibility box that it DOES work with version 3.9.1 of the WordPress codebase so if it doesn't someone (or lots of people) are lying!

By the way you can now also buy the premium version of my plugin on etsy.com if you so wish as I setup a shop yesterday. I have already added more products including digital vouchers that will enable you to let me configure your own sites for the best use of my plugins as well as for SEO, security and much more.

Anyway I thought I better let you know in case you were holding off upgrading your WordPress core code base.

In any case (as I do with any big backup - and as WordPress advice) I would backup the files and the database just in case (especially the /wp-includes/wpdb.php file) and if anything goes wrong let me know either here on the blog or on the WordPress support forum.

Thanks

Rob

Problems with WordPress version 3.9 and 3.9.1 - Prepare Statement

Problems with WordPress version 3.9 and 3.9.1 - Prepare Statement

By Strictly-Software

If you have upgraded to WordPress 3.9.1 and suddenly found yourself with a bunch of errors coming from you in every direction it will probably be due to their decision to re-write their wpdb.php class.

Whilst I applaud their decision to implement their own version of my own code that was fixing the "MySQL Server Has Gone Away" Error that seemed to appear everywhere due to lost connections.

It does this by repeatedly calling a "reconnect" in a loop if the error is spawned.

I have to say as a WordPress developer with not much time on his hands that to be told a day before by email (from WordPress) that they were releasing version 3.9 the very next day was not very helpful indeed.

I did warn all my plugin users NOT to upgrade to it (see >  http://blog.strictly-software.com/2014/04/please-dont-upgade-to-wordpress-39.html) as I have no idea what will break with my own plugins if they do.

I still am on 3.8.2 and I won't upgrade until I know I won't be causing a whole shit storm of bugs for myself.

One of these bugs is the prepare statement.

Whilst a newbie PHP / WordPress developer I got into the habit of using $wpdb->prepare all the time when creating inline SQL statements - "where are the decent, transaction, multi recordset returning stored procedures that MS SQL did 10 years ago I still cry in the air at MySQL in vain!"

Therefore a statement like this where I am replacing certain parameters with values is what prepare is aimed for and will work fine in WP 3.9.1

$sql = $wpdb->prepare("UPDATE {$wpdb->posts} SET post_content = %s WHERE id = %d;", $newcontent,$object->ID);

However because of the new re-write of their wpdb.php class in /wp-includes to handle both old and new versions of the MySQL library functions they have also added some unnecessary (or maybe they think they are - forgetting the millions of people who use their code and the plugins built on it) methods and new functionality to existing methods.

One of those is in the prepare method

At the top of the function are these lines of code.

function prepare( $query, $args ) {

if ( is_null( $query ) )
   return;

// This is not meant to be foolproof -- but it will catch obviously incorrect usage.
if ( strpos( $query, '%' ) === false ) {

              _doing_it_wrong( 'wpdb::prepare', sprintf( __( 'The query argument of %s must have a placeholder.' ), 'wpdb::prepare()' ), '3.9' );

}

Notice what it is doing?

It is making sure that the query passed into the prepare method has at least one % symbol in it.

Therefore if you are a plugin write who has just got into the habit of wrapping all their WordPress SQL strings in $wpdb->prepare functions - whether OR NOT they actually have parameters to be replaced you are now in a big hole of doom.

Instead of the error message I guess they hope users see ("The query argument of %s must have a placeholder") is shown to people instead I am getting complaints (see > WordPress bug in my plugin - really WP 3.9.1 ) that don't contain that error message at all.

Instead it will just be a warning that

Warning: Missing argument 2 for wpdb::prepare(), called in XXXX

Therefore quick fixes

1. Use my own wpdb.php class in 3.9.1 and forget about the newer MySQL functions but still have the fix for MySQL Server Has Gone Away and NO ERRORS when Prepare is used without parameters.

2. Remove those lines of code from the top of the wpdb.php class. e.g

function prepare( $query, $args ) {

if ( is_null( $query ) )
   return;

// REMOVE THESE LINES BELOW!
// This is not meant to be foolproof -- but it will catch obviously incorrect usage.
if ( strpos( $query, '%' ) === false ) {

              _doing_it_wrong( 'wpdb::prepare', sprintf( __( 'The query argument of %s must have a placeholder.' ), 'wpdb::prepare()' ), '3.9' );

}

3. Return to using WordPress 3.8.1. There might be some legitimate security holes that the WordPress team have fixed so be careful and check what they actually did in the 3.9 and 3.9.1 updates. Also make sure you are blocking spammers, hackers and the like with tools like fail2ban, .htaccess rules, firewalls, DenyHosts, WordPress firewall plugins and constant analysis of your log files.

Read my article on WordPress security for more information: blog.strictly-software.com/2012/03/wordpress-survival-guide-part-3.html

4. Or get every plugin developer who has used this method without placeholders to rewrite his code, even though he has a hectic day job and may not care or have the time.

If you do - donate!

If you do try and get him to change his code due to WordPress changing theirs as it's not the plugin developers fault in my eyes.