Suppress PHPCS auto_detect_line_endings deprecation notice

[GeorgeWebDevCy]

Summary

• Suppress the known PHPCS auto_detect_line_endings is deprecated notice while PHPCS runs.
• Delegate all other errors to the previously registered error handler.
• Add a regression test with a custom error handler that would throw if the PHPCS deprecation leaks through.

Fixes #1368.

Testing

• php -l includes/Checker/Checks/Abstract_PHP_CodeSniffer_Check.php
• php -l tests/phpunit/tests/Checker/Checks/Plugin_Review_PHPCS_Check_Tests.php
• vendor/bin/phpcs --standard=phpcs.xml.dist includes/Checker/Checks/Abstract_PHP_CodeSniffer_Check.php tests/phpunit/tests/Checker/Checks/Plugin_Review_PHPCS_Check_Tests.php
• PHP 8.4 Docker harness running the PHPCS-backed check with an outer handler that throws on auto_detect_line_endings is deprecated: errors=0 warnings=0

Follow-up verification

• php -l passed for both modified PHP files.
• Targeted PHPCS passed for both modified PHP files.
• Targeted PHPStan passed for both modified PHP files.
• Windows Docker / wp-env: Plugin_Review_PHPCS_Check_Tests passed: 4 tests, 61 assertions.

AI assistance: Yes
Tool: OpenAI Codex
Used for: Analyzing the error-handler stack, implementing the exceptional-path cleanup and regression test, and running the stated automated checks. I remain responsible for the contribution.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: GeorgeWebDevCy <orionaselite@git.wordpress.org>
Co-authored-by: ernilambar <nilambar@git.wordpress.org>
Co-authored-by: davidperezgar <davidperez@git.wordpress.org>
Co-authored-by: Tsjippy <tsjippy@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[ernilambar]

Instead of suppressing may be we should explore why it is coming.

[GeorgeWebDevCy]

Thanks, I explored that path.

What I found:

• The notice comes from PHPCS itself: vendor/squizlabs/php_codesniffer/src/Runner.php calls @ini_set( "auto_detect_line_endings", true ) during Runner::init().
• The repo is already on the latest PHPCS 3.x release, squizlabs/php_codesniffer 3.13.5, and that call is still present there.
• I checked whether moving to PHPCS 4 would avoid needing this, but it is currently blocked by the dependency graph: automattic/vipwpcs, wp-coding-standards/wpcs, plugin-check/phpcs-sniffs, and slevomat/coding-standard all constrain PHPCS to 3.x in the installed versions.
• The deprecation leaks when a site/plugin has a custom error handler that still receives suppressed @ini_set() deprecations, which matches the stack trace in error: auto_detect_line_endings is deprecated #1368.

So this PR keeps the workaround narrowly scoped to the PHPCS runner call and only swallows this exact PHPCS deprecation from Runner.php; everything else is delegated back to the previously registered error handler.

[Copilot]

Pull request overview

This pull request addresses a PHP 8.4+ deprecation notice (auto_detect_line_endings is deprecated) emitted by PHP_CodeSniffer during Plugin Check’s PHPCS-backed checks, by temporarily intercepting that specific deprecation while PHPCS runs and validating the behavior via a regression test.

Changes:

• Register a temporary error handler around PHPCS execution to suppress the specific auto_detect_line_endings deprecation originating from PHPCS’s Runner.php.
• Restore the prior error handler after PHPCS completes.
• Add a PHPUnit regression test that installs an outer error handler which would throw if the deprecation leaks through.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
includes/Checker/Checks/Abstract_PHP_CodeSniffer_Check.php	Adds a scoped error handler around PHPCS execution to suppress the targeted deprecation and restore prior handling afterward.
tests/phpunit/tests/Checker/Checks/Plugin_Review_PHPCS_Check_Tests.php	Adds a regression test to ensure the PHPCS deprecation does not leak through an outer error handler.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[davidperezgar]

@GeorgeWebDevCy thanks for the PR. Could you check the comments?

[GeorgeWebDevCy]

Thanks for the nudge, @davidperezgar. Copilot's two points are both valid. On Abstract_PHP_CodeSniffer_Check.php, the catch block only restores $_SERVER['argv'] and doesn't reset installed_paths or close the output buffer if PHPCS throws, so that cleanup should move into the finally block alongside restore_error_handler(). On the test file, the custom error handler returns false unconditionally for non-target errors, which silently swallows anything a previously-registered handler would have caught during the test — it should capture and delegate to the previous handler, mirroring what the production code does. Pushing a follow-up commit addressing both now.

[davidperezgar]

I reviewed this with Codex and found a handler-restoration issue.

PHPCS installs its own error handler during runPHPCS() and restores it only on its normal execution path. If PHPCS throws after installing that handler, the finally block’s single restore_error_handler() removes PHPCS’s handler but leaves this PR’s temporary handler active, rather than restoring the caller’s original handler.

That can leak the temporary handler into subsequent code and alter how later errors are handled. Could we explicitly restore the original handler (or unwind both handlers) on this exceptional path, and add a regression test that forces PHPCS to throw after registering its handler?

[GeorgeWebDevCy]

Thanks for catching this. I pushed 8c56ff0, which now detects whether PHPCS left its own handler active on the exceptional path, unwinds it when necessary, and then restores this check's temporary handler so the caller's original handler is reinstated.

I also added a regression test that simulates PHPCS registering its handler and throwing before restoring it. The focused test class passes in the Windows Docker test environment: 4 tests, 61 assertions. Syntax checks, targeted PHPCS, and targeted PHPStan also pass.

[GeorgeWebDevCy]

Follow-up: commits ed1fe59 and 1741df7 address the CI formatting and PHPStan findings from the first run. The same two modified files now pass the repository PHPCS standard, and the full 107-file PHPStan analysis completes with no errors locally. The earlier PHPUnit matrix failures occurred during Docker image pulls (
egistry-1.docker.io timeout), before tests ran.