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).
