Everybody Staze...

Nobody leavz...

You are here: Home / Archives for Wordpress

WordPress doesn’t create thumbnails

By

Imagemagick-logoI had an interesting issue hit my site recently, that I still can’t figure out WHY it happened, but after a few days of troubleshooting, I have figured out what happened, and how to fix it.

First, let me say that my site runs on a Mac Mini running Mavericks (10.9.5). So, all of this MAY come down to some update Apple released recently, I’m really unsure. I also run my site behind Cloudflare, which I also was curious about. It seems to have cropped up on/around the time WordPress 4.2 was released, which is what I thought the issue was at first (and why I was involved in the wordpress.org forum thread here). The issue is basically that WordPress, in my case, wouldn’t generate thumbnails for JPG image uploads, but PNGs would. The issue cropped up right around the time that wordpress 4.2 was released, so the natual causation logic seemed to point to WordPress being the issue. Interestingly, it wasn’t. After banging my head on this for a while, a coworker finally found a note that WordPress defaults to using ImageMagick (imagick.so) for image processing if it’s present, otherwise it uses GD. So, I found a “plugin” that forces WordPress to use GD, and that fixed it. So crap, the issue is my ImageMagick install. The problem is, WordPress is failing silently, and not throwing ANY errors.

So, I added a simple script to test imagick using some code I found on php.net hoping it would actually throw an error. And it did throw an error:

PHP Fatal error: Uncaught exception 'ImagickException' with message 'Wrong JPEG library version: library is 70, caller expects 90

There we go. So, the issue is ImageMagick is being compiled against libjpeg version 9, but when it’s going to run, it’s being handed version 7. So, I was able to do an “mdfind” and see I had version 9 and 8 installed, as well as 7, both in /usr/local/lib, and with my PHP install. So, knowing I installed both 8 and 9, I removed 8 and 9, so only 7 was avaible, and then recompiled ImageMagick, and uninstall and reinstall imagick.so. Then, I ran my test, and it worked!

fail2ban WordPress and Cloudflare

By

Fail2ban_logoLike most people that run a WordPress site, or any CMS, I’ve struggled with brute force attacks on my site. Having just installed fail2ban on a mail server, this seemed like an obvious. Thankfully, as well, someone had already written a plugin for WordPress to drop a message in the system log saying a login failed (by default, Apache doesn’t do this, it just shows someone hit the login page). At first, I had set up an iptables/pf rule to block the bad user, but for some reason, this wasn’t happening. My test browser kept hitting the page successfully.

After a break, I realized that I use Cloudflare, and of course blocking the offending IP wouldn’t work… it never actually connects to my host. Thankfully, Cloudflare has an API, and there was already a starting point for a fail2ban action, albeit, out of date (Cloudflare forces json now). Below is that action. You should be able to just call this like any other action, after you fill out the appropriate “token” and “email”. ((Note: I had to disable “always online” with Cloudflare to have the block take effect within 5-10 seconds. With “always online” enabled, it took about 2-3 minutes to block the attack, all the while the “bot” was able to keep hitting my server.))

Good luck!


# Fail2Ban cloudflare action
#
# Author: Ryan Stasel
#
# $Revision$
#

[Definition]

# Option: actionstart
# Notes.: command executed once at the start of Fail2Ban.
# Values: CMD
#
actionstart =

# Option: actionstop
# Notes.: command executed once at the end of Fail2Ban
# Values: CMD
#
actionstop =

# Option: actioncheck
# Notes.: command executed once before each actionban command
# Values: CMD
#
actioncheck =

# Option: actionban
# Notes.: command executed when banning an IP. Take care that the
# command is executed with Fail2Ban user rights.
# Tags: <ip> IP address
# <failures> number of failures
# <time> unix timestamp of the ban time
# Values: CMD
#
actionban = curl -s https://www.cloudflare.com/api_json.html -d ‘a=ban’ -d ‘key=‘ -d ’email=‘ -d ‘tkn=‘

# Option: actionunban
# Notes.: command executed when unbanning an IP. Take care that the
# command is executed with Fail2Ban user rights.
# Tags: <ip> IP address
# <failures> number of failures
# <time> unix timestamp of the ban time
# Values: CMD
#
actionunban = curl -s https://www.cloudflare.com/api_json.html -d ‘a=nul’ -d ‘key=‘ -d ’email=‘ -d ‘tkn=‘

[Init]

account = YOUR_CLOUDFLARE_EMAIL

token = YOUR_CLOUDFLARE_TOKEN

WordPress _transient buildup

By

WordPress uses DB entries called _transients to cache certain data. Cached entries are by default, things like RSS info, when cron last run, etc. If you use a plugin like Google Analytics Dashboard (GAD hereafter) though, you also get cached data relating to that. Unfortunately, either due to a bug in WordPress, or something left out of GAD, this cached info doesn’t seem to be deleted after it’s designated expiration time/date (_transients have a set expiration time, but they don’t seem to matter for GAD set transients).

Looking around online, I found someone who was dealing with a similar problem here.

The trick was to add the following to my the functions.php file in my theme.


add_action( ‘wp_scheduled_delete’, ‘delete_expired_db_transients’ );

function delete_expired_db_transients() {

global $wpdb, $_wp_using_ext_object_cache;

if( $_wp_using_ext_object_cache )
return;

$time = isset ( $_SERVER[‘REQUEST_TIME’] ) ? (int)$_SERVER[‘REQUEST_TIME’] : time() ;
$expired = $wpdb->get_col( “SELECT option_name FROM {$wpdb->options} WHERE option_name LIKE ‘_transient_timeout%’ AND option_value < {$time};" ); foreach( $expired as $transient ) { $key = str_replace('_transient_timeout_', '', $transient); delete_transient($key); } }

Later in the day, when that cron task ran, it removed all the expired transients from my wp-options table, and at midnight, when my system cron task ran to optimize my DB tables, the table shrunk down to the size it should be. If you so wanted, you could add the optimize operation to the above, but I figure it’s not that big of a deal once things are under control. As always, back up your DB and any files you modify before implementing changes. If you have access to a mysql console, you can also try the query out by doing something like:

SELECT option_name FROM wp_options WHERE option_name LIKE '_transient_timeout%' AND option_value < now();

You'll want to change "wp_options" if you have a different prefix set for wordpress. Theoretically, that query should show you all your expired transients.

Have fun!