One of the things that took the most work to get right was the thickness of the graph lines.  Because of the nature of the graphs, it was an absolute necessity that the lines be drawn with antialiasing enabled.  PHP’s interface to GD (or perhaps it’s GD itself?) ignores the line thickness setting when antialiasing is enabled.  The solution I eventually settled on is to, more or less, draw several one-pixel-wide lines next to and on top of one another to get the appearance of a thicker line.

As an aside, I’m using the technique mentioned here for permanently redirecting the old URL to the new URL:

… if you actually moved something to a new location (forever) use:

<?php
 header("HTTP/1.1 301 Moved Permanently");
 header("Location: http://example.org/foo");
?>

… it is strongly recommended for the PHP developers to add more secure random number functions to the PHP core and it is strongly recommended for PHP application developers to keep their fingers away from srand() or mt_srand() and to never ever use rand() or mt_rand() for cryptographic secrets.

It sounds like the PRNGs in PHP, mt_rand() and rand(), shouldn’t be used for anything security-related, and perhaps /dev/random or /dev/srandom or some such should be used instead (though this is much more system-dependent).

Then I discovered Bob Stein and VisiBone.  For months now, I’ve had the card collection and MySQL cards.  I’ve still had to have the PHP manual up.  That is, until now, with the new PHP products.  With luck, I should have my PHP+MySQL book by the beginning of next week (since he’s updated the MySQL cards since I bought mine, but the card collection is still up to date, so I didn’t get the everything book).  I keep trying to put my VisiBone reference stuff away, since it’s always out in the middle of my desk, but it never stays put away even for a day before I find myself pulling it out to use again.

This is all fine and good, but still doesn’t quite work, since WordPress is smart and won’t just redirect anywhere willy-nilly.  It will only redirect to authorized-for-redirecting servers (wp_safe_redirect, which doesn’t have any documentation in the Codex).  Though undocumented (or at least not well documented in the Codex), the way the authorized host list is handled allows for a plugin to add a filter hook that modifies the allowed list (since the allowed list by default only includes the actual WordPress server name and isn’t exposed as an option/setting anywhere).  Toss that hook into my plugin, add on a settings page to allow the admin to input a comma-separated list of allowed-for-redirecting hosts, and now I can use WordPress to authenticate users on subdomains.

If anyone is interested in this plugin, please let me know and I’ll try to clean it up engouh to make it public.

Both register_globals and Magic Quotes were implemented in PHP to help beginners who were learning to program in PHP or new to programming in general. One thing I noticed about the upgrade was that neither of the problems I encountered were major, but also that they weren’t related to the actual upgrade to version 5, as they both should have been taken care of already. It brings up the discussion of a good programmer versus a bad/lazy programmer. Most of the sites that had any issues, and the few that had major issues were ones that I had taken over and was hosting but didn’t initially create. The sites were not built so long ago that there was an excuse for using both register_globals and magic quotes, and it shows that having programming standards is important, and that keeping up to date with programming trends and upgrades to the programming language are very important. I’m glad I caught this before I upgraded to verion 6 when I possibly would have had a much harder time solving the problem.

It’s a fairly straight-forward process.  At its simplest:

Including wp-config.php (you may have to watch the path) gets you just about all of WordPress and auth_redirect() will check if the user is logged in to WordPress and if not, they get bounced to a login form.

Where things get trickier is if you want to use the authentication on a subdomain (you have to tweak COOKIE_DOMAIN in wp-config.php [to override what’s already in wp-settings.php) or if your blog is in a subdirectory and you want the authentication outside that subdirectory (try tweaking COOKIEPATH).

Oh, and if you try to put the require_once() statement inside a function, you will also need

global $wpdb;

or nothing will work.

The issue of how much memory it consumes to load all of WordPress just to authenticate users is a whole separate issue.

Now, what I didn’t know when I did the upgrade was that php5 defaults to having register_globals off.  This is a very good thing.  I’ve been working hard for the past year to make sure any code I was working on didn’t rely on register_globals.  What I didn’t do however, was make sure that any code that was already in use on my server didn’t need register_globals.  This led to a weekend of digging through server error logs to find the scripts that needed to be fixed (if they could easily be fixed) or patch specific chunks of code wholesale by forcing register_globals on in .htaccess.

Lately, though, I’ve been playing with objects/classes.  I like the changes in the object/class stuff in php5 (even though I’m very oldskool and OOP still feels very strange to me, I keep trying to make OOP stuff work).  Komodo Edit, however, doesn’t seem to like it when I use php5 things like protected and private functions and variables.  I suspect this is because my macs have php4 somewhere and Komodo Edit is using the actual php executable to run syntax checks.  I haven’t yet found an easy way to deal with this, since I don’t want to just install php5 over the php4 that’s part of the base OS X install.