p14nd4's blog is the best blog ever.

One of the sites I run, Techware Labs, uses WordPress for its CMS. (As an aside, we previously used our own home-grown CMS, which had a variety of benefits, but didn’t provide quite as much flexibility as we wanted. Rather than putting significant effort into rewriting or massively upgrading it, we decided to leave that heavy lifting to the pros.) We began using WP around May, 2009 (v2.7.1), since which point 17 major releases have occurred (and significantly more minor releases). We selected the Multi-Page Toolkit plugin to paginate articles (since WordPress just sticks the entire post on a single page by default), which seemed reasonable at the time—it was relatively popular, and had been updated a few months prior. Unfortunately, that update a few months prior [to early 2009] is the last update the plugin has received at the time of this writing.

A lot can happen in seven-plus years, especially in a popular software project like WordPress, but miraculously this plugin mostly kept working through it all. Mostly, however, isn’t quite the same as entirely, and some people get cranky when one thing goes wrong. (Take the Hindenburg, for example; why doesn’t anyone talk about its 62 successful flights?)

Read more »

As mentioned in my previous post, I’ve been playing with WordPress, vBulletin, vBridge, and some other stuff as part of my work for my other site, TechwareLabs. One of the other plugins I utilize on that site is WP Super Cache, which I discovered was an easier way to accomplish basic static caching instead of trying to jump into the deep end of learning mod_cache, memcache, and other sorts of fancy things for an actual elegant solution.

Unfortunately, these are complicated systems, and vbridge in particular seems slightly less polished than some more widely utilized components (though, in fairness, its user base is considerably smaller than most wordpress plugins).

Read more »

I’m the webmaster (and co-founder) of TechwareLabs, which gives me opportunities to play with some technology, software, and code that I otherwise likely wouldn’t have the motivation (or occasion) to pursue on my own. (This isn’t the main point of the post, but one of the coolest in recent history was using Xdebug profiling in PHP with KCachegrind to debug a performance problem on the live site. Flipped the profiler on for a few seconds, sent a few requests to the server, disabled the profiler, and loaded the output in KCachegrind to immediately get an awesome graphical overview of all the calls made to render the page, and how long they took. I don’t get to use fancy software like that at my day job, so this was very cool to use, and even cooler that it actually helped solve my problem so quickly.)

Anyway, back to the main point of this post! We’re currently working on an integration between the site backend (WordPress) and our forum software (vBulletin). I found a slick plugin for WordPress that’s supposed to accomplish most of this: Complete WordPress/Vbulletin Bridge and a guide explaining that vBulletin’s own utility, ImpEx, already has the ability to import users from WordPress. (Side note: ImpEx is available only to current vBulletin license holders, and can be downloaded from the same page where you can download vBulletin, after logging into the members area on their site. This wasn’t immediately apparent to me from reading that guide.) Woo! I can follow instructions!

Things went pretty smoothly, other than the hiccup I had trying to use the WordPress or WordPress CMS importers in vBulletin ImpEx. I eventually realized I had to click some start over link to get ImpEx to clear my session before I could continue with the BBpress importer, as the guide mentioned above recommended. Things seemed to be working pretty well in my testing, aside from a few pesky PHP errors about headers already being sent on some pages in the WordPress admin control panel, and a few slightly more concerning vBulletin-generated emails about insufficient database connections (yet to be resolved).

The bad news came when someone actually tried to publish a live article, and discovered that the Add media button for uploading images wasn’t working, and was instead presenting an error:

Are you sure you want to do this?

Please try again.

I poked around in media-upload.php, and first noticed that $_GET[‘inline’] wasn’t being defined, so I thought this was the problem. Not so fast! I guess the staff’s been using the NextGEN Gallery Plugin for WordPress, so this does something fancy for the media upload links, so that wasn’t the problem. My google-fu was apparently a little weak, since although I found other people reporting the issue immediately, I had to read through about twenty pages of the plugin thread before I found a solution (which, in retrospect, I wish I would’ve thought to check, myself, earlier).

User ‘skariko’ posted a [possible?] solution for folks having a problem with the WordPress flash-based image uploader, and while this wasn’t exactly what I needed, it was the Eureka! moment I needed to solve it, myself with a few keystrokes of modification. He suggested modifying the following line in vbbridge.php:
[code lang=”php”]#if (basename($_SERVER[‘SCRIPT_NAME’]) == ‘upload.php’) { return; }[/code]
to
[code lang=”php”]if (basename($_SERVER[‘SCRIPT_NAME’]) == ‘async-upload.php’) { return; }[/code]
I’m guessing that async-upload.php is the file that the flash uploader posts to, and for whatever reason needs to be unaffected by the vbbridge code. Anyway, I wasn’t even getting that far, so I just changed it to
[code lang=”php”]if (basename($_SERVER[‘SCRIPT_NAME’]) == ‘media-upload.php’) { return; }[/code]
and everything magically worked!

It turns out that someone else posted this exact same solution on another page of the thread, but I wanted to share it here, too, so maybe someone else in the future can have better luck googling for a solution (or in case I forget how I fixed it, and have to fix it again :-p).