[wp-trac] [WordPress Trac] #44789: REST API: Improved media titles when created from filename

WordPress Trac noreply at wordpress.org
Tue Aug 14 23:55:18 UTC 2018


#44789: REST API: Improved media titles when created from filename
----------------------------------------+-----------------------
 Reporter:  iCaleb                      |       Owner:  (none)
     Type:  defect (bug)                |      Status:  new
 Priority:  normal                      |   Milestone:  4.9.9
Component:  REST API                    |     Version:  trunk
 Severity:  normal                      |  Resolution:
 Keywords:  has-patch needs-unit-tests  |     Focuses:  rest-api
----------------------------------------+-----------------------
Changes (by SergeyBiryukov):

 * keywords:   => has-patch needs-unit-tests
 * milestone:  Awaiting Review => 4.9.9


Old description:

> Issue first discovered here:
> https://github.com/WordPress/gutenberg/issues/8902. It's very similar to
> this previous core ticket https://core.trac.wordpress.org/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?

New description:

 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?

--

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/44789#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list