aidanlane

Fantastic, thanks Shreyas.

We’ve updated, and look forward to testing it out.

Best regards,
Aidan

Fantastic, thanks Shreyas.

We’ve updated, and look forward to testing it out.

Best regards,
Aidan

I @gravitate, we have the same issue:

Current policy: “Media files attached to a post use the post’s date to determine the folder path they are placed in” [amazon-s3-and-cloudfront/classes/amazon-s3-and-cloudfront.php:559]

Scenario illustrating problem with this policy: Author is editing a post and uploads an image. Author comes back at ANY time in future with their revised image, deletes the old version and uploads the new one… Reader never sees new version of image, as the “attached to” post date used for version and the expiry is set to “Never Expire” / 10 years.

Workaround: filter “as3cf_get_object_version_string” to return current date + time as a string, e.g .in “YmdHis”, as they do.

@bradt should the above policy at least be optional? What’s the rational behind it?
ps. thanks for the plugin! We’re looking forward to the Pro version.

Thanks for that @slangley.

Ah, so I wasn’t the only one affected by this.

Yes, please add an option to override this behaviour.

Many thanks,
Aidan

Note that the “Add Media” for posts is also effected by this issue.

Apologies, @wpyogi, I should have stated that @tuanmh works for me- that is for the same issue on the same project.

I have reduced the code down…

wp-includes/functions.php:

function wp_mkdir_p( $target ) {
	syslog(LOG_INFO, "wp_mkdir_p point A for $target");
	$wrapper = null;

	…

	// Make sure we have an uploads directory.
	syslog(LOG_INFO, "wp_mkdir_p point B for $target");
	if ( file_exists( $target ) ) {
		syslog(LOG_INFO, "wp_mkdir_p point C for $target");
		$is_dir = @is_dir($target);
		syslog(LOG_INFO, "wp_mkdir_p point D for $target");
		return $is_dir;
	}
...

Log output:

I 16:18:40.141 2015-02-04 200 142.71 KB 22427ms /wp-admin/admin-ajax.php
… – – [03/Feb/2015:21:18:40 -0800] “POST /wp-admin/admin-ajax.php HTTP/1.1” 200 146134 – “Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.94 Safari/537.36” “…” ms=22427 cpu_ms=10850 … app_engine_release=1.9.17
I 16:18:18.576 wp_mkdir_p point A for gs://our-bucket
I 16:18:18.576 wp_mkdir_p point B for gs://our-bucket
I 16:18:19.160 wp_mkdir_p point C for gs://our-bucket
I 16:18:19.160 wp_mkdir_p point D for gs://our-bucket
I 16:18:19.195 wp_mkdir_p point A for gs://our-bucket
I 16:18:19.195 wp_mkdir_p point B for gs://our-bucket
I 16:18:19.195 wp_mkdir_p point C for gs://our-bucket
I 16:18:19.195 wp_mkdir_p point D for gs://our-bucket
I 16:18:19.285 wp_mkdir_p point A for gs://our-bucket
I 16:18:19.285 wp_mkdir_p point B for gs://our-bucket
I 16:18:19.595 wp_mkdir_p point C for gs://our-bucket
I 16:18:19.595 wp_mkdir_p point D for gs://our-bucket

Hi,

Is anyone able to help with this?

Here’s some more debugging, which illustrates the problem:

wp-includes/functions.php:

[moderated – that’s too much code to post in these forums – please read the forum guidelines]

Marking as resolved.

Brilliant, thanks again slangley ??

Thanks slangley, you’re an absolute champion!

So would you call that a bug in WordPress?
If so, could you recommend the best way in which to get this pushed upstream so that it doesn’t break again when updating WordPress?
That’d provide a true resolution, because at the moment, I’m scared that it might easily break again.