Plus hair tearing. Cussing. Going away from it and getting sleep. And some things you don’t learn from an Hour of Code. There is not heaps of science in my computing.
I got a (polite) email request for help from Brian Lamb. He was seeing (and confirmed) error reports from the TRU Writer SPLOT, on the very trubox domain the things were hatched.
A definitive but not very descriptive error message.
Brian had does some useful things in reporting the problem- showing the error message, identifying that it occurs under different conditions (logged in as admin us a public user), and mentioning a change in the system.
I can upload images when I am logged in under my own account, but when I try to upload an image via the SPLOT interface I get a range of upload errors.
The one most significant change I can think of is we recently moved to SSL on Trubox.
My first step (after the internal “Oh shit”) was to replicate the issue on the TRU site. Yup. I got the same. Opened the Chrome console and did not see any JavaScript thrown errors.
The next step is to try and further isolate conditions. I’m working on my own site using SPLOTs on preparation for my upcoming workshops (selfishly I would like to know they work), and I have installed a WordPress mullti-site under an SSL domain, at https://cog/dog/roo. I quickly put together a TRU Writer spot on my own domain, and checked it as a guest user… the upload worked.
So I replied to Brian and Troy Welch, suggesting maybe it was a server issue, as I had it working.
But later I had to retract that diagnosis. I installed a second SPLOT, the TRU Collector on my domain– and I was getting that same error.
Damn.
Now I was stumped. And worried. Not only for my stuff, but knowing how many sites they have at TRU running on SPLOTty things. What if there was something wrong with the way I had designed things (it involves invisible logging in as a WordPress user, allowing access to upload media to the library without exposing the WordPress dashboard). Was my duct tape unraveling?
I looked in the error logs on my own server and so no PHP bombs on this domain (I did see however how frequent the bot barrage is on attempts to log in to WordPress sites, it’s insane, it’s war.).
So I went into search mode. I did a google search on the error message itself
Sometimes one does get lucky, often not, but in between the extremes, I often find myself closer to an answer. Not much helped, I saw the usual suggestions for checking for plugin conflict (tried that, nope). I
But this post from Sebastian Expert did push my some in a direction.
He suggested instead of the error messages in the browser developer tools. to look at the Network tab, and in particular, the results for HTTP responses from async_upload.php a piece of WordPress called when it executes AJAX type requests for things like the media loaded.
I did not see any error messages in th JSON responses as Sebastian suggested, but did not on the problem sites that this request resulted in an HTTP response code 302 an error code. This was something.
This 302 is not cool. I have no idea why it;s hear, but it means the transaction is not happening
On the site where it worked, the HTTP response code was a good, green 200.
More searching now on wordpress async-upload.php 302 got me circling, but not finding an exact solution. I started thinking I might have to rebuild my site in a non SSL domain, which did not really help with the problem.
I decided after midnight last night to let it go and sleep on it. Sometimes giving up for sleep helps.
I woke up worried how much time I was going to spend trying to fix this, especially with how much other prep is looming. This StackExchange thread felt closer to the problem, espcially:
xThe issue seems conflict with another plugin or function that is trying to prevent non logged in or non admin users access to the wp-admin area so it is redirecting from wp-admin/admin-ajax.php and giving you 302 response.
Try deactivate each plugin one by one and check the issue.
That seemed possible, but in the SPLOTs the guest is secretly logged in as an Author user, and uploading media does not need access to the dashboard. I reviewed my code and saw there this was happening via the wp_signon command, it creates the login info stored in the array called $cred:
$autologin_user = wp_signon( $creds, false );
I then remembered an issue someone wrote me about last year using the TRU Writer SPLOT on SSL, and I messed around a bit with that second parameter, which is typically not needed but is listed as $secure_cookie. I read a bit more and had a hunch of I sent it a true value for SSL… it just might work. I even got clever by just replacing false in the line with 8 other characters– is_ssl() returns true if running on an SSL enabled site, false otherwise
$autologin_user = wp_signon( $creds, is_ssl() );
I tested on my domain’s test site for TRU Collector.
Woah, it now worked. I looked at the code on my TRU Writer site which was working on my domain, but not TRU. The reason it worked was I had some longer code last year to set that value on an SSL site (TRU must be running an older version of the theme, guys you gotta update).
I then tried it non SSL multi-site versions, the ones on splot.ca — and it worked fine.
Then I did something maybe not totally kosher, editing on a production server… I logged in to TRU Box and direct edited the themes (that’s my only access).
It worked there!
the hunt is over — unicorn with a mustache : painting, scott richard, castro, san francisco (2014) flickr photo by torbakhopper shared under a Creative Commons (BY-ND) license
All of a sudden the skies parted, and rainbow colored unicorns started singing Ozzie Osbourne songs. Well in my head.
If you use either of these SPLOTS, the GitHub versions for the TRU Writer and for the TRU Collector have been fixed. I wonder if most people who get these working are using the first versions they downloaded.
As I am myself using them, expect a lot of fixes and cleanups. My policy and I have been 100% so far, is that any updates, new features aded will not break any previous versions. As far as I know, I’m still on pace there. Get yer newest splot code!
I know a fair bit about WordPress, but far from top to bottom. It’s rather vast. But there’s more to it than knowing the commands or all the dashboard screens or what you can get from a bunch of online videos. And while you can Get Google Lucky you can’t always find solutions by tossing stuff into the search bar.
It takes some amount of code base, some web search, some hunches, some luck, and sometimes just giving it and getting a night’s sleep.
But for now, the SPLOTs are not SPLATTED.
At least today.
Featured Image: Enlightment Photography shared under a Creative Commons (BY-ND) license
