Remove E_STRICT error level and deprecate E_STRICT constant #13053

mvorisek · 2023-12-30T12:59:42Z

E_STRICT error level is no longer used in the php-src and is/was already documented in the code [1] as to be removed.

E_STRICT error level has no use since PHP 7.4 [2] with comment in the last PR description:

The constant still exists in the Zend engine which we may want to remove in PHP 8.

[1] https://github.com/php/php-src/blob/php-8.3.0/run-tests.php#L1647
[2] #4401

RFC: https://wiki.php.net/rfc/deprecations_php_8_4#remove_e_strict_error_level_and_deprecate_e_strict_constant

staabm · 2024-01-01T11:52:32Z

Does this change yield any value or just create a lot of work to cleanup existing userland code without actual value?

https://github.com/search?q=%22E_STRICT%22+language%3APHP&type=code

staabm · 2024-01-01T11:56:16Z

Before deleting it here IMO we should check whether static analysis tools would want to emit a error for the constant when used as a first step forward

https://phpstan.org/r/5f512016-9f2a-4387-9486-5330853e11cb

staabm · 2024-01-01T12:07:26Z

Maybe we can even mark the constant as @deprecated in the stubs. This might already be enough to make phpstan emit error for its usages (I did not check whether thats true).

mvorisek · 2024-01-01T12:41:06Z

I updated this PR to be BC friendly, ie. removed all E_STRICT error level related code as the error level is no longer used since PHP 7.4.

I kept the E_STRICT constant /wo even deprecating it. It might be deprecated in separate PR and such PR will probably require a RFC.

jorgsowa · 2024-01-01T18:10:25Z

Deprecation of the constant may be added to the collective RFC of deprecations: https://wiki.php.net/rfc/deprecations_php_8_4

Girgias · 2024-01-03T12:51:29Z

Adding it to the deprecation RFC makes sense, because in theory someone could use the constant with trigger_error()

mvorisek · 2024-01-16T13:24:41Z

This PR should not require RFC as it does not remove the constatnt. It removes the internal E_STRICT error level that is no longer used.

TimWolla · 2024-01-16T15:26:01Z

This PR changes the user-visible value of a built-in constant, which might be considered a breaking change. This PR is probably on the line of needing an RFC and in those cases it's easier to create a succinct RFC than to argue why it would not need one. Especially if at least one contributor feels that it needs one.

mvorisek · 2024-01-16T15:37:17Z

Can you or someone more involved add it to the https://wiki.php.net/rfc/deprecations_php_8_4? Thank you.

jorgsowa · 2024-01-16T16:39:32Z

I have added to the list. Let me know if something is wrong.

https://wiki.php.net/rfc/deprecations_php_8_4#constant_e_strict

andypost · 2024-08-04T16:39:08Z

Looks like voting finished!

iluuu1994 · 2024-08-05T09:52:43Z

It looks like this is missing the actual deprecation of the constant.

iluuu1994 · 2024-09-18T12:30:44Z

@mvorisek Ah, I see you just pushed the changes. Good timing 🙂 Thanks!

RFC: https://wiki.php.net/rfc/deprecations_php_8_4#remove_e_strict_error_level_and_deprecate_e_strict_constant Closes phpGH-13053

Note that this change addresses three different issues, which need to be done in one step, otherwise none of isolated patches would get a +1 CI verification: * Alignment for changed `$escape` parameter handling of CSV related methods, which must be avoided with PHP versions below 8.4.0-beta5, but is required as of PHP 8.4.0-RC1. * This `$escape` issue needs to be addressed directly in the `typo3/testing-framework` and thus needs a raised dependency directly. * PHP 8.4.0.0-RC1 also deprecated the `E_STRICT` constant, which needs to be addressed directly. With [1] the `$escape` parameter for the following method calls * `str_getcsv()` * `fputcsv()` * `fgetcsv()` must be provided as a 1 character long value. Omitting and using the default value will emit a PHP deprecation [2] warning as of PHP 8.4.0-RC1, for example: str_getcsv(): the $escape parameter must be provided as its default value will change To mitigate this, PHP recommends following: It must be passed explicitly either positionally or via named arguments. This change adjusts all occurences (function calls) and ensures that the `$escape` parameter is explicitly provided via specifying all parameters up to that position and not using a `named arguments` approach for easier backporting. The TYPO3 testing framework also needs to be aligned to mitigate `fgetcsv()` issues, and is raised in the same step - otherwise none of these changes would get a green CI pipeline run. The following testing-framework updates are adjusted: * main: simple update `main` pointer * 12.4: Raise to tag `8.2.2` * 11.5: Raise to tag `6.16.10` Used command(s): > composer require --dev "typo3/testing-framework":"^8.2.2" Additionally, PHP 8.4.0-RC1 deprecated the `E_STRICT` constant, which now emits a E_DEPRECATED which leads to failed CI tests. This change introduces a core internal constant with the same integer value, and replaces usages with this constant to mitigate the E_DEPRECATION. This constant can then be dropped with TYPO3 v14, preventing a breaking change at this time. [3][4] [1] php/php-src#15569 [2] https://github.com/php/php-src/blob/ebee8df27ed/UPGRADING#L617-L622 [3] https://github.com/php/php-src/blob/ebee8df27edf7/UPGRADING#L47-L49 [4] php/php-src#13053 Resolves: #105155 Releases: main, 12.4, 11.5 Change-Id: Ie8b7d46eeb75ba6e32c0e8f6e7e947775083cc15 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/86376 Tested-by: core-ci <typo3@b13.com> Tested-by: Stefan Bürk <stefan@buerk.tech> Reviewed-by: Garvin Hicking <gh@faktor-e.de> Reviewed-by: Stefan Bürk <stefan@buerk.tech> Tested-by: Garvin Hicking <gh@faktor-e.de>

Note that this change addresses three different issues, which need to be done in one step, otherwise none of isolated patches would get a +1 CI verification: * Alignment for changed `$escape` parameter handling of CSV related methods, which must be avoided with PHP versions below 8.4.0-beta5, but is required as of PHP 8.4.0-RC1. * This `$escape` issue needs to be addressed directly in the `typo3/testing-framework` and thus needs a raised dependency directly. * PHP 8.4.0.0-RC1 also deprecated the `E_STRICT` constant, which needs to be addressed directly. With [1] the `$escape` parameter for the following method calls * `str_getcsv()` * `fputcsv()` * `fgetcsv()` must be provided as a 1 character long value. Omitting and using the default value will emit a PHP deprecation [2] warning as of PHP 8.4.0-RC1, for example: str_getcsv(): the $escape parameter must be provided as its default value will change To mitigate this, PHP recommends following: It must be passed explicitly either positionally or via named arguments. This change adjusts all occurences (function calls) and ensures that the `$escape` parameter is explicitly provided via specifying all parameters up to that position and not using a `named arguments` approach for easier backporting. The TYPO3 testing framework also needs to be aligned to mitigate `fgetcsv()` issues, and is raised in the same step - otherwise none of these changes would get a green CI pipeline run. The following testing-framework updates are adjusted: * main: simple update `main` pointer * 12.4: Raise to tag `8.2.2` * 11.5: Raise to tag `6.16.10` Used command(s): > composer update "typo3/testing-framework" Additionally, PHP 8.4.0-RC1 deprecated the `E_STRICT` constant, which now emits a E_DEPRECATED which leads to failed CI tests. This change introduces a core internal constant with the same integer value, and replaces usages with this constant to mitigate the E_DEPRECATION. This constant can then be dropped with TYPO3 v14, preventing a breaking change at this time. [3][4] [1] php/php-src#15569 [2] https://github.com/php/php-src/blob/ebee8df27ed/UPGRADING#L617-L622 [3] https://github.com/php/php-src/blob/ebee8df27edf7/UPGRADING#L47-L49 [4] php/php-src#13053 Resolves: #105155 Releases: main, 12.4, 11.5 Change-Id: Ie8b7d46eeb75ba6e32c0e8f6e7e947775083cc15 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/86371 Tested-by: Garvin Hicking <gh@faktor-e.de> Reviewed-by: Stefan Bürk <stefan@buerk.tech> Tested-by: Anja Leichsenring <aleichsenring@ab-softlab.de> Reviewed-by: Anja Leichsenring <aleichsenring@ab-softlab.de> Tested-by: core-ci <typo3@b13.com> Tested-by: Stefan Bürk <stefan@buerk.tech> Reviewed-by: Garvin Hicking <gh@faktor-e.de>

Note that this change addresses three different issues, which need to be done in one step, otherwise none of isolated patches would get a +1 CI verification: * Alignment for changed `$escape` parameter handling of CSV related methods, which must be avoided with PHP versions below 8.4.0-beta5, but is required as of PHP 8.4.0-RC1. * This `$escape` issue needs to be addressed directly in the `typo3/testing-framework` and thus needs a raised dependency directly. * PHP 8.4.0.0-RC1 also deprecated the `E_STRICT` constant, which needs to be addressed directly. With [1] the `$escape` parameter for the following method calls * `str_getcsv()` * `fputcsv()` * `fgetcsv()` must be provided as a 1 character long value. Omitting and using the default value will emit a PHP deprecation [2] warning as of PHP 8.4.0-RC1, for example: str_getcsv(): the $escape parameter must be provided as its default value will change To mitigate this, PHP recommends following: It must be passed explicitly either positionally or via named arguments. This change adjusts all occurences (function calls) and ensures that the `$escape` parameter is explicitly provided via specifying all parameters up to that position and not using a `named arguments` approach for easier backporting. The TYPO3 testing framework also needs to be aligned to mitigate `fgetcsv()` issues, and is raised in the same step - otherwise none of these changes would get a green CI pipeline run. The following testing-framework updates are adjusted: * main: simple update `main` pointer * 12.4: Raise to tag `8.2.2` * 11.5: Raise to tag `6.16.10` Used command(s): > composer require --dev "typo3/testing-framework":"^6.16.10" Additionally, PHP 8.4.0-RC1 deprecated the `E_STRICT` constant, which now emits a E_DEPRECATED which leads to failed CI tests. This change introduces a core internal constant with the same integer value, and replaces usages with this constant to mitigate the E_DEPRECATION. This constant can then be dropped with TYPO3 v14, preventing a breaking change at this time. [3][4] [1] php/php-src#15569 [2] https://github.com/php/php-src/blob/ebee8df27ed/UPGRADING#L617-L622 [3] https://github.com/php/php-src/blob/ebee8df27edf7/UPGRADING#L47-L49 [4] php/php-src#13053 Resolves: #105155 Releases: main, 12.4, 11.5 Change-Id: Ie8b7d46eeb75ba6e32c0e8f6e7e947775083cc15 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/86377 Tested-by: Stefan Bürk <stefan@buerk.tech> Reviewed-by: Garvin Hicking <gh@faktor-e.de> Tested-by: core-ci <typo3@b13.com> Reviewed-by: Stefan Bürk <stefan@buerk.tech> Tested-by: Garvin Hicking <gh@faktor-e.de>

Note that this change addresses three different issues, which need to be done in one step, otherwise none of isolated patches would get a +1 CI verification: * Alignment for changed `$escape` parameter handling of CSV related methods, which must be avoided with PHP versions below 8.4.0-beta5, but is required as of PHP 8.4.0-RC1. * This `$escape` issue needs to be addressed directly in the `typo3/testing-framework` and thus needs a raised dependency directly. * PHP 8.4.0.0-RC1 also deprecated the `E_STRICT` constant, which needs to be addressed directly. With [1] the `$escape` parameter for the following method calls * `str_getcsv()` * `fputcsv()` * `fgetcsv()` must be provided as a 1 character long value. Omitting and using the default value will emit a PHP deprecation [2] warning as of PHP 8.4.0-RC1, for example: str_getcsv(): the $escape parameter must be provided as its default value will change To mitigate this, PHP recommends following: It must be passed explicitly either positionally or via named arguments. This change adjusts all occurences (function calls) and ensures that the `$escape` parameter is explicitly provided via specifying all parameters up to that position and not using a `named arguments` approach for easier backporting. The TYPO3 testing framework also needs to be aligned to mitigate `fgetcsv()` issues, and is raised in the same step - otherwise none of these changes would get a green CI pipeline run. The following testing-framework updates are adjusted: * main: simple update `main` pointer * 12.4: Raise to tag `8.2.2` * 11.5: Raise to tag `6.16.10` Used command(s): > composer require --dev "typo3/testing-framework":"^8.2.2" Additionally, PHP 8.4.0-RC1 deprecated the `E_STRICT` constant, which now emits a E_DEPRECATED which leads to failed CI tests. This change introduces a core internal constant with the same integer value, and replaces usages with this constant to mitigate the E_DEPRECATION. This constant can then be dropped with TYPO3 v14, preventing a breaking change at this time. [3][4] [1] php/php-src#15569 [2] https://github.com/php/php-src/blob/ebee8df27ed/UPGRADING#L617-L622 [3] https://github.com/php/php-src/blob/ebee8df27edf7/UPGRADING#L47-L49 [4] php/php-src#13053 Resolves: #105155 Releases: main, 12.4, 11.5 Change-Id: Ie8b7d46eeb75ba6e32c0e8f6e7e947775083cc15 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/86376 Tested-by: core-ci <typo3@b13.com> Tested-by: Stefan Bürk <stefan@buerk.tech> Reviewed-by: Garvin Hicking <gh@faktor-e.de> Reviewed-by: Stefan Bürk <stefan@buerk.tech> Tested-by: Garvin Hicking <gh@faktor-e.de>

Note that this change addresses three different issues, which need to be done in one step, otherwise none of isolated patches would get a +1 CI verification: * Alignment for changed `$escape` parameter handling of CSV related methods, which must be avoided with PHP versions below 8.4.0-beta5, but is required as of PHP 8.4.0-RC1. * This `$escape` issue needs to be addressed directly in the `typo3/testing-framework` and thus needs a raised dependency directly. * PHP 8.4.0.0-RC1 also deprecated the `E_STRICT` constant, which needs to be addressed directly. With [1] the `$escape` parameter for the following method calls * `str_getcsv()` * `fputcsv()` * `fgetcsv()` must be provided as a 1 character long value. Omitting and using the default value will emit a PHP deprecation [2] warning as of PHP 8.4.0-RC1, for example: str_getcsv(): the $escape parameter must be provided as its default value will change To mitigate this, PHP recommends following: It must be passed explicitly either positionally or via named arguments. This change adjusts all occurences (function calls) and ensures that the `$escape` parameter is explicitly provided via specifying all parameters up to that position and not using a `named arguments` approach for easier backporting. The TYPO3 testing framework also needs to be aligned to mitigate `fgetcsv()` issues, and is raised in the same step - otherwise none of these changes would get a green CI pipeline run. The following testing-framework updates are adjusted: * main: simple update `main` pointer * 12.4: Raise to tag `8.2.2` * 11.5: Raise to tag `6.16.10` Used command(s): > composer update "typo3/testing-framework" Additionally, PHP 8.4.0-RC1 deprecated the `E_STRICT` constant, which now emits a E_DEPRECATED which leads to failed CI tests. This change introduces a core internal constant with the same integer value, and replaces usages with this constant to mitigate the E_DEPRECATION. This constant can then be dropped with TYPO3 v14, preventing a breaking change at this time. [3][4] [1] php/php-src#15569 [2] https://github.com/php/php-src/blob/ebee8df27ed/UPGRADING#L617-L622 [3] https://github.com/php/php-src/blob/ebee8df27edf7/UPGRADING#L47-L49 [4] php/php-src#13053 Resolves: #105155 Releases: main, 12.4, 11.5 Change-Id: Ie8b7d46eeb75ba6e32c0e8f6e7e947775083cc15 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/86371 Tested-by: Garvin Hicking <gh@faktor-e.de> Reviewed-by: Stefan Bürk <stefan@buerk.tech> Tested-by: Anja Leichsenring <aleichsenring@ab-softlab.de> Reviewed-by: Anja Leichsenring <aleichsenring@ab-softlab.de> Tested-by: core-ci <typo3@b13.com> Tested-by: Stefan Bürk <stefan@buerk.tech> Reviewed-by: Garvin Hicking <gh@faktor-e.de>

Note that this change addresses three different issues, which need to be done in one step, otherwise none of isolated patches would get a +1 CI verification: * Alignment for changed `$escape` parameter handling of CSV related methods, which must be avoided with PHP versions below 8.4.0-beta5, but is required as of PHP 8.4.0-RC1. * This `$escape` issue needs to be addressed directly in the `typo3/testing-framework` and thus needs a raised dependency directly. * PHP 8.4.0.0-RC1 also deprecated the `E_STRICT` constant, which needs to be addressed directly. With [1] the `$escape` parameter for the following method calls * `str_getcsv()` * `fputcsv()` * `fgetcsv()` must be provided as a 1 character long value. Omitting and using the default value will emit a PHP deprecation [2] warning as of PHP 8.4.0-RC1, for example: str_getcsv(): the $escape parameter must be provided as its default value will change To mitigate this, PHP recommends following: It must be passed explicitly either positionally or via named arguments. This change adjusts all occurences (function calls) and ensures that the `$escape` parameter is explicitly provided via specifying all parameters up to that position and not using a `named arguments` approach for easier backporting. The TYPO3 testing framework also needs to be aligned to mitigate `fgetcsv()` issues, and is raised in the same step - otherwise none of these changes would get a green CI pipeline run. The following testing-framework updates are adjusted: * main: simple update `main` pointer * 12.4: Raise to tag `8.2.2` * 11.5: Raise to tag `6.16.10` Used command(s): > composer require --dev "typo3/testing-framework":"^6.16.10" Additionally, PHP 8.4.0-RC1 deprecated the `E_STRICT` constant, which now emits a E_DEPRECATED which leads to failed CI tests. This change introduces a core internal constant with the same integer value, and replaces usages with this constant to mitigate the E_DEPRECATION. This constant can then be dropped with TYPO3 v14, preventing a breaking change at this time. [3][4] [1] php/php-src#15569 [2] https://github.com/php/php-src/blob/ebee8df27ed/UPGRADING#L617-L622 [3] https://github.com/php/php-src/blob/ebee8df27edf7/UPGRADING#L47-L49 [4] php/php-src#13053 Resolves: #105155 Releases: main, 12.4, 11.5 Change-Id: Ie8b7d46eeb75ba6e32c0e8f6e7e947775083cc15 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/86377 Tested-by: Stefan Bürk <stefan@buerk.tech> Reviewed-by: Garvin Hicking <gh@faktor-e.de> Tested-by: core-ci <typo3@b13.com> Reviewed-by: Stefan Bürk <stefan@buerk.tech> Tested-by: Garvin Hicking <gh@faktor-e.de>

Note that this change addresses three different issues, which need to be done in one step, otherwise none of isolated patches would get a +1 CI verification: * Alignment for changed `$escape` parameter handling of CSV related methods, which must be avoided with PHP versions below 8.4.0-beta5, but is required as of PHP 8.4.0-RC1. * This `$escape` issue needs to be addressed directly in the `typo3/testing-framework` and thus needs a raised dependency directly. * PHP 8.4.0.0-RC1 also deprecated the `E_STRICT` constant, which needs to be addressed directly. With [1] the `$escape` parameter for the following method calls * `str_getcsv()` * `fputcsv()` * `fgetcsv()` must be provided as a 1 character long value. Omitting and using the default value will emit a PHP deprecation [2] warning as of PHP 8.4.0-RC1, for example: str_getcsv(): the $escape parameter must be provided as its default value will change To mitigate this, PHP recommends following: It must be passed explicitly either positionally or via named arguments. This change adjusts all occurences (function calls) and ensures that the `$escape` parameter is explicitly provided via specifying all parameters up to that position and not using a `named arguments` approach for easier backporting. The TYPO3 testing framework also needs to be aligned to mitigate `fgetcsv()` issues, and is raised in the same step - otherwise none of these changes would get a green CI pipeline run. The following testing-framework updates are adjusted: * main: simple update `main` pointer * 12.4: Raise to tag `8.2.2` * 11.5: Raise to tag `6.16.10` Used command(s): > composer update "typo3/testing-framework" Note that the backport has been squashed with the later partly revert using integer values instead of adding a own deprecated constant #105165 for [3][4]. We can not deprecate a constant and use it at the same time. We basically traded a deprecated constant with a new deprecated constant. Therefore this intermediate constant (added without being released yet in #105155) is removed again and replaced by a plain value. It's too likely that this constant is used by 3rd party code (or dependencies like typo3/testing-framework), which then makes it hard to remove this constant again (despite being deprecated). Also defining an own constant – that looks like an official PHP constant – into the global space, has caused immediate confusions which we want to avoid by using a scalar value + comment. The reason (possible 3rd party extensions that may still trigger this error) why this is kept (and not just removed) is also added to all usages now. [1] php/php-src#15569 [2] https://github.com/php/php-src/blob/ebee8df27ed/UPGRADING#L617-L622 [3] https://github.com/php/php-src/blob/ebee8df27edf7/UPGRADING#L47-L49 [4] php/php-src#13053 Resolves: #105155 Resolves: #105165 Releases: main, 13.3, 12.4, 11.5 Change-Id: Ie8b7d46eeb75ba6e32c0e8f6e7e947775083cc15 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/86456 Tested-by: Christian Kuhn <lolli@schwarzbu.ch> Tested-by: Oliver Hader <oliver.hader@typo3.org> Tested-by: core-ci <typo3@b13.com> Reviewed-by: Oliver Hader <oliver.hader@typo3.org> Reviewed-by: Christian Kuhn <lolli@schwarzbu.ch>

andypost · 2024-10-08T15:06:40Z

Using 8.4.0 RC2 I see a lot of warnings in pearcmd.php

Deprecated: Constant E_STRICT is deprecated in /usr/local/lib/php/pearcmd.php on line 441
Deprecated: Constant E_STRICT is deprecated in /usr/local/lib/php/pearcmd.php on line 441
Deprecated: Constant E_STRICT is deprecated in /usr/local/lib/php/pearcmd.php on line 441

is there pear repo to fix it?

jyxjjj · 2024-12-16T16:28:17Z

This can be easily bypassed via change it into 2048. I am here because there's a very well known repository negatively fixes their error. I think it can be detected inside error_reporting function. Can you fix this bypass error? May I create a new issue?

mvorisek requested review from dstogov, iluuu1994 and bukka as code owners December 30, 2023 12:59

github-actions bot added the Category: Engine label Dec 30, 2023

mvorisek marked this pull request as draft December 30, 2023 13:17

mvorisek force-pushed the rm_e_strict branch 2 times, most recently from 283cdfb to c5c27a7 Compare December 30, 2023 17:51

github-actions bot added SAPI: fpm Extension: standard labels Dec 30, 2023

mvorisek force-pushed the rm_e_strict branch from c5c27a7 to 4722423 Compare December 30, 2023 19:53

mvorisek marked this pull request as ready for review December 30, 2023 20:13

mvorisek force-pushed the rm_e_strict branch from 4722423 to 45bef89 Compare January 1, 2024 11:09

mvorisek changed the title ~~Remove E_STRICT constant/error level~~ Remove E_STRICT error level Jan 1, 2024

mvorisek changed the title ~~Remove E_STRICT error level~~ Remove unused E_STRICT error level Jan 1, 2024

Girgias added the Status: Requires RFC label Jan 5, 2024

alexandre-daubois mentioned this pull request Jul 23, 2024

[ErrorHandler][VarDumper] Remove PHP 8.4 deprecations symfony/symfony#57799

Merged

TimWolla added RFC and removed Status: Requires RFC labels Aug 4, 2024

iluuu1994 self-assigned this Sep 18, 2024

Deprecate E_STRICT constant and remove error level

d313ad6

RFC: https://wiki.php.net/rfc/deprecations_php_8_4#remove_e_strict_error_level_and_deprecate_e_strict_constant Closes phpGH-13053

iluuu1994 force-pushed the rm_e_strict branch from 1cc5369 to d313ad6 Compare September 18, 2024 12:47

iluuu1994 closed this in d313ad6 Sep 18, 2024

iluuu1994 merged commit d313ad6 into php:master Sep 18, 2024
7 of 10 checks passed

mvorisek deleted the rm_e_strict branch September 18, 2024 16:37

jrfnl mentioned this pull request Sep 18, 2024

PHP 8.4 | RemovedConstants: detect use of E_STRICT (RFC) PHPCompatibility/PHPCompatibility#1772

Merged

derrabus mentioned this pull request Sep 19, 2024

Deprecation of the E_STRICT constant in PHP 8.4 sebastianbergmann/phpunit#5956

Closed

DanielWTQ mentioned this pull request Sep 27, 2024

The E_STRICT constant is deprecated in PHP 8.4.0 RC1 on Windows. #16082

Closed

nightflyza mentioned this pull request Dec 12, 2024

Fix: constant E_STRICT is deprecated since PHP 8.4 phpsysinfo/phpsysinfo#403

Closed

2 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Remove E_STRICT error level and deprecate E_STRICT constant #13053

Remove E_STRICT error level and deprecate E_STRICT constant #13053

mvorisek commented Dec 30, 2023 •

edited by TimWolla

Loading

staabm commented Jan 1, 2024

staabm commented Jan 1, 2024

staabm commented Jan 1, 2024 •

edited

Loading

mvorisek commented Jan 1, 2024 •

edited

Loading

jorgsowa commented Jan 1, 2024

Girgias commented Jan 3, 2024

mvorisek commented Jan 16, 2024

TimWolla commented Jan 16, 2024

mvorisek commented Jan 16, 2024

jorgsowa commented Jan 16, 2024

andypost commented Aug 4, 2024

iluuu1994 commented Aug 5, 2024

iluuu1994 commented Sep 18, 2024

andypost commented Oct 8, 2024

jyxjjj commented Dec 16, 2024

Remove E_STRICT error level and deprecate E_STRICT constant #13053

Remove E_STRICT error level and deprecate E_STRICT constant #13053

Conversation

mvorisek commented Dec 30, 2023 • edited by TimWolla Loading

staabm commented Jan 1, 2024

staabm commented Jan 1, 2024

staabm commented Jan 1, 2024 • edited Loading

mvorisek commented Jan 1, 2024 • edited Loading

jorgsowa commented Jan 1, 2024

Girgias commented Jan 3, 2024

mvorisek commented Jan 16, 2024

TimWolla commented Jan 16, 2024

mvorisek commented Jan 16, 2024

jorgsowa commented Jan 16, 2024

andypost commented Aug 4, 2024

iluuu1994 commented Aug 5, 2024

iluuu1994 commented Sep 18, 2024

andypost commented Oct 8, 2024

jyxjjj commented Dec 16, 2024

mvorisek commented Dec 30, 2023 •

edited by TimWolla

Loading

staabm commented Jan 1, 2024 •

edited

Loading

mvorisek commented Jan 1, 2024 •

edited

Loading