[wp-trac] [WordPress Trac] #64928: pomo/po.php: Replace deprecated auto_detect_line_endings with manual line-ending handling

[WordPress Trac]

#64928: pomo/po.php: Replace deprecated auto_detect_line_endings with manual line-
ending handling
--------------------------+--------------------------------------
 Reporter:  apermo        |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  I18N          |    Version:  5.9
 Severity:  normal        |   Keywords:  has-patch has-unit-tests
  Focuses:                |
--------------------------+--------------------------------------
 Since WordPress 5.9 ([51636]), `wp-includes/pomo/po.php` silences the PHP
 8.1 deprecation of `auto_detect_line_endings` with the `@` operator:

 {{{#!php
 @ini_set( 'auto_detect_line_endings', 1 );
 }}}

 The comment says to revisit this when PHP 9.0 is in alpha/beta. PHP 9.0 is
 still years away (PHP 8.5 is expected late 2025, 8.6 late 2026), but this
 is already causing real problems right now.

 == The actual problem

 The `@` suppression works for PHP's built-in error handler. But custom
 error handlers like Sentry, Bugsnag, Rollbar, or New Relic still receive
 the error — `@` only sets `error_reporting` to `0` temporarily, and the
 handler has to check that itself. Many don't.

 The result: this deprecation notice fires on '''every single request'''
 and gets logged to error tracking on every WordPress site running PHP 8.1+
 with a custom error handler. That's a lot of noise, and it affects a lot
 of sites.

 We ran into this in our production environment, where it was spamming our
 Sentry instance. I'm fairly sure we're not the only ones dealing with
 this.

 == The fix

 [https://github.com/WordPress/wordpress-develop/pull/7256 PR #7256] by
 @akirk already has a clean solution. It's been open since August 2024 but
 hasn't received any reviews yet.

 The approach is straightforward:
  * Remove the `@ini_set( 'auto_detect_line_endings', 1 )` call
  * Handle `\r` line endings manually in `PO::read_line()` using `strpos()`
 + `fseek()`
  * Includes a unit test covering `\r`, `\n`, and `\r\n`

 I've independently tested this: a 23,000-line German core translation file
 (`de_DE.po`) converted to `\r`-only line endings parses identically (8
 headers, 4456 entries) to the original. No regressions on page loads or
 REST API responses.

 == Why not wait for PHP 9.0

 Well, there are three main reasons.

 First, the error tracking noise is a real problem today. Sites using
 Sentry or similar tools are getting this deprecation on every request in
 production. The only workaround is to blacklist the message in your error
 tracker, which is a band-aid, not a fix.

 Second, the fix already exists, it's tested, and it moves the line-ending
 handling to where it actually belongs — `PO::read_line()`. That's just
 better code.

 Third, there's a small but real performance benefit: removing the `@`
 operator + `ini_set` call eliminates per-request overhead. The `@`
 operator saves/restores `error_reporting`, and `ini_set` modifies a
 runtime setting. Neither is needed when the handling is done in
 `read_line()`. Not a huge deal on its own, but this runs on every request
 on every WordPress site. It adds up.

 == Related

  * #53635 — PHP 8.1 compatibility (introduced the `@` suppression in
 [51636])
  * #51383 — `php-error` CSS class added for suppressed errors (Alex linked
 his PR there, but it's a different issue)
  * [https://github.com/WordPress/wordpress-develop/pull/7256 PR #7256] —
 The patch by Alex Kirk

 Disclaimer: Research, verfication and documentation with help of Claude
 Opus 4.6 (1M)

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64928>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform