Skip to content

Conversation

@jrfnl
Copy link
Member

@jrfnl jrfnl commented Oct 6, 2024

PHP 7.4 | New PHPCompatibility.ParameterValues.RemovedProprietaryCSVEscaping sniff

  • Standard:
    . fputcsv() and fgetcsv() now accept an empty string as $escape argument,
    which disables the proprietary PHP escaping mechanism. The behavior of
    str_getcsv() has been adjusted accordingly (formerly, an empty string was
    identical to using the default).

This adds a new sniff to detect code subject to this change.

The one thing I'm not 100% sure about, is whether this should be an error or a warning.

In PHP 7.3 and lower, passing an empty string as $escape to fputcsv() and fgetcsv() would result in a PHP warning: "Warning: fputcsv(): escape must be a character", not in a fatal error, but as the resulting CSV data can be significantly different - which could break imports/exports, I've elected to make it an error for PHPCompatibility anyway.

Refs:

PHP 8.4 | ParameterValues/RemovedProprietaryCSVEscaping: detect new deprecation

This commit updates the PHPCompatibility.ParameterValues.RemovedProprietaryCSVEscaping sniff to start flagging code affected by this next step in the plan to "kill csv escaping".

Note: the changelog entry isn't very clear and the implementation is different from the implementation proposed via the RFC.

In practice, it now comes down to: passing any value to the $escape parameter is okay.
Not passing the parameter, i.e. relying on the default value for the $escape parameter will now trigger a deprecation notice.
Also see: https://3v4l.org/lsjvA/rfc#vgit.master

Refs:

Related to #1731

jrfnl added 2 commits October 7, 2024 00:51
…Escaping` sniff

> - Standard:
>  . fputcsv() and fgetcsv() now accept an empty string as $escape argument,
>    which disables the proprietary PHP escaping mechanism. The behavior of
>    str_getcsv() has been adjusted accordingly (formerly, an empty string was
>    identical to using the default).

This adds a new sniff to detect code subject to this change.

The one thing I'm not 100% sure about, is whether this should be an `error` or a `warning`.

In PHP 7.3 and lower, passing an empty string as `$escape` to `fputcsv()` and `fgetcsv()` would result in a PHP warning: "Warning: fputcsv(): escape must be a character", not in a fatal error, but as the resulting CSV data can be significantly different - which could break imports/exports, I've elected to make it an error for PHPCompatibility anyway.

Refs:
* https://wiki.php.net/rfc/kill-csv-escaping (step 1)
* https://github.com/php/php-src/blob/004cb827501d1ddaf98daacb185a53e0816f78a7/UPGRADING#L489-L493
* php/php-src 3515
* php/php-src@3b0f051
…eprecation

> - Standard:
>  . Using the default value for $escape parameter of:
>   - fputcsv()
>   - fgetcsv()
>   - str_getcsv()
>   is now deprecated. It must be passed explicitly either positionally or via named arguments.
>   RFC: https://wiki.php.net/rfc/deprecations_php_8_4#deprecate_proprietary_csv_escaping_mechanism

This commit updates the `PHPCompatibility.ParameterValues.RemovedProprietaryCSVEscaping` sniff to start flagging code affected by this next step in the plan to "kill csv escaping".

Note: the changelog entry isn't very clear and the implementation is different from the implementation proposed via the RFC.

In practice, it now comes down to: passing _any_ value to the `$escape` parameter is okay.
Not passing the parameter, i.e. relying on the default value for the `$escape` parameter will now trigger a deprecation notice.
Also see: https://3v4l.org/lsjvA/rfc#vgit.master

Refs:
* https://wiki.php.net/rfc/kill-csv-escaping (step 2)
* https://wiki.php.net/rfc/deprecations_php_8_4#deprecate_proprietary_csv_escaping_mechanism
* https://github.com/php/php-src/blob/ee7e21020e74f02ca1d0ebee462ef9878fe9d55a/UPGRADING#L612-L617
* php/php-src 15362
* php/php-src@c818d94
* php/php-src 15569
* php/php-src@f756b96
@wimg wimg merged commit fc30dbb into develop Oct 7, 2024
@wimg wimg deleted the php-7.4-8.4/new-removedproprietarycsvescaping-sniff branch October 7, 2024 07:09
@jrfnl jrfnl changed the title PHP 7.4/8.4 | New PHPCompatibility.ParameterValues.RemovedProprietaryCSVEscaping sniff PHP 7.4/8.4 | ✨ New PHPCompatibility.ParameterValues.RemovedProprietaryCSVEscaping sniff Oct 12, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants