Documentation updates for Drupal 11 wxt [#3529851]

Problem/Motivation

https://drupalwxt.github.io/docs/general/installation/

Currently says:
# Requires PHP 8.3 (Drupal 11 - alpha release)
should be changed to
# Requires PHP 8.3 (Drupal 11 LTS)

Steps to reproduce

Visit the documentation page

Proposed resolution

See issue summary for suggested change

Remaining tasks

Make the changes

User interface changes

Documentation

Comment	File	Size	Author
#25	panels-php84-patch-3534531.patch	3.21 KB	danrod
#25	entityqueue-patch-php84-3499532.patch	4.36 KB	danrod
#25	migrate_tools-patch-php84-3411051 .patch	85.02 KB	danrod
#25	page_manager-patch-php84-44.patch	2.59 KB	danrod
#25	field-group-patch-php84-95.patch	6.39 KB	danrod
#23	pathauto-patch-php84-91.patch	9.63 KB	danrod
#22	panels-php84.patch	3.43 KB	danrod
#22	layout_library-php84.patch	972 bytes	danrod
#22	entityqueue-php84-2.patch	1004 bytes	danrod
#22	entityqueue-php84-1.patch	4.36 KB	danrod
#22	migrate_tools-php84-and-other-changes.patch	85.02 KB	danrod
#22	page_manager-php84.patch	2.59 KB	danrod
#22	field_group-php84.patch	6.44 KB	danrod
#3	3529851-php84.png	626.6 KB	danrod

Comments

Comment #1

12 June 2025 at 14:48

joseph.olstad created an issue. See original summary.

Comment #2

joseph.olstad

French

commented 12 June 2025 at 14:49

Assigned:

Unassigned

» smulvih2

Comment #3

danrod

Ottawa

commented 15 July 2025 at 23:56

Status	File	Size
new	3529851-php84.png	626.6 KB

Is there any plan to support PHP 8.4 sometime soon? I've seen a few warning here and there, but given that most projects are updating their projects to work with PHP 8.4, I'm not sure what is the approach here.

PHP 8.4

Comment #4

joseph.olstad

French

commented 16 July 2025 at 18:11

Category:	Task	» Support request
Status:	Active	» Fixed

Yesterday I published bootstrap 3.36 which IS php 8.4 compatible
Simply do this:

composer up drupal/bootstrap

Comment #5

joseph.olstad

French

commented 16 July 2025 at 18:11

Status:

Fixed

» Needs review

Comment #6

joseph.olstad

French

commented 16 July 2025 at 18:14

@danron, normally you should check/report contrib issues first in the individual contrib projects. bootstrap is a contrib theme , has it's own issue queue. It's ok to know about it here but if you would have checked yesterday you would have discovered that this was fixed in the dev release.

It is always helpful to get feedback on the dev release however since you didn't provide that feedback you get lucky anyway since I tagged a new release with the fix yesterday afternoon.

bootstrap 3.36 has those fixes so please upgrade and let us know how it goes.

composer up drupal/bootstrap

#3528571: PHP 8.4 compatibility improved

Comment #7

joseph.olstad

French

commented 16 July 2025 at 18:23

with that said, we probably should lock 6.1.x onto php 8.3 so that people don't go and do things like try and use PHP 8.4 before it's even been tested.

I'd say that wxt 6.1.x should likely target/recommend php 8.3

Perhaps once tested, if wxt 6.2.x works out well, we could recommend php 8.4 for wxt 6.2.x

This could be locked down using a directive in the wxt/composer.json

Comment #8

joseph.olstad

French

commented 16 July 2025 at 18:25

~~The folks at zend should take strong medication for their addiction to deprecations.~~

Comment #9

danrod

Ottawa

commented 16 July 2025 at 18:32

It was a small experiment, no need to answer like that.

And I installed WxT 6.1.x last night yesterday, perhaps yes, I was lucky, and sorry for trying to contribute and do some testing, I'm aware about the individual Drupal projects besides this distro, thanks, I use some projects here and there sometimes..

Comment #10

joseph.olstad

French

commented 16 July 2025 at 19:21

@danrod , appreciate your reporting of testing, so is that the only issue was with bootstrap?

I'd expect basically dozens of modules to blow up with 8.4 not just bootstrap?

Maybe 8.4 isn't much of a shocker?

With that said, please try again this time using bootstrap 3.36 , feedback on that especially is very much appreciated since I tagged and released it yesterday.

Last week there were 17,938 installs of bootstrap 3.35 so really that's why I'm pointing you in the direction of the bootstrap issue queue since WxT is only in the hundreds.

#3528571: PHP 8.4 compatibility improved

Comment #11

joseph.olstad

French

commented 16 July 2025 at 19:32

Ya I suppose, maybe it is time to start testing 8.4? I can easily do this in my environments.

PHP time is like rabbit years. One PHP year converts to a decade or two in human years.

Comment #12

joseph.olstad

French

commented 17 July 2025 at 00:17

@danrod sorry I guess maybe that came off badly, I just kinda thought it's funny that I published the PHP 8.4 compatibility fixes in a release yesterday and the day after I'm seeing it again lol. It's not like I even waited more than 48 hours with the code sitting in the dev branch. I guess people are excited to try PHP 8.4! The bootstrap project like I mentioned the recent release 3.35 has nearly 20,000 installs, it has surpassed my expectations! I imagine people will be rushing to install 3.36 and try out PHP 8.4.

Today I did some additional work on the bootstrap theme cleaning up a bunch of easy phpcs related issues. There's still many but I put a dent into it, got over 40 of them resolved.

Comment #13

danrod

Ottawa

commented 17 July 2025 at 00:33

@joseph.olstad yeah, more people eager try PHP 8.4, and actually is being encouraged by the Core maintainers themselves, I haven't seen other warnings in my WxT 6.x instances, I'll poke around check if I see others.

I see a bunch others from other modules when going to the home page:

Deprecated: entityqueue_entity_field_access(): Implicitly marking parameter $items as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/html/modules/contrib/entityqueue/entityqueue.module on line 21

Deprecated: field_group_form_process(): Implicitly marking parameter $form_state as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/html/modules/contrib/field_group/field_group.module on line 426

Deprecated: field_group_field_group_form_process_build_alter(): Implicitly marking parameter $form_state as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/html/modules/contrib/field_group/field_group.module on line 493

Deprecated: field_group_fields_nest(): Implicitly marking parameter $vars as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/html/modules/contrib/field_group/field_group.module on line 637

Deprecated: field_group_field_layout_fields_nest(): Implicitly marking parameter $vars as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/html/modules/contrib/field_group/field_group.module on line 730

Deprecated: field_group_group_save(): Implicitly marking parameter $display as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/html/modules/contrib/field_group/field_group.module on line 877

Deprecated: Drupal\migrate_tools\Routing\RouteProcessor::processOutbound(): Implicitly marking parameter $bubbleable_metadata as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/html/modules/contrib/migrate_tools/src/Routing/RouteProcessor.php on line 26

Deprecated: Drupal\layout_library\Plugin\SectionStorage\Library::access(): Implicitly marking parameter $account as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/html/modules/contrib/layout_library/src/Plugin/SectionStorage/Library.php on line 254

Deprecated: Drupal\entityqueue\Plugin\views\relationship\EntityQueueRelationship::init(): Implicitly marking parameter $options as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/html/modules/contrib/entityqueue/src/Plugin/views/relationship/EntityQueueRelationship.php on line 102

Deprecated: Drupal\entityqueue\Entity\EntitySubqueue::access(): Implicitly marking parameter $account as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/html/modules/contrib/entityqueue/src/Entity/EntitySubqueue.php on line 91

Most of them don't have a PHP8.4 fix, I am not sure if you guys are eager to adopt PHP 8.4 (yet), but I'll make patches for these just in case.

Comment #14

joseph.olstad

French

commented 17 July 2025 at 01:46

ok cool ya, I only see two modules in there entityqueue and field_group

very good that you're looking into it!

Comment #15

joseph.olstad

French

commented 17 July 2025 at 17:55

Someone I have a lot of respect for (I've seen his work) recently posted on LinkedIn that he's some back to PHP after several years of hiatus.

He points out several improvements since PHP 7.0.

Notably:

A modern, type-safe language with union types (int|string|null), match expressions, and the nullsafe operator.

A JIT compiler that transforms PHP into a language capable of handling CPU-intensive workloads. In some benchmarks, it even outperforms Node.js!

A mature ecosystem: Laravel, Symfony, FrankenPHP, Pest, Psalm, PHPStan, etc. — we now have developer tools and static analysis comparable to TypeScript’s world.

Even ThePrimeagen admitted that “PHP doesn’t suck anymore”. That’s not nothing.

He points out the performance improvements also, significant performance improvements with recent releases of PHP over previous releases.

So ya, I should and will be more welcoming to testing PHP 8.4 (and soon PHP 8.5). It's a challenge keeping up however it's great that there's people like Maximiilen Gilet that are comming back to the PHP ecosystem from frameworks such as NodeJS.

While I tend to push back on disruptive upstream changes and try to minimize risks, it is good to see that some folks really appreciate what's going on upstream.

@danrod, it would be good to get WxT fully tested on PHP 8.4, please follow up with your patches. I'm sure they will be appreciated not just by us but by many others.

Comment #16

danrod

Ottawa

commented 18 July 2025 at 00:05

@joseph.olstad thanks, will do during some free time tomorrow, I never jumped into the NodeJS wagon really (but I like JS), I'd rather learn to use Rust or a Python framework to create a website.

PHP is a more mature language with new features that you would expect from a modern language, the problem is that Drupal didn't catch up on time with these new features while other CMS did, that's why more and more people are migrating their Drupal sites to WordPress.

I know a client in Ottawa that had an old D9 site and was offered his site to be migrated to D11 or WordPress, the D11 proposal was cheaper. Way chaper, guess which one the client chose?

Experience Builder is a great idea but it came up late. WordPress has had these features since ages ago.

Comment #17

joseph.olstad

French

commented 21 July 2025 at 04:06

@danrod

https://chatgpt.com/share/687dbc9d-b6e0-800e-a0d2-284f3cb4320d

Comment #18

danrod

Ottawa

commented 21 July 2025 at 11:31

@joseph.olstad Interesting, I guess most of the clients prefer WordPress over Drupal 11 because of the templating system which is similar to the Drupal 7 templating system and the gutenberg editor which has a lot of components (blocks).

I was tempted to learn WordPress just to score extra work (need the extra money badly), but after seeing that I don't think It's a good idea, I'd rather invest my time in learning something else.

Thanks a lot for sharing this.

Comment #19

joseph.olstad

French

commented 21 July 2025 at 13:59

Wordpress is very successful because they have never orphaned their stakeholders. It's less a technical thing and more of a pragmatic approach to keeping up/staying relevant. They're upgrades have been essentially low risk gradual changes.

Upgrades have been relatively easy since the beginning with Wordpress. That's how they have managed to maintain such a huge install base. (ease of use, low TCO)

With that said, there's been a recent push to slow down the speed of deprecating apis with many/most deprecations having been postponed for Drupal 13.

Should be fairly smooth sailing for us until "13".

Comment #20

danrod

Ottawa

commented 23 July 2025 at 15:43

Going back to the PHP 8.4 support, I created this MR:

https://www.drupal.org/project/page_manager/issues/3536704

No maintainer has reviewed it yet, as for the other warnings:

Deprecated: Drupal\panels\Form\PanelsAddBlockForm::buildForm(): Implicitly marking parameter $request as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/html/modules/contrib/panels/src/Form/PanelsAddBlockForm.php on line 65
PHP Deprecated:  Drupal\panels\Storage\PanelsStorageManager::access(): Implicitly marking parameter $account as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/html/modules/contrib/panels/src/Storage/PanelsStorageManager.php on line 110

Deprecated: Drupal\panels\Storage\PanelsStorageManager::access(): Implicitly marking parameter $account as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/html/modules/contrib/panels/src/Storage/PanelsStorageManager.php on line 110
PHP Deprecated:  Drupal\panels\Storage\PanelsStorageManagerInterface::access(): Implicitly marking parameter $account as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/html/modules/contrib/panels/src/Storage/PanelsStorageManagerInterface.php on line 69

Deprecated: Drupal\panels\Storage\PanelsStorageManagerInterface::access(): Implicitly marking parameter $account as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/html/modules/contrib/panels/src/Storage/PanelsStorageManagerInterface.php on line 69

Deprecated: Drupal\entityqueue\Controller\EntityQueueUIController::subqueueListForEntity(): Implicitly marking parameter $entity as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/html/modules/contrib/entityqueue/src/Controller/EntityQueueUIController.php on line 76

PHP Deprecated:  Drupal\migrate_tools\Routing\RouteProcessor::processOutbound(): Implicitly marking parameter $bubbleable_metadata as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/html/modules/contrib/migrate_tools/src/Routing/RouteProcessor.php on line 26

Deprecated: Drupal\migrate_tools\Routing\RouteProcessor::processOutbound(): Implicitly marking parameter $bubbleable_metadata as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/html/modules/contrib/migrate_tools/src/Routing/RouteProcessor.php on line 26

PHP Deprecated:  Drupal\entityqueue\Entity\EntitySubqueue::access(): Implicitly marking parameter $account as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/html/modules/contrib/entityqueue/src/Entity/EntitySubqueue.php on line 91

Deprecated: Drupal\entityqueue\Entity\EntitySubqueue::access(): Implicitly marking parameter $account as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/html/modules/contrib/entityqueue/src/Entity/EntitySubqueue.php on line 91

PHP Deprecated:  Drupal\layout_library\Plugin\SectionStorage\Library::access(): Implicitly marking parameter $account as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/html/modules/contrib/layout_library/src/Plugin/SectionStorage/Library.php on line 254

Deprecated: Drupal\layout_library\Plugin\SectionStorage\Library::access(): Implicitly marking parameter $account as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/html/modules/contrib/layout_library/src/Plugin/SectionStorage/Library.php on line 254

PHP Deprecated:  Drupal\entityqueue\Controller\EntityQueueUIController::subqueueListForEntity(): Implicitly marking parameter $entity as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/html/modules/contrib/entityqueue/src/Controller/EntityQueueUIController.php on line 76

I believe the fix is already in their codebase for these modules and a tagged release should be coming in the next months, I hope.

I have not seen any other warnings.

Comment #21

joseph.olstad

French

commented 23 July 2025 at 17:01

Answering comment #20, ok I see the need for at least 4 patches there

panels
layout_library
entityqueue
migrate_tools

If they're fixed in the dev branches , have to pull out those patches.

Comment #22

danrod

Ottawa

commented 23 July 2025 at 20:51

Status	File	Size
new	field_group-php84.patch	6.44 KB
new	page_manager-php84.patch	2.59 KB
new	migrate_tools-php84-and-other-changes.patch	85.02 KB
new	entityqueue-php84-1.patch	4.36 KB
new	entityqueue-php84-2.patch	1004 bytes
new	layout_library-php84.patch	972 bytes
new	panels-php84.patch	3.43 KB

I have these set of patches that I've applied on my WxT D11 instance with PHP 8.4 and found no issues so far.

There's some other PHP 8.4 warnings triggered by the field_group module, and I included a patch for that as well.

The entityqueue patch had to divide in two separate files. Feel free to try the patches and let me know if you see any other issues to address.

Comment #23

danrod

Ottawa

commented 25 July 2025 at 18:00

Status	File	Size
new	pathauto-patch-php84-91.patch	9.63 KB

There's also a pathauth patch that needs to be considered: https://www.drupal.org/project/pathauto/issues/3489108

Attaching it here.

Comment #24

joseph.olstad

French

commented 27 July 2025 at 12:31

For the patches uploaded July 23, are those all from dev branches/commits/untagged in waiting? Is there issue numbers that go with? Usually issue numbers in the filename can help.
Ex modulename-php84-3000000-03-and-3000001-02.patch as an example if theres a two in one.
This helps us track where things are and where they have been and where we're going.

Comment #25

danrod

Ottawa

commented 27 July 2025 at 22:10

Status	File	Size
new	field-group-patch-php84-95.patch	6.39 KB
new	page_manager-patch-php84-44.patch	2.59 KB
new	migrate_tools-patch-php84-3411051 .patch	85.02 KB
new	entityqueue-patch-php84-3499532.patch	4.36 KB
new	panels-php84-patch-3534531.patch	3.21 KB

Done, perhaps these could work, if you want the specific commit hash just let me know and I can grab it for you, the numbers at the end of the files are the issue numbers.

Please let me know and I can help grabbing more information

Comment #26

joseph.olstad

French

commented 28 July 2025 at 04:07

Hi @danrod, that's great, now migrate_tools, entityqueue and panels have the issue numbers but still looking for field_group issue number and page_manager issue number (if there is).