Deprecated: Drupal\key\KeyConfigOverrides::__construct(): Implicitly marking parameter $cache_backend as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/web/modules/contrib/key/src/KeyConfigOverrides.php on line 53
PHP Deprecated: Drupal\tfa\Form\TfaOverviewForm::buildForm(): Implicitly marking parameter $user as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/web/modules/contrib/tfa/src/Form/TfaOverviewForm.php on line 72
Deprecated: Drupal\tfa\Form\TfaOverviewForm::buildForm(): Implicitly marking parameter $user as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/web/modules/contrib/tfa/src/Form/TfaOverviewForm.php on line 72
PHP Deprecated: Drupal\tfa\Form\TfaSetupForm::buildForm(): Implicitly marking parameter $user as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/web/modules/contrib/tfa/src/Form/TfaSetupForm.php on line 99
Deprecated: Drupal\tfa\Form\TfaSetupForm::buildForm(): Implicitly marking parameter $user as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/web/modules/contrib/tfa/src/Form/TfaSetupForm.php on line 99
PHP Deprecated: Drupal\tfa\Form\TfaDisableForm::buildForm(): Implicitly marking parameter $user as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/web/modules/contrib/tfa/src/Form/TfaDisableForm.php on line 83
Deprecated: Drupal\tfa\Form\TfaDisableForm::buildForm(): Implicitly marking parameter $user as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/web/modules/contrib/tfa/src/Form/TfaDisableForm.php on line 83
| Comment | File | Size | Author |
|---|
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
chandansha commentedComment #4
chandansha commentedComment #5
chandansha commentedComment #6
cmlaraNote:
This issue contains fixes that are detected by phpcs and automatically fixed by phpcbf.
This issue will not receive D.O. issue credit under Abuse of the Contribution Credit system.
Comment #7
chandansha commented@cmlara sorry for this contribution i have't idea about it i have found that issue in drush cr so i created issue and try to fixed it.
Next time i will take care of it.
Thanks!
Comment #8
cmlaraCommitted to dev on 2.x, postponing 1.x on #3496667: PHP 7.0 Support as we technically can't add this into the codebase without breaching declared minimum php support.
Comment #9
cmlaraComment #12
nadim hossain commentedCreating this to be used for a project updated to php 8.4
Comment #13
acbramley commentedPHP 7.4 has been EOL for almost 3 years, why would we need to support 7.0?
This is NW as there are more issues that need fixing
Comment #14
acbramley commentedMight be good to get #3543251: Fix test failures related to phpunit:^11 in first to get a green pipeline for this.
Comment #16
cmlaraReplied to comment #13 in #3496667-2: PHP 7.0 Support to keep the questions/responses closer linked to the issues.
Back to postponed on that issues decisions.
Comment #17
casey commentedSnapshot of latest state of MR for safe usage with composer patches.
Comment #18
acbramley commented@cmlara what about https://www.drupal.org/project/tfa/issues/3496667#comment-16260847?
Comment #19
acbramley commentedMight be time to revisit this
Comment #20
d.fisher commentedSeeing this now on Drupal 11.3 and PHP 8.4.
Comment #21
andreastkdf commentedShould probably be fixed as part of new broader issue regarding failing tests: Fix CI failures: resolve PHPUnit + PHPStan errors
Comment #22
andreastkdf commentedComment #23
andreastkdf commentedComment #24
phoang commentedPatch works for me. RTBC +1
Comment #25
phoang commentedComment #26
svendecabooterSeems to resolve the PHP8.4 warnings. Can this be added to a new release?
Comment #27
smustgrave commentedWriting test coverage for a module that uses this and started getting hit by this +1 to merging please.
Comment #28
cmlaraFor this to be committed #3496667: PHP 7.0 Support needs to be decided/committed first (either PHP7.0 is maintained or increased to at least 7.1 which is required for the changes in this issue).
Comment #29
acbramley commented@cmlara I believe that decision lies with you, no one else has voiced support to keep PHP 7.0 compatibility. It would be good to get these decisions made so we can start unblocking the issue queue.
Comment #30
cmlaraPersonally, if its my choice I would have only 2.x receiving this and the issue closed out as complete.
There are however 6 other "higher ranking" project maintainers that have the ability to override my opinion, and I have my doubts they are as strict on BC as I am, which is why I have not made the "executive decision" to close this outright as already completed on 2.x.
Comment #31
acbramley commentedBut 2.x is explicitly not production ready, therefore we need to maintain 8.x-1.x releases until it is.
Comment #32
acbramley commentedWe could also just do some release hopping that I described in https://www.drupal.org/project/tfa/issues/3496667#comment-16260847
Cut a 3.x from 8.x-1.x and drop support for any Drupal and PHP versions that are unsupported.
Comment #33
cmlara8.x-1.x isn't exactly production ready either. it may have a 'tagged release' however given its history and known publicly disclosed flaws it should IMO generally be considered unsuitable for production (If i had authority I would mark 8.x-1.x unsupported and vulnerable to indicate this concern). It is also a large portion why I personally do not like the idea to try and continued 8.x-1.x code base as 3.x release, doing so would be reckless.
This issue isn't a concern until PHP 9.0's initial release, which at this time has no defined date yet. My understanding is we can generally expect around 6 months lead time from initial announcement to release. It should not be interfering with production sites (logging disabled or backed only) and should not interfere with tests (only test code you 'own').
Comment #34
acbramley commentedOver 10k sites are using 8.x-1.x, marking it unsupported would be the reckless thing to do.
I'm not saying 8.x-1.x (or more so 3.x) has to receive new features but minor fixes like this shouldn't need to be blocked.