yes thanks, the ai_ollama_provider works well, I tested it last week!
Also, I'm hesitant to move forward on this until 2.0.1-rc1 becomes 2.0.1 . Currently I see zero usage on 2.0.1-rc1 so I will be waiting a while yet.
hmm, looks good however I have no cycles to test this or to confirm the approach at this moment.
I'll let this simmer and see how many others start using it.
I had a look at this last week in a build, possibly no longer using this. I couldn't find it in my builds.
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).
joseph.olstad → created an issue. See original summary → .
I might suggest that restarting the php8.3-fpm or php8.4-fpm service and if using reddis or keyval , restart those also could possibly be an alternative fix. However I haven't actually seen this exact error occur before.
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.
joseph.olstad → created an issue. See original summary → .
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.
Hmm, yes and now for Drupal 11.1.8 and 11.2.2 please!
ok I see, the extra parameter was added to be optional. I'll give time for folks to test this and see how they like it.
Great work @dvyansh.gupta, with that said, I'm seeing api changes, some concern that these changes would possibly break other modules that require toc_api such as toc_filter.
Wondering if there's a way to build this with compatibility in mind and keeping disruptions very low.
would be great to get some extra eyes and brains on this.
Hi Rumens, thanks, ya I ended up doing that for the deepseek module. It was similar.
With that said, drupal cms 1.1.x out of the box has a stable stability requirement so a lot of those folks are not technical enough to surmount this issue or could not be bothered.
Brought in the D11 compatibility fix from 🐛 D11 construct error Active
This patch should resolve the issue.
https://git.drupalcode.org/project/book_pdf/-/merge_requests/10.patch
🐛 Exception when used with contrib book Needs work
joseph.olstad → created an issue.
joseph.olstad → created an issue. See original summary → .
Thanks
Thanks
There's a pre-release version available. Once I see some usage statistics on it next week I'll evaluate the possibility of tagging 2.0.1
https://www.drupal.org/project/toc_api/releases/2.0.1-rc1 →
PHPUnit tests are failing and are more important than phpcs and phpstan
@heddn, why are you working on 8.x-1.x ?
@phanaproxima did a lot of work which was all pushed into 2.0.x
@heddn, why was this merged into 8.x-1.x ?
2.x-dev has had a lot of work gone into it.
@heddn, why was this merged into 8.x-1.x ?
2.x-dev has had a lot of work gone into it.
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".
I prefer ✨ Consider to make configurable the entity type on which enable entity print Needs work
However let the maintainer weigh in.
Thanks!
@heddn, great work, seems like you've pushed things further along!
@waropd
My groups have been using:
layout_builder_st dev-2.0.x with a bunch of patches that have recently been merged.
🐛
Contextual links for translation are removed by core
Active
🐛
Error: Call to a member function getConfig() OverridesSectionStorage.php
Active
and
🐛
Error: Call to a member function getConfig() OverridesSectionStorage.php
Active
All of which have now been merged
Looks like @heddn is doing some great work here. Cheering on @heddn to be soon ready for a tagged release.
Hmm, ok strange so you've fixed the Drupal 10.4.x testing somehow.
However Drupal 11 testing results is curiously vastly different. Perhaps since it's testing against 11.x-dev instead of 11.1.8 or 11.2.2?
If we're testing off of 11.x there is a higher chance of seeing turbulence when compared to say testing against 11.1.8 or 11.2.2.
The Drupal 11 pipelines show 14 failures in the most recent run.
Not sure if this is of any help however we have been successfully using layout_builder_st dev-2.0.x 68f690c8fb with Drupal 11.1.8 extensively with this concoction of patches:
"drupal/layout_builder_st": {
"3411037 - Fix core removing contextual translation links": "https://git.drupalcode.org/project/layout_builder_st/-/merge_requests/5.patch",
"3420063 - Call to a member function getConfig() OverridesSectionStorage.php": "https://git.drupalcode.org/project/layout_builder_st/-/merge_requests/6.diff",
"3069964 - Null fix for moderation dashboard, otherwise WSOD on login": "https://www.drupal.org/files/issues/2025-01-02/3069964-null-fix.patch"
},Others outside of my groups have builds with layout_builder_st dev-2.0.x with a variety of patches applied and using Drupal 11.1+
Wondering why Drupal 11..x-dev testing would suddenly show 14 pipeline failures. Previously there were 3 with 22 skips, maybe because now there's only 21 skipped? Maybe the non-skipped test has a lot of failures now that it's no longer skipped?
Prior to recent changes;
Tests: 38, Assertions: 1100, Errors: 1, Failures: 3, PHPUnit Deprecations: 1, Skipped: 22.
https://git.drupalcode.org/project/layout_builder_st/-/jobs/5051465
Latest pipeline run:
Tests: 38, Assertions: 98, Errors: 14, PHPUnit Deprecations: 60, Skipped: 21.
https://git.drupalcode.org/project/layout_builder_st/-/jobs/5051465
Pipeline is all green.
Thanks!
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.
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!
@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.
I hit this also with a 24.04 LTS server. It will only become more frequent.
/usr/sbin/sendmail -t should likely be the default instead of -bs
Not sure if it makes a difference however I am using postfix, so the sendmail command is essentially a wrapper for postfix.
The 2.0.1+ releases currently support >= D10.4 and >=D11.1
Changes introduced in 2.0.1-rc1
- 📌 Set 10.4 and 11.1 as minimum supported releases. Active
- 🐛 Fix empty render context Needs work
- 🐛 Unable to use config_translation to translate most toc_type entities Active
- 🐛 Undefined array key "class" in template_preprocess_toc_tree() in toc_api.module Active
- 🐛 Webform TOC Submission Issue Active
- 🐛 Layout builder fatal error Active
- #3264056: How to build a TOC block? →
joseph.olstad → created an issue.
adding credit
Actually, still looking into this, maybe was too hasty.
This is already fixed in toc_api 2.0.x
Please upgrade to 2.0.x
This will not be fixed in 8.x-1.x
creditting
Ya I suppose, maybe it is time to start testing 8.4, I can easily do this in my environments.
creditted dejan.maric.max and socialnicheguru for their work in the related issue.
@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?
Reported as fixed in 2.0.0
Would be best to wrap the normal processing logic/call in a try/catch, perform normal processing in the try, and if there's mangled html catch the exception, log it in the dblog so that people know about it, ideally it would be optional to auto-correct faulty html so add a configuration option for this and ONLY autocorrect the faulty HTML if you've first logged that an exception due to faulty html has occured and conditionally based on the configuration option value then and only then do the autocorrection.
The folks at zend should take strong medication for their addition to deprecations.
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
@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
Yesterday I published bootstrap 3.36
Simply do this:
composer up drupal/bootstrap
joseph.olstad → created an issue.
There is no need to make a new branch.
All we have to do is change entity_print.info.yml
from
^9.4 || ^10 || ^11
to
^10.4 || ^11.1
Composer will then ensure that running ^9.4 or 10.0/10.1/10.2/10.3 will get the most recent release that has
^9.4 || ^10 || ^11
Everyone with 10.4 || 11.1 will get the fix that we publish in a new release. There's no need for a new branch to protect someone with 9.4 or 10.0
Creditting
crediting for fix
Thanks @hosterholz!
There's a single failure in the latest pipeline run for 4294 for testTranslateOperationInListUi
Would be good to get this one past the finish line.