WordPress.org
Get WordPress

Make WordPress Core

Changes between Initial Version and Version 1 of Ticket #55635


Ignore:
Timestamp:
04/28/2022 12:24:15 AM (4 years ago)
Author:
SergeyBiryukov
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #55635 – Description

    initial v1  
    11Resolves #17725
    22
    3 When `wp_convert_hr_to_bytes()` was introduced in [https://core.trac.wordpress.org/changeset/4388/ 4388] it provided a simplified mechanism to parse the values returned by functions like `ini_get()` which represent byte sizes. The over-simplified approach has led to issues in that function reporting the wrong byte sizes for various php.ini directives, leading to confusing problems such as uploading files that are rejected improperly or accepted improperly.
     3When `wp_convert_hr_to_bytes()` was introduced in [4388] it provided a simplified mechanism to parse the values returned by functions like `ini_get()` which represent byte sizes. The over-simplified approach has led to issues in that function reporting the wrong byte sizes for various php.ini directives, leading to confusing problems such as uploading files that are rejected improperly or accepted improperly.
    44
    55In this patch we're porting the parser from PHP's own source (which has remained stable for decades and probably can't change without major breakage) in order to more accurately reflect the values it uses when it reads those configurations.
    … …  
    88
    99Over the years this function has been modified a couple of times in ways that this patch reverts:
    10  - [https://core.trac.wordpress.org/changeset/38013 38013] introduced a `PHP_INT_MAX` limit in a way that coerces hexadecimal and octal integer representations to decimal.
    11  - [https://core.trac.wordpress.org/changeset/35325 35325] replaced the hard-coded byte size with overwritable constants but if there were any occasion for someone to change those constants in `wp-config.php` then we would actually want to preserve the hard-coded values in `wp_convert_hr_to_bytes()` since that function refers to code inside of PHP, not inside of WordPress.
    12  - The original code from [https://core.trac.wordpress.org/changeset/4388/ 4388] looks for the presence of the suffixes //anywhere// within the value string and prioritizes `g` over `m` over `k` whereas PHP only looks at the last character in the input string (this is something that [https://core.trac.wordpress.org/attachment/ticket/17725/17725.3.diff 17725.3.diff] got right). This can cause unexpected parses, such as with `14gmk` when WordPress interprets it as 14GiB but PHP interprets it as 14KiB.
     10 - [38013] introduced a `PHP_INT_MAX` limit in a way that coerces hexadecimal and octal integer representations to decimal.
     11 - [35325] replaced the hard-coded byte size with overwritable constants but if there were any occasion for someone to change those constants in `wp-config.php` then we would actually want to preserve the hard-coded values in `wp_convert_hr_to_bytes()` since that function refers to code inside of PHP, not inside of WordPress.
     12 - The original code from [4388] looks for the presence of the suffixes //anywhere// within the value string and prioritizes `g` over `m` over `k` whereas PHP only looks at the last character in the input string (this is something that [https://core.trac.wordpress.org/attachment/ticket/17725/17725.3.diff 17725.3.diff] got right). This can cause unexpected parses, such as with `14gmk` when WordPress interprets it as 14GiB but PHP interprets it as 14KiB.
    1313
    1414Further we do acknowledge the mismatch between PHP's definition of "gigabyte"/"megabyte"/"kilobyte" being factors of 1024 apart from each other and the standard of being 1000. WordPress follows PHP's convention so this is simply noted in the function and preserved.