Protected: Oliver Luxury Real Estate SEO

This post is password protected. To view it please enter your password below:


Protected: Davis Yoder Group

This post is password protected. To view it please enter your password below:


The Trouble with amazonaws.com

Since implementing scanning procedures to search and destroy the elusive picscout bot I have noticed other activity which I believe is related. My logs show a great deal of activity from IPs tracing back to amazonaws.com that are direct requests for information that does not exist, nor would any reasonably informed search bot issue such a query.

My guess is that the amazonaws.com legal department is on a search mission for Apple related images and applications. The search is on for apple-touch-icon.png, /m, /mobile, /mobi, /iphone, & /pda.

What’s next? Are they going to search my BlackBerry for iPhone apps?

This type of behavior is unacceptable. The notion that the legal department of amazonaws.com believes that they have the right to search anyone’s server without any type of cause is simply un-American.

It’s this type of behavior I’ll block from my server in an instant.

WordPress Plugin Automatic Upgrade Patch

Webmasters running WordPress on a UNIX flavor server running Apache2 may have noticed that when you attempt to use the automatic upgrade option on your plugins page of the Dashboard, that you are prompted for a FTP login.

Rather than conjour up a FTP account you can patch one of your WordPress administration files to get the upgrade option to work. The patch suggested by rootninja modifies the function get_filesystem_method() found in wp-admin/includes/file.php by replacing the call to mygetuid() with a call to posix_getuid().

if( ! $method && function_exists(‘getmyuid’) && function_exists(‘fileowner’) ){

if ( getmyuid() == fileowner($temp_file_name) )

becomes

if( ! $method && function_exists(‘posix_getuid’) && function_exists(‘fileowner’) ){

if ( posix_getuid() == fileowner($temp_file_name) )

Of course, your webserver will need rw permissions to your plugin directory.

Thank you rootninja, I was getting a bit tired of manual installations and I agree, FTP blah.

Wordpress Blank Screen of Death

As I was running tests on all of the Wordpress enabled websites I maintain, to verify that the recent PHP & WordPress upgrades were working I ran across a puzzling problem. One of my website’s blog displayed nothing but a white screen. After pouring over every log file I could find I discovered there was nothing to find. The only error message generated by these white screens was an httpd error 500!

So I went off to google foo to see what I could find. Turns out, this seems to be quite the problem in the WordPress world. It also seems that there are many, many theories and proposed solutions to what is called the “WordPress Blank Screen of Death“.

While I did foo some good advise, most of it I had already explored in several hours of debug work.  The most likely cause, since this problem reared it’s ugly head after my PHP upgrades, was a misbehaving plugin. But which one? And how do you disable a plugin when you can’t even get to your dashboard?

The trick was found by examining the database(s). In the options table there is a tuple enumerating the plugins in use. After verifying that this was the sole definition, clearing out the plugin attribute in the tuple cleared the problem.

And after a bit of testing I found the offending plugin:

  • WP-EMail Widget Version 2.40

Fatal error: Cannot redeclare widget_email_init() (previously declared in /usr/local/www/data/wordpress/wp-content/plugins/wp-email/wp-email.php:1400) in /usr/local/www/data/wordpress/wp-content/plugins/wp-email/wp-email-widget.php on line 102

Apparently this plugin was discontinued in WP-EMail 2.5. You will need to completely remove the plugin before upgrading to get rid of the php file for the widget.

After reviewing the updates of some of Lester’s other plugins it appears that his updates are all implemented differently. You will need to completely review any and all of these plugins to ensure that the old versions are deleted.

And finally a word on WordPress best practices upgrade procedures which call for de-activating all plugins prior to the upgrade. If you are running multiple sites, this is an unwieldy procedure. It is far easier to make sure all plugins have been upgraded to their latest versions and then take the failures up on a case by case basis.

It would be a great help, if when upgrades are detected during subsequent accesses to each website, that not only a database update is preformed, but a check or a reinstall is run on each of the plugins deployed for the site. This notion of a “Wordpress Blank Screen of Death” is comical at best.

PHP extensions.ini updated

The recent PHP update left the extensions.ini file sorted. Unfortunately some  of the extensions contain dependencies that result in undeclared forward references. The .ini file was reordered to accommodate the build deficiency.

PHP Warning:  PHP Startup: Unable to load dynamic library ‘/usr/local/lib/php/20060613/mysqli.so’ – /\
usr/local/lib/php/20060613/mysqli.so: Undefined symbol “spl_ce_RuntimeException” in Unknown on line 0

PHP Startup: Unable to load dynamic library ‘/usr/local/lib/php/20060613/soap.so’ – /us\
r/local/lib/php/20060613/soap.so: Undefined symbol “ps_globals” in Unknown on line 0

In addition, jpeg-7 was rebuilt.

PHP Startup: Unable to load dynamic library ‘/usr/local/lib/php/20060613/gd.so’ – Share\
d object "libjpeg.so.9" not found, required by "gd.so" in Unknown on line 0

Copyright © 1994 - 2010 Gossamer Web Design Lake Tahoe
Gossamer Computer Services, LLC
(530) 583-7989
135 Alpine Meadows Road, #22
PO Box 3433
Olympic Valley, CA 96146