michalzubkowicz
commented
5 years ago It's not a fault of of this plugin directly. wp_mkdir_p tries to create directory with path like gs://xxx, what obviously is not possible. You can see in the code that after protocol remove it points to root of filesystem. Worst thing is that wp_upload_dir is executed hundreds of times during processing of template, so every directory is tried to create over and over again.
For us helped a lot using object cache plugin like: https://wordpress.org/plugins/redis-cache/
Without it rendering time makes this plugin unusable.
Second solution is to change definition of function wp_upload_dir to have default false, but I didn't test it much.
In our case finally this problems is caused by WPML, because it's using function wp_upload_dir not wp_get_upload_dir (which doesn't try to create directory)
The 'upload_dir' filter makes it a GCS-path. In the core wp_upload_dir function, the first time in the request it is called wp_mkdir_p checks existence of the folder on the GCS bucket. The subsequent filter calls are taken from cache in the wp_upload_dir function.
Maybe we're doing something wrong, but this first time execution of 'wp_mkdir_p' takes a very long time, 0.8 seconds often, run from a PHP7.1 GAE instance, built with this Google codelabs toturial.
This probably has to do with the StreamWrapper being much slower than the regular filesystem operations. Is this supposed to happen? Or is there any way we can get around this, or cache this check?
Thanks!