Scott Grant – PHP and Wordpress Consulting

One quick and common way to get debugging information about an application is to introduce some print tracing statements (print spam).  If you run a debug environment as well as a production environment, you can set up a print statement for displaying this information that is defined differently in each of your environments.

I’ve got a configuration file for both dev and prod, and this file is responsible for defining the debugPrint statement.  On dev, it looks like this:

function debugPrint($x) {
if (is_array($x)) {
echo ‘<p>’; print_r($x); echo ‘</p>’;
} else {
echo ‘<p>’ . $x . ‘</p>’;
}
}

And on prod, it looks like this:

function debugPrint($x) {
}

The nice thing about this simple addition is that I can litter questionable code with debug statements, and not worry about debug spam leaking through to production.

For me, the real benefit is being able to do things like this in the production environment:

function debugPrint($x) {
if (is_user_admin()) {
if (is_array($x)) {
echo ‘<p>’; print_r($x); echo ‘</p>’;
} else {
echo ‘<p>’ . $x . ‘</p>’;
}
}
}

Even in the production environment, it can be nice to have this debug information, but only if you’re the type of user who should be reading it.  In this case, administrator users, or programmers, or whomever you’d like, are the only ones who see the debug spam.

For WordPress theme developers, remember that when you need to reference the local theme template directory, the following call will reference the parent theme:

get_template_directory_uri();

Intuitively, you might look at this and say that the child theme is of course the active theme.  This call will actually return the URI of the active parent theme, if you’re using a child.  Use the following call to get the location of your active child theme:

get_stylesheet_directory_uri();

If you want to identify your browser as an iPad when navigating the web, open up your Firefox client and visit about:config in the navigation bar.  Right-click and create a new String entry, then enter the following information:

Preference name: general.useragent.override

Value: Mozilla/5.0 (iPad; U; CPU OS 3_2 like Mac OS X; en-us) AppleWebKit/531.21.10 (KHTML, like Gecko) Version/4.0.4 Mobile/7B334b Safari/531.21.10

I’m a Firebug user, and we’d been seeing some very strange errors in Firefox 4 on a site that was running without any obvious errors.  In the Console tab, the following error was showing up.

Image corrupt or truncated: <unknown>

This is almost as unhelpful as it gets, unfortunately!  All we know is that there’s an image that seems to be causing a problem.  There’s no line information, no offending image reference, and no other clues that help us track things down.

Some other detectives had tracked this down to the favicon.ico, and blamed this on a Firefox 4 error.

http://code.google.com/p/fbug/issues/detail?id=4291

When we opened up the favicon.ico file on its own, sure enough, the error still popped up.  I’m not sure how the original icon was generated, but something was invalid in the actual file.

It’s great that browsers and other applications are error-tolerant.  It can lead to a false sense of stability though, and in this case, the phantom error was appearing even though the image was loading properly.  Once we generated a valid favicon.ico file and replaced the old one, the error disappeared.

If you’ve got the WordPress plugin WP-MEMBER installed on your site and you’re seeing Invalid Data Passed errors when expired users attempt to resubscribe, there is a fix available in the meantime until the developers patch the plugin.  You’ll need to have some background working with a database, and of course, you’re going to want to make a good backup.  You can also contact me if you’re looking for assistance with this problem.

The offending data seems to be the fact that old user accounts have existing Paypal information in the account.  Since WP-MEMBER encrypts all of their plugin source, it’s difficult to go in to see exactly what the problem is.  However, the old Paypal meta-data is still present in the wp_usermeta table, and it appears that the plugin isn’t able to handle it properly for expired users.  Go to the table, and for any user who is expired (wp_usermeta records with the key ‘paypal_status’ will have the value ‘Expired’), remove their ‘paypal_user’ key.

Update: If you are writing a PHP script to automate this, you might do the following.

Get the user id’s from the wp_usermeta table:

$query = “SELECT * FROM `wp_usermeta` WHERE meta_key=’paypal_status’ AND meta_value=’Expired’”;

Take the id values from the results of that query, join them into a comma-separated string (php join function), and remove the old meta-data.

$query = “DELETE FROM `wp_usermeta` WHERE user_id IN ($id_values) AND meta_key IN (‘paypal_user’)”;

One of my clients ran into a problem with their Google Analytics logging system.  There was a Perl script set up by another developer to receive Paypal Payment Data Transfer (PDT) notifications each time a user was billed.  This script would then send a notification to the Analytics tracker to log the successful payment.  One day, it just stopped working.

Handling asynchronous requests can be a bit of a nightmare.  If you miss the callback and you don’t have some sort of logging system set up, that data can just disappear.  Also, if you’re not printing things like “PAYPAL ERROR 500 OMG” to the user (and it’s arguably best not to!), you’ll never know it’s happening until you notice a few weeks later that no more data is being tracked.

We set up some basic logging in the script to take note of what Paypal was telling us.

An Error Occurred: 500 Can’t verify SSL peers without knowning which Certificate Authorities to trust

That’s actually a verbatim error too, so the typo isn’t ours.  It turns out that one of the dependencies in the Perl script had been updated, and that the certificates were no longer valid.

http://cpansearch.perl.org/src/GAAS/libwww-perl-6.00/Changes

For us, the fix included adding the following two lines to the top of the file:

use IO::Socket::SSL;
use Mozilla::CA;

Additionally, we had to install these libraries to a specific location and to specify to our Perl script that the libraries were there.  On Hostgator, we went into the cPanel and installed Mozilla::CA and IO::Socket::SSL, and added the following lines to our script (directory name removed):

BEGIN {
my $base_module_dir = (-d ‘/home/USER_NAME/perl’ ? ‘/home/USER_NAME/perl’ : ( getpwuid($>) )[7] . ‘/perl/’);
unshift @INC, map { $base_module_dir . $_ } @INC;
}

If you’re seeing Error 500 in your Paypal PDT scripts, give this a shot.  And if you think this is happening to you and you need someone to patch it, feel free to contact me!