PHP 8.4 | Fix CSV escaping deprecation notices#5991
Merged
swissspidy merged 3 commits intowp-cli:mainfrom Oct 1, 2024
Merged
Conversation
Okay, so this is an awkward one.... The short of it, is that the custom escaping mechanism available for `fputcsv()`, `fgetcsv()` and `str_getcsv()` is kind of broken and using it is discouraged. However, the default parameter value for the optional `$escape` parameter is still `"\\"`, which activates it. Since PHP 7.4, it is allowed to pass an empty string to `$escape`, which effectively de-activates the PHP native custom escaping mechanism. Prior to PHP 7.4, passing an empty string would fall through to the default value of the parameter. Since PHP 8.4, not passing the `$escape` is deprecated - which effectively makes it a required parameter _after_ two optional parameters... 🤦🏻♀️ The intention is to change the default value to an empty string in a future PHP version (PHP 9.0?) and once that's done, the "required optional" `$escape` parameter can be removed again (providing you want to follow the advise of disabling the custom escaping mechanism)... Yes, don't ask. I've [challenged the implementation of this deprecation](php/php-src#15569 (comment)), but my objections were waved aside. So, generally speaking to handle this deprecation there are three options: * Pass the parameter and set it explicitly to the current default value `"\\"`. * Pass the parameter and set it explicitly to an empty string to deactivate the PHP custom escaping mechanism on PHP 7.4+ and let it fall through to the default value for escaping prior to PHP 7.4. This may cause issues when an export was created with the `"\\"` value for escaping and an import is done without escaping. * Silence the deprecation notice for the time being by using the `@` operator and run the risk of other notices/warnings (and prior to PHP 8.0 errors) from the function call being silenced. All things considering and keeping in mind that this code base still has a PHP 5.6 minimum, I think it would probably be best to go for option 1, to prevent potential import/export file compatibility problems. This commit implements this. Refs: * https://wiki.php.net/rfc/deprecations_php_8_4#deprecate_proprietary_csv_escaping_mechanism * https://wiki.php.net/rfc/kill-csv-escaping * php/php-src 15362 * php/php-src 15569
swissspidy
approved these changes
Oct 1, 2024
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Okay, so this is an awkward one....
The short of it, is that the custom escaping mechanism available for
fputcsv(),fgetcsv()andstr_getcsv()is kind of broken and using it is discouraged. However, the default parameter value for the optional$escapeparameter is still"\\", which activates it.Since PHP 7.4, it is allowed to pass an empty string to
$escape, which effectively de-activates the PHP native custom escaping mechanism. Prior to PHP 7.4, passing an empty string would fall through to the default value of the parameter.Since PHP 8.4, not passing the
$escapeis deprecated - which effectively makes it a required parameter after two optional parameters... 🤦🏻♀️ The intention is to change the default value to an empty string in a future PHP version (PHP 9.0?) and once that's done, the "required optional"$escapeparameter can be removed again (providing you want to follow the advise of disabling the custom escaping mechanism)...Yes, don't ask. I've challenged the implementation of this deprecation, but my objections were waved aside.
So, generally speaking to handle this deprecation there are three options:
"\\"."\\"value for escaping and an import is done without escaping.@operator and run the risk of other notices/warnings (and prior to PHP 8.0 errors) from the function call being silenced.All things considering and keeping in mind that this code base still has a PHP 5.6 minimum, I think it would probably be best to go for option 1, to prevent potential import/export file compatibility problems.
This commit implements this.
Refs: