PHP7 Support For Strictly AutoTags

PHP7 Support For Strictly AutoTags

By Strictly-Software


If you are using the popular Strictly AutoTags plugin then everything should be working fine however if you have upgraded to PHP 7 then that will have caused problems.

Not every developer has the time or knowledge to know that a new PHP version will remove features or cause issues with their plugins. However in this case it's due to the /e modifier being dropped.

$content = preg_replace("/(\.[”’\"]?\s*[A-Z][a-z]+\s[a-z])/e","strtolower('$1')",$content);

The only difference apart from the callback is that I am using @ @ as wrappers around my regular expression this is just so I can see it more easily with far less escaping required.

So replace the line above which is about line 1345 of the strictly-autotags/strictlyautotags.class.php file.

$content = preg_replace_callback("@(\.[”’\"]?\s*[A-Z][a-z]+\s[a-z])@",
 function ($matches) {
  return strtolower($matches[0]);
 },
$content);

Other people have used this fix for the plugin in the WordPress forum so it should work. I don't use PHP7 yet so never had to deal with it.

However if you are a developer please help others out on the forum. I have had over 223,616 downloads of the free version. If just everyone of those people had donated me £1 then I could spent my whole time working on it but everyone wants everything for free it seems nowadays which is why I have my premium plugin with more features > Strictly AutoTags Premium Plugin Version.

Remember you can also find up to date information on my Facebook page for my Automation plugins, this and the Strictly TweetBOT plugin which go hand in hand.

Also remember there is a Facebook page for thee plugins you can check for help as I don't automatically get notified of new problems on the WordPress site for some reason.

You can find this page at https://www.facebook.com/strictlysoftware/

Remember if you have a bug with any of my plugins to do the following:

1. Check the WordPress forum for similar bugs and fixes https://wordpress.org/support/plugin/strictly-autotags
2. Check the ReadMe file or admin page for any help.
3. Check your PHP and APACHE error logs to ensure it's this plugin causing the issues.
4. Run though the standard debug practises laid out here: Giving useful debug information.
5. Provide as much info to the developer as possible e.g PHP version, WP version, Plugin version, any other installed plugins, when it started failing, was anything else installed near that time, details of your process for tagging.

By Strictly-Software


© 2017 Strictly-Software

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.

Problems Upgrading to IE 8

Upgrading to Internet Explorer 8.0

There are plenty of sites already out there listing all the many bugs or "features" that IE 8 has brought to the table but so far the two main ones I have come across are:


Problems when FirebugLite is also running in IE 8.

I was getting a "Function Expected" error on line 1499 in the IsArray function. As a workaround I added the following line as the first line in the function e.g

IsArray:function(_object){
if(!_object) return false;

This prevents the error but the Firebug-lite console does not display correctly in IE 8 when the document mode is also IE 8. To get round this I set the document mode to IE 7 and then it works fine.

Remember IE 8 now has a console in the developer tools options for outputting custom debug messages plus its now got a great debugger tool with all the same features as Firebug so Firebug-Lite isn't really needed anymore. However it should still be possible to run the two side by side.


Issue with clip and rect function

I also found an "invalid argument" error when setting the clip properties using the rect function. The code was for a scroller and the original version that raised the error was:

this.canvas.style.clip = "rect(0 " + this.canvasWidth + " " + this.canvasHeight + " 0)";

The fix was to add "px" after the dimension values and separate the values with commas e.g

this.canvas.style.clip = "rect(0px, " + parseInt(this.canvasWidth) + "px, " + parseInt(this.canvasHeight) + "px, 0px)";

I have come across a few errors such as "null is null or not an object" (you don't say!) which have been simple fixes and have just required testing the values correctly before using them.

I am sure there are hundreds more errors and that many many hours will be devoted to fixing them all in a similar manner to the last 2 major releases of IE. However overall I am very happy that they seem to have caught up with Firefox and the others and have implemented a pretty decent developer tools section including a great debugger that actually gives you a useful error message for once. Plus I like the fact that the GUI hasn't changed very much in the way that IE 6 to IE 7 did and I do like the little touches like the accelerators.

However its a shame that with such a major release they couldn't have gone the whole hog and sorted their Javascript engine out to make that standards compliant as well as the CSS. Apparently they have rewritten the whole JS engine so now was as good a time as any to bite the bullet and do it and they would have made the whole web development community very happy if they had done so. Even with the rewrite their event model is still pretty shoddy and even if they wanted to keep with their intermediary event model (attachEvent, removeEvent, returnValue, srcElement etc) then they could have fixed those annoying little issues that people have spent thousands of development hours resolving such as the this keyword referring to the window and not the object in question and attaching event listeners in order rather than randomly.

It seems pretty likely that more and more companies will get to the point where developing for IE becomes too much work and stop supporting it. Market share of Firefox, Chrome, Safari and Opera are increasing all the time so it may not be that long until you find a lot of sites just redirecting to a Mozilla download page when you access their site in IE. If that does happen then it might be a shame to some people but Microsoft will only have themselves to blame and may find that they have missed a great opportunity with this release to prevent that from occurring.