php-docs-samples
php-docs-samples copied to clipboard
Media Upload doesn't work when Wordpress is installed in a subdirectory.
If Wordpress is in a subdirectory instead of in the root; e.g. www.foo.com/blog/ instead of www.foo.com, then all attempts to upload media to GCS will fail with 403 errors due to a problem in the cookie path.
The fix is to add this line to wp-config.php:
define('COOKIEPATH', '/');
The setup script should notice if Wordpress is being installed in a subdirectory and, if so, add this line. Or perhaps it can be added unconditionally. I haven't tried this on a Wordpress install in the root directory.
Is this for App Engine standard?
I discovered it on standard. I haven't tested on flex. May or may not be true there.
Since there's a workaround, maybe we can add the workaround in the README. Does it work for you?
Please, how can I make my Wordpress to upload media files to my Storage bucket? I tried putting bucket URL on database wp_options > upload_url_path and allowed read/write permission to allUsers on bucket. Wordpress can read images and page loading is very fast. But Wordpress can't upload images (error 404 when uploading). Wordpress is installed on Compute Engine instance in same project as Storage bucket. Storage API enabled on VM. Please can someone help me with a simple tutorial?
Best regards!
@ericleonardo Try https://wordpress.org/plugins/wp-stateless/
@tmatsuo I tried it, but don't want it functioning when loading pages as read redirect. Would like to use it only when uploading. Putting direct bucket URL on wp_options > upload_url_path database makes my Wordpress pages load faster. Tried to nullify the WP-Stateless reading function with no success. Also tried its Backup mode but images was uploaded to both local and to Storage, this would increase I/O costs on Google Cloud. My question on WP-Stateless github https://github.com/wpCloud/wp-stateless/issues/175 My site: hotsale.com.br Thanks!
@elharo Please, can you tell me how did you make Wordpress to upload media files to Storage bucket? I just put Storage bucket URL on wp_options > upload_url_path database but is returning 404 error. Reading works perfectly. My site: hotsale.com.br
@ericleonardo Just to confirm, are you hosting your site on App Engine Standard using the instructions here on Github?
I did this twice. The first time image uploads just worked. The second time it failed because the site was in a subdirectory and I had to add the line at the top of this thread to my wp-config.php.
That said, it recently stopped working again for no obvious reason. I haven't had time to debug that yet.
@elharo My Wordpress is hosted on Compute Engine VM instance, there I enabled the Storage API. And in Storage, I enabled read/write permission to allUser. Is your method restrict to App Engine?
I've only tried on App Engine Standard. Compute Engine is a very different environment. Nothing described here should be assumed/expected to work there.
OTOH GCE is basically a Linux box in the cloud so anything that works on Linux should work there (which is not true on App Engine).
Understood... Thank you all anyway!
WordPress requires writable directory to store uploaded file. Should work regardless if the installation runs in web server root folder or a sub folder as long your config is set up ok. If you run default installer process PHP process is able to write to wp-content/uploads/ folder it should work out of the box. There are several plugins available that can instantly move uploaded files to cloud storage and update WordPress database media URLs. This way you can run WordPress in a cluster.
And image uploads are working again, with no changes on my part. Weird.
@tmatsuo We can add the workaround in the README as a quick intermediate step. However longterm this really should be part of the installer script.
@elharo and @tmatsuo — is there anything that still needs to be done here to follow up? I see a suggestion to update the README and/or change the installer script. Does this still need to be done?
Most likely yes. As far as I know, this bug has not been addressed.