The .1 update that many people said they were waiting for is here. (And there are reminders all over every admin page on my blog, too.)
Version 2.5.1 of WordPress is now available. It includes a number of bug fixes, performance enhancements, and one very important security fix. We recommend everyone update immediately, particularly if your blog has open registration. The vulnerability is not public but it will be shortly.
The notice also mentioned the SECRET_KEY thing that I talked about yesterday and gave a link to auto-generate the line for wp-config.php:
Since 2.5 your wp-config.php file allows a new constant called SECRET_KEY which basically is meant to introduce a little permanent randomness into the cryptographic functions used for cookies in WordPress. You can visit this link we set up to get a unique secret key for your config file. (It’s unique and random on every page load.) Having this line in your config file helps secure your blog.
Upgrading took me about 15 seconds (as usual), mostly to find the svn command in the codex again and then a few seconds to run it and a few seconds in hitting the “database upgrade” page on the site before things were all done.
I’ve gotten into the habit of actually reading the various blogs to which there are links on my WordPress dashboard and I saw this today from boren.nu:
To make cookies secure against attacks where someone has managed to get into your database through an SQL injection exploit or other means, WordPress 2.5 introduced a user-definable constant called SECRET_KEY. If you look at the sample wp-config.php shipped with 2.5, you’ll see these lines.
// Change SECRET_KEY to a unique phrase. You won’t have to remember it later,
// so make it long and complicated. You can visit https://www.grc.com/passwords
.htm
// to get a phrase generated for you, or just make something up.
define(’SECRET_KEY’, ‘put your unique phrase here’); // Change this to a unique phrase
If you upgraded from a previous version of WordPress you probably won’t have these lines in your wp-config.php.
That last bit is, of course, the critical thing for me and had me going back and inserting SECRET_KEYs into all my older/upgraded WordPress installs. Just remember that if you’re integrating with bbPress, you have to match the SECRET_KEYs in wp-config.php and bb-config.php.
Scribblit => Inksome (but scribblit.com still works… for now? until May 10 [updated based on comment below])
CommieJournal to close May 1 unless they raise the money to cover $169/month hosting bill. (If they cover this month’s bill, will the date just become June 1? I don’t know.)
¶
Posted 22 April 2008
† 2718.us §
LJ-Stat
‡
°
Tagged: cj, clone, commiejournal, inksome, livejournal, lj, lj clone, lj code, LJ-Stat, scribblit, stat, stats
I not only wanted to integrate my own other things into my WordPress-based site, but I wanted forums, too, so of course I thought of bbPress. It seems to integrate well with WordPress, but then suddenly strange things started happening with login and logout. For instance, when I logged in with bbPress, I couldn’t get WordPress to log me out and my integrated site didn’t work.
Ah-ha! A cookie problem–while I’d set the cookie domain for WordPress to allow subdomains to work, bbPress didn’t know about WordPress’s cookie settings, so bbPress didn’t set the right cookie domain. Worse, this meant that the cookie didn’t quite match up to what WordPress expected, so logging out in WordPress tried to blank a cookie that wasn’t set, not the login cookie set by bbPress. The fix is to add something like
$bb->cookiedomain = '.yoursite.com';
to bb-config.php (that is, match what you’ve set in WordPress). Not the most obvious way to set an option, but it works.
¶
Posted 20 April 2008
† 2718.us §
Web Programming
‡
°
Tagged: authentication, bbpress, cookie, cookie domain, cookies, domain, integration, login, user, user authentication, wordpress, wordpress 2.5, wordpress login, wp, wp2.5
If, like me, you find yourself doing lots of random web stuff, particularly with all the HTML, CSS, MySQL, and PHP that go along with it, you may find yourself looking for a good reference book so you can quickly check the syntax of that one thing you only use like once a year and for which you can never remember the order of the arguments. For a longtime, for me, this meant that I programmed with a whole separate browser window on a separate monitor devoted just to having up the reference manuals for PHP and MySQL as well as the W3C pages giving the full specs on HTML and CSS, all in whatever versions I happened to be using that day. It worked, but not well. (Which is to say, it worked well enough that I haven’t spent the $10-$20 for a nutshell pocket reference guide in a few years, but I’d still look at them every time I was in a bookstore and think about buying them.)
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.
¶
Posted 17 April 2008
† 2718.us §
Web Programming
‡
°
Tagged: bob stein, browser book, card, css, guide, html, manual, mysql, php, reference, reference card, syntax, visibone
After implementing other pages that used WordPress to authenticate users and deal with access control, I went to move these pages off to a subdomain, and suddenly found that auth_redirect wasn’t quite working right. When auth_redirect is called and doesn’t find a logged-in user, it redirects to login and passes the URI of the current page… well sort of. It passes the request string, but it ignores the server part. So, when the login page is done and tries to redirect, it’s going back to the main WordPress server, not the subdomain. Fortunately, auth_redirect is a very simple function to duplicate and it is designated as pluggable–that is, a plugin can be used to redefine auth_redirect, so I’ve now got a plugin that overrides auth_redirect() with auth_redirect($use_current_host = FALSE) so that if I want auth_redirect to pay attention to the host, I call auth_redirect(TRUE).
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.
¶
Posted 16 April 2008
† 2718.us §
Web Programming
‡
°
Tagged: 2.5, authentication, auth_redirect, filter, filter hook, login, php, pluggable, plugin, user, user authentication, user login, wordpress, wordpress 2.5, wp, wp plugin, wp2.5, wp_redirect, wp_safe_redirect
Since I’ve already hit on SQL injection issues twice in the past two days (here directly and here indirectly through the non-issue with WP and SQL injection), why not add a cartoon to the mix… 
Right, of course, I should be doing this already, but having magic quotes in PHP4 may hvae made me a bit lazy in some instances, and just like I’ve been going through and fixing register_globals dependence… As I read here,
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.
5 minutes is a long time for upgrading WP, as far as I’m concerned. I think it might have taken 5 minutes total to upgrade all three of my current WP installs and check/fix plugin issues. Mind you, I use the subversion method of upgrading. If you have shell access and can run subversion, it is so incredibly easy to upgrade WP with it that I don’t ever want to go back to the download-unzip-upload stuff I used to do. In a post I referenced earlier, Matt said:
Upgrade your blog to the latest WP. This shouldn’t be hard. There are plugins for it, if you’re techy use Subversion, there is the standard FTP method, and finally Media Temple, Dreamhost, and Bluehost (through SimpleScripts) all have been pretty good about having their one-click upgrade systems ready with new versions within a day or two of a release.
I’m techy, sure, but I don’t know much about subversion other than it seems to have replaced CVS and I didn’t know much of anything about CVS other than that people working on big OSS projects seemed to use it. (Okay, I know a little more about what subversion and CVS are supposed to do, but I’ve never actually used a check-in/check-out/versioning system.) I literally just installed subversion with the package manager on my system, then used the commands given in the WP Codex. Not very techy-like. Done.
