[wp-trac] [WordPress Trac] #39476: wp_delete_file filter expects both absolute and relative paths

[WordPress Trac]

#39476: wp_delete_file filter expects both absolute and relative paths
--------------------------+------------------
 Reporter:  rmccue        |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  4.8
Component:  Media         |     Version:  4.2
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:
--------------------------+------------------

Comment (by gitlost):

 Of the 3 branches, only the last `$backup_sizes` gives a relative path to
 the `wp_delete_file` filter, as the other 2, `$meta['thumb']` and
 `$meta['sizes']`, do a `str_replace()` on the absolute path `$file`, so
 the `path_join()` with `$uploadpath['basedir']` is always a no-op (except
 when it messes up).

 So the behavioural change would only be for the backup sizes.

 I think it would make sense to make all 3 cases the same basic code,
 avoiding the non-semantic `str_replace()`/`basename()` combo by using
 `dirname()` instead, which would also fix the UTF-8 issue #33227.

 The following patch does this, with unit tests for backup
 sizes/`wp_delete_file` filter and the #33227 UTF-8 case, and some cleaning
 up of other tests.

 (I looked at the reasonably recently updated plugins in those listed above

  polylang, post-thumbnail-editor, geodirectory, upload-to-ftp, editor-by-
 mintboard, file-gallery, mapify-lite-google-maps-plus, xili-language,
 foogallery, conoha-object-sync

 and only `mapify-lite-google-maps-plus` and `foogallery`, which both use
 the no longer maintained https://github.com/humanmade/WPThumb, were
 expecting a relative path.)

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