Strix technica
Forum Replies Created
-
Right. We also use ‘New Blog Templates’, but that one wasn’t updated in this case. Looking at the code for this filter in NBT (as it now is), it appears to be maintaining the type (array) for $all so, for both reasons, it probably isn’t that.
I don’t have the time right now to isolate which particular plugin it is that’s causing the problem (and since the fault generates a 500 error, it will be a very tedious process unless I hack User Switching to check for false and log the case to prevent it), but if/when I do find an answer, I’ll let you know, as well as notify the plugin author. It’s possible, of course, that the problem has already been fixed in the interim.
Forum: Plugins
In reply to: [Post Type Switcher] Saving Draft… not completing in WordPress 3.9Ah excellent, thanks for the update.
(I guess /me is enough of a dinosaur not to use twitter… or even think of it as a means to contact authors!)
Forum: Plugins
In reply to: [Post Type Switcher] Saving Draft… not completing in WordPress 3.9We’re seeing the same problem. I haven’t tried bobbingwide’s fix (rather, we simply disabled the plugin) — so far so good.
We’re still running v1.2 of the plugin (since autoupdate doesn’t appear to have noticed that 1.2.1 has been released) but it probably wouldn’t help anyway, because the only difference between 1.2 and 1.2.1 appears to be some CSS.
Would the Author please comment?
Hi Ronald,
An unfortunate series of coincidences resulted in several changes being made in close proximity to one another, beginning with the setting of FORCE_SSL_ADMIN. A day later, WP 3.6 was released and our primary WordPress admin (neither Victor nor I, we are primarily responsible for maintenance of the server itself) upgraded to it for the sake of security.
When trying to diagnose the AEC problem, a restore of the WP 3.5.2 version of the site seemed to indicate no problem (but FORCE_SSL_ADMIN wasn’t set back then), and a test install of WP 3.6 (in which I set FORCE_SSL_ADMIN as a matter of course, without even thinking about it — seems foolish in retrospect, but oh well) and AEC showed the problem. Between them, it appeared it was a WP 3.6 problem.
We’ve found that with FORCE_SSL_ADMIN, WP 3.6 and AEC 5.0.28, AEC works okay when the https:// version of the page is manually loaded.
I <i>think</i> what’s going on is that, when FORCE_SSL_ADMIN is set, the auth cookies are set to be returned only over secured HTTP (which makes complete sense). Without those auth cookies, fetching of the comment evidently is broken. By switching to the secured page, everything is automatically HTTPS, and therefore it works.
We’d rather not turn off SSL (for obvious reasons and, anyway, now that the SSL version of the site is in our readers’ browser histories, that won’t necessarily solve the problem), and I’d rather not force the whole site onto SSL because, amongst other reasons, of server load.
It would seem that the simplest solution (for anybody using AEC in conjunction with FORCE_SSL_ADMIN) would be to get AEC to submit use https for all of its AJAX requests when that symbol is defined. I’d do it myself but I’m a sys-admin, and not particularly knowledgeable about PHP, JS and AJAX.
A self-signed certificate would do for testing or, if getting that organised is not convenient on your own servers and you’re prepared to switch to email, I’ll what I can provide by way of testing platform.