[wp-trac] [WordPress Trac] #55635: wp_convert_hr_to_bytes() report correct byte sizes for php.ini "shorthand" values
WordPress Trac
noreply at wordpress.org
Thu Apr 28 08:13:15 UTC 2022
#55635: wp_convert_hr_to_bytes() report correct byte sizes for php.ini "shorthand"
values
-------------------------------------------------+-------------------------
Reporter: dmsnell | Owner: (none)
Type: defect (bug) | Status: new
Priority: normal | Milestone: Awaiting
| Review
Component: Upload | Version:
Severity: normal | Resolution:
Keywords: needs-unit-tests has-patch dev- | Focuses:
feedback changes-requested |
-------------------------------------------------+-------------------------
Comment (by pento):
This is a fun patch. 🙂
I think this change should go in a new function, rather than altering the
behaviour of the existing function. While the original intention of
`wp_convert_hr_to_bytes()` was for quickly parsing PHP INI values, I
suspect that it's often used for converting any "human readable" sizes to
their integer equivalent
([https://plugins.trac.wordpress.org/browser/backupwordpress/trunk/functions/core.php#L447
example]).
I would argue that `wp_convert_hr_to_bytes('1MB')` is a reasonable usage
of the function, and returns the expected (if technically incorrect)
value, particularly when comparing it to the behaviour of the
corresponding `wp_convert_bytes_to_hr()` function (since deprecated in
favour of `size_format()`, but still relevant).
One other note, the function should support `-1` (as an integer, not a
string), as this is
[https://core.trac.wordpress.org/browser/trunk/tests/phpunit/includes/bootstrap.php#L230
commonly used] for the `WP_MEMORY_LIMIT`/`WP_MAX_MEMORY_LIMIT` constants.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/55635#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list