[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
Wed Sep 14 23:15:31 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:  has-patch dev-feedback changes-      |     Focuses:
  requested                                      |
-------------------------------------------------+-------------------------
Changes (by dmsnell):

 * keywords:  needs-unit-tests has-patch dev-feedback changes-requested =>
     has-patch dev-feedback changes-requested


Comment:

 I've
 [https://core.trac.wordpress.org/attachment/ticket/55635/55635.0.3.diff
 updated (55635.0.3.diff)] the associated patch in
 [https://github.com/WordPress/wordpress-develop/pull/2660 #2660] again and
 would be interested in moving forward here.

 **What's different/new?**

  - `ini_parse_quantity0` is merged in PHP 8.2, which is
 [https://wiki.php.net/todo/php82 schedule for release on Nov. 24]
  - there's a new set of functions for comparing these values:
 `wp_ini_lesser_quantity()`, `wp_ini_greater_quantity()`, and
 `wp_ini_quantity_cmp()`. these are valuable because we often want to
 retain the string value of the set INI directive while knowing if it's
 larger or smaller than another.
  - I've updated some core code to use the new functionality. while some
 cases required a fair bit of work to understand what core is doing, I
 believe that the updated code is much easier to follow.

 Can you let me know if I've overlooked any feedback?
 Can you identify any blockers to this issue?
 What is important to you before merging this?

 P.S. I know there's still discussion about back-porting the internal PHP
 parsing routine. Unless someone feels really strongly about that I'd like
 to keep it in because it flows from the purpose of these updates that
 WordPress should agree with PHP on what these values mean. Being off by a
 factor of a million in normal cases is something that seems worth
 avoiding.

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


More information about the wp-trac mailing list