WP_Image_Editor::make_image should call wp_mkdir_p

[batmoo]

To play nicely with some replication plugin, WP_Image_Editor::make_image should make sure that the target folder exists before proceeding with accessing the image.

WordPress does something similar with wp_crop_image and similar functions.

Patch calls wp_mkdir_p at the start of the method.

We can probably do that. Still WP_Image_Editor is a very abstracted class and the default folder is the folder itself.

So you can also see it that the developer should deal with it. Most likely because of you want to call wp_mkdir_p before you even going to load an image. This means that this patch only fixes 50%. What can be good enough.

Put it on the 3.6 milestone for consideration.

btw can you give an example of a plugin. I'm not sure what you mean with replication. Is that image or site based.
Also I'm missing why using that function. Seems like a file system operation without the need of resizing.

Also I'm missing why using that function

WordPress core uses this function :) (Both WP_Image_Editor_GD and WP_Image_Editor_Imagick call the make_image method when a user is editing a file from Dashboard > Media > Edit).

The issue is the similar to the one fixed in [20384]; certain replication plugins (like the one we use on WordPress.com) don't guarantee that a file (or directory, in this case) will be available in the local filesystem and this helps prevent issues because of that.

I meant wp_crop_image(). WP_Image_Editor is what I partly written myself so I do know that code.

My opinion still stands that it shouldn't be dealt inside WP_Image_Editor. Also if you really want to add it you can do that in the custom WP_Image_Editor you probably already have by now.

Still My questions stands in comment 3.

Sorry, I should clarify. I don't have a custom class that extends WP_Image_Editor and my custom code is not interacting with that class anywhere.

I'm running into this problem when editing an image via the "Edit Image" interface in the WordPress Dashboard, i.e. using WordPress core functionality.

Ah so no WordPress.com related thing. I still don't get the issue when editing an image through WordPress dashboard. Since all those images would be saved on the same directory where the main image is stored.

We try to remove assumptions from core that an image file will actually exist in the location where it is supposed to exist. If it does not exist we fetch the image using the url and pretend we loaded it from disk from the expected place. When we go to save it, the directory that contains the file that doesn't really exist often also doesn't exist. This has to do with replication plugins that put files in places like S3 or some other remote image/file store. We must assume that there is no guarantee of local storage consistency from one page load to another.

In 23744:

Make WP_Image_Editor::make_image() safe for replication plugins by making sure the directory for the image being made exists.

Props batmoo
fixes #23306