PHP Deprecated: Drupal\forum\Form\DeleteForm::buildForm(): Implicitly marking parameter $taxonomy_term as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/web/modules/contrib/forum/src/Form/DeleteForm.php on line 55
Deprecated: Drupal\forum\Form\DeleteForm::buildForm(): Implicitly marking parameter $taxonomy_term as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/web/modules/contrib/forum/src/Form/DeleteForm.php on line 55
PHP Deprecated: Drupal\forum\Controller\ForumController::buildActionLinks(): Implicitly marking parameter $forum_term as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/web/modules/contrib/forum/src/Controller/ForumController.php on line 290
Deprecated: Drupal\forum\Controller\ForumController::buildActionLinks(): Implicitly marking parameter $forum_term as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/web/modules/contrib/forum/src/Controller/ForumController.php on line 290
PHP Deprecated: Drupal\forum\Form\Overview::buildForm(): Implicitly marking parameter $taxonomy_vocabulary as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/web/modules/contrib/forum/src/Form/Overview.php on line 30
Deprecated: Drupal\forum\Form\Overview::buildForm(): Implicitly marking parameter $taxonomy_vocabulary as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/web/modules/contrib/forum/src/Form/Overview.php on line 30
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
prem suthar commentedComment #4
prem suthar commentedComment #5
prem suthar commentedi think so now test's are runing against 8.3 .
So, we need to update the test to run against version 8.4, correct?
Comment #6
avpadernoComment #7
prem suthar commentedi created the issue as per this issue pipeline failure .
https://www.drupal.org/project/pathauto/issues/3495869
I apologize for creating this issue. I was not aware that it would not receive D.O. issue credit under the Abuse of the Contribution Credit system. It was an oversight on my part, and I did not intend to misuse the system.
Please feel free to close this issue, and I am sorry for any inconvenience caused.
Next Time we will take care of it .
Thank you for understanding.
Comment #8
larowlan@prem suthar, this is still a valuable fix, I just won't add issue credit for it because it is something we could automate in the future
If you're looking for issues to work on, there's heaps I'd love help with.
Comment #9
prem suthar commentedThank you for the clarification! I completely understand, and I’m glad the fix is still considered valuable. I’d love to contribute more—please feel free to point me toward any issues or areas where you could use help. Looking forward to assisting further! 😊
Comment #10
larowlan@prem suthar thanks, I'll get in touch later in the week
Comment #11
larowlanDiscussed this with @berdir who pointed out that these are more than just coding standards fixes, they resolve a unsilenced deprecation error that shows up in site logs. He felt these fixes should attract issue credit and I agree.
Let's see if we can setup 8.4 testing in the same MR
Comment #12
prem suthar commentedI have Added the code in the .gitlab-ci.yml and tried .
composer:
extends: .composer-base
variables:
PHP_VERSION: '8.4'
Comment #13
berdirTests are failing, that shows that there are more problems to fix here.
This .gitlab-ci.yml change problably shouldn't be committed as it would risk breaking on earlier versions if they aren't tested anymore. That said, there's still previous minor/major that could be used to test 8.1/8.3, so actually why not? We'd want to make sure that only the current version is tested with 8.4, job inheritance is a bit weird.
The gitlab ci template now uses PHP 8.4 with OPT_IN_TEST_MAX_PHP, so one option is to set hat variable to 1, that's a bit easier. it's one extra job to test though.
Comment #14
andypostFew more deprecations in test files and usage of
block_rebuild()must be converted to new hooks for 11.x https://www.drupal.org/node/3486534Comment #15
prem suthar commentedI have addressed the #14 and pushed the code . Please review
For item #13, I currently don’t have an idea of how to test the current version against version 8.4. If someone can provide guidance or refer me to a relevant document, I will review it and proceed accordingly.
Comment #16
berdirLooking at the test results, I think you essentially already did that option.
If you check the output, you can see that the phpunit job now runs on Drupal 11.1 with PHP 8.4, while phpunit (next minor) runs on PHP 8.3 and 11.2.
Instead of next minor, I personally usually enable previous major and previous minor (11.0 at the moment, would run with PHP 8.3) and previous major (10.4 currently with PHP 8.1) to make sure new changes don't break older supported versions. But changing that might be considered out of scope for this issue and is up to the maintainers, also if they want this or OPT_IN_PHP_MAX.
Setting to needs review to get feedback on that.
Comment #17
andypostUpdated CI and conditionally call
block_rebuild()for 11.1+ core (looks like it has no effect)Comment #19
larowlanLooks good, checked the pipelines and we have 8.4 on 11.1 and 11.2, 8.3 on 11.1 and 8.1 on 10.4
Only missing thing is 11.0 but that's out of scope here.
Will setup weekly testing while I'm here.
Comment #21
solideogloria commentedCan we have a new release that contains these fixes, please?
Comment #22
larowlanDone https://www.drupal.org/project/forum/releases/1.0.3
Comment #23
solideogloria commentedThanks!