Documentation updates for Drupal 11 wxt

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.

Yesterday I published bootstrap 3.36
Simply do this:

composer up drupal/bootstrap

@danron, normally you should report contrib issues in the individual contrib projects. bootstrap is a contrib theme , has it's own issue queue.

I happen to have published 3.36 yesterday that has those fixes so please upgrade and let me know how it goes.

📌 PHP 8.4 compatibility improved Active

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 target 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

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

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

And I installed WxT 6.1.x last night yesterday, sorry for trying to contribute.

@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?

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

@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.

@joseph.olstad yeah, more people are more 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.

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

Should be pretty easy for those. I'm sure someone will find more though!

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 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.

@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, 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.

@danrod

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

@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.

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.

Upgrades have been relatively easy since the beginning.

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

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

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

https://www.drupal.org/project/page_manager/issues/3536704 🐛 [PHP8.4] Misc null deprecation warning on a few files Active

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 have not seen any other warnings.

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.

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.

There's also a pathauth patch that needs to be considered: https://www.drupal.org/project/pathauto/issues/3489108 🐛 Fix PHP 8.4 implicit nullable deprecation Needs review

Attaching it here.

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.

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

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).

Hi @joseph.olstad, here's the requested information:

field_group: issue # 3504453 : https://git.drupalcode.org/project/field_group/-/commit/0b8365169e8f45cd...
page_manager: issue # 3536704: https://www.drupal.org/project/page_manager/issues/3536704 🐛 [PHP8.4] Misc null deprecation warning on a few files Active - I created this issue but they haven't looked at it yet.

Hope this helps.