Behaviour changes in wp_unique_filename()

[tellyworth]

Unit testing picked up two recent changes in wp_unique_filename() behaviour. They might be ok but I thought worth raising as they might affect plugins or l10n.

1. The strtolower() introduced in [7478] mangles non-ascii filename characters on many systems. The locale isn't set so accented characters get converted to something unpredictable. This changes the result of the 'tést-imagé.png' case in test_wp_unique_filename():

expected string <testtest-image.png>
difference      <     xxxxxxxxx>
got string      <testtast-imaga.png>

​http://svn.automattic.com/wordpress-tests/wp-testcase/test_includes_functions.php

2. Leading paths aren't stripped from the filename if present. They were before [7440]. Now, the full path is used with slashes removed (i.e. /path/to/filename.jpg becomes pathtofilename.jpg instead of filename.jpg) test_unique_filename_with_slashes() now fails as a result:

​http://svn.automattic.com/wordpress-tests/wp-testcase/test_includes_file.php

expected string <73bd23e4df5b4cbf9962bb1f4ee8988d.txt>
difference      <                                xxxx????????????????????????????????>
got string      <73bd23e4df5b4cbf9962bb1f4ee8988d73bd23e4df5b4cbf9962bb1f4ee8988d.txt>

It might be reasonable to accept the new behviour - if that's the case I'll update the tests to reflect that. If not, the enclosed patch fixes both issues and restores the previous behaviour. All relevant unit tests pass with the patch applied.

[Denis-de-Bernardy]

marking as dev-feedback to raise this.

please close if it rings no bell.

[ryan]

See #9416.

[Denis-de-Bernardy]

dup/fixed.