Google App Engine Plugin Uploads to Cloud Storage do not work in WP 4.0

[jgrasser2]

We get "Http Error" when uploading media from WordPress to GCS. To be clear, media does get uploaded, but we still receive a 500 status code from the server.

Http response from har File.

"name": "status",
"value": "500 Internal Server Error"

WordPress Version 4.0
Production GAE. Did not test in dev.

The lines that appear to be causing the issue are in /modules/uploads.php, 195-196

$_COOKIE[$auth_cookie_name] = $auth_cookie;
$_COOKIE[LOGGED_IN_COOKIE] = $logged_in_cookie;

If these are changed to the following code, the upload works

if ( !isset($_COOKIE[$auth_cookie_name]) ) $_COOKIE[$auth_cookie_name] = $auth_cookie;
if ( !isset($_COOKIE[LOGGED_IN_COOKIE]) ) $_COOKIE[LOGGED_IN_COOKIE] = $logged_in_cookie;

[Craxic]

I'm also getting this problem (but without the HTTP Error.) Instead, the server just dies and the user sees "An error occurred in the upload. Please try again later.". To shed some more light on the issue, here is why it's failing for me:

1. User logs in and gets a token as part of their cookie (call it "abcd")
2. User goes to upload form and gets a nonce that allows them to upload. This nonce only works for the cookie with the "abcd" token.
3. User sends upload to the wrapped URL.
4. Upload completes, and the wrapped URL then calls the original URL. We then get into the area @jgrasser2 mentioned: (full output of print_r(debug_backtrace(), true) here:

google\appengine\WordPress\Uploads\Uploads::set_fake_cookies(USER_ID)
google\appengine\WordPress\Uploads\Uploads::authenticate()
google\appengine\WordPress\Uploads\Uploads::preauthenticate()
/base/data/home/apps/app-name/instance-name.1234/src/wp-settings.php::do_action('plugins_loaded')
/base/data/home/apps/app-name/instance-name.1234/src/wp-config.php
/base/data/home/apps/app-name/instance-name.1234/src/wp-load.php
/base/data/home/apps/app-name/instance-name.1234/src/wp-admin/async-upload.php 

5. This overwrites the cookie token with a fresh one
6. This causes wp_verify_nonce to fail in async_upload.php -> wp_ajax_upload_attachment -> check_ajax_referer( 'media-form' ) since the token is different.
7. This causes the script to die.

@jgrasser2's solution works great, thanks! (although there's clearly a reason this code is in here, and I'm a bit worried that we're basically just removing it... Perhaps it was only important in the earlier versions of WordPress/GAE.)

Also, another strange thing: The project I'm working on runs two apps: one for development and one for production. The production server does not experience any issue with this specific problem (although it gets strange "time-out" issues... But that's probably unrelated.), but the development server does. I'll be back with more information if I can run some logging on the production server.

[DejaAugustine]

When I first tried to run Wordpress 4.0 on Google Apps Engine, the isset() fix that was patched in worked fine.

However, today even with the isset() fix, I'm back to getting the "HTTP error" and "Are you sure?" messages on Wordpress 4.0, even using version 1.5 of the Google App Engine plugin.

The files are being uploaded (I can browse them on Google Storage) so I don't think it's a permissions issue on the bucket, but it looks like the metadata is missing and obviously the files aren't showing up in the Wordpress backend.

Any ideas what I might be missing?

[Craxic]

@DejaAugustine
I'm not sure what you're missing: all I can do is offer some general advice I guess...

• If you're getting the HTTP Error message, try viewing the network requests in the debug console. Perhaps that might give you some more information.
• Check the App-engine logs obviously for any errors (or requests that aren't giving 200 OK responses)
• If all else fails, you can do what I did: Put a whole lot of syslog() calls throughout async-upload.php to figure out exactly where it fails.

Hope that helps, sorry I can't offer any advice you probably haven't already tried.

[DejaAugustine]

@Craxic
I wonder if it was a problem on the Google API side. Without making any changes or deployments, I tried it a couple hours later and it worked.