REST API: Improved media titles when created from filename

[iCaleb]

Issue first discovered here: ​https://github.com/WordPress/gutenberg/issues/8902. It's very similar to this previous core ticket #37989

When you upload an image via the REST API, the image's automatically created title attribute is sub-optimal. As an example, if you upload image name.png through the REST API - the title will become image-name. If you do the same through WP core's media gallery though, the image title will be image name. More explanation on this in the above two tickets.

To get the rest api's behavior more inline with the rest of WP core, syncing up WP_REST_Attachments_Controller::create_item media_handle_upload() with media_handle_upload() seems like the best option.

I've attached a patch doing just this, however as a disclaimer, I'm fairly unfamiliar with the process of uploading an image via raw POST data - so I've just kind of left that path untouched and it will act the same as it currently does. Also, as an added benefit to making titles more friendly by default, using wp_basename() is i18n friendly.

Some concerns off the top of my head:

1. Will pathinfo() in this scenario always be okay? It is used in media_handle_upload() but not in media_handle_sideload() where the regex is used instead to remove the extension.
2. Are there cases where the "name" index in $files['file']['name'] won't be available when uploading a file?
3. Any ideas to make the image title more friendly when going through the raw POST data path of the conditional?

[dryanpress]

I've been testing this patch this morning.. wasn't immediately clear Gutenberg had been shim'd to alter this behavior, so I spun wheels trying to/being unable to recreate via Gutenberg 🤦‍♂️

Anyways, started to work through unit tests but brief update (I'll upload a new patch when complete):

• Within else condition, passed $file param to basename() needs to be

  $file['file']
  

  based on returned associative keys from wp_handle_sideload().
• Still tracing origin, but $this->upload_from_data is returning a WP_Error instead of array after changing to $filefile?

[danielbachhuber]

Given the ​timeline for shipping 5.0, it's unlikely this particular enhancement will make it for this release. We can consider it for a future release when there's a patch with tests to consider.

[abitofmind]

Duplicate of #57957.

[abitofmind]

In #57957 there is already a fix for this. But the unit tests for the fix are still outstanding.

So there is some hope this will get resolved.

[abitofmind]

Anyone willing to fix the unit tests could expedite this! Help appreciated! Am no dev myself.