The MR doesn't fix the problem when installing/uninstalling modules which only add a sub menu item e.g. "User interface translation" for locale module.
The keys of the array do not change, so the hash does not change either. Maybe the installed modules list should be in in the hash input, too?
Rerolled
Rerolled and removed not matched ignoreErrors
Rerolled, added context in several cases, added default to config and added default to tests
Rerolled
Rerolled
sleitner → made their first commit to this issue’s fork.
sleitner → made their first commit to this issue’s fork.
sleitner → created an issue. See original summary → .
Upstream issue: https://github.com/symfony/polyfill/issues/535
The PHP intl extension is compiled into PHP in the docker image. If the PHP intl extension should be optional, the base docker image has to be changed to install intl with pecl.
I compared the composer.json ext-* requirements and the extensions installed in the gitlab docker image. There are many PHP extensions installed that are not listed as required by core and its dependencies. Doesn't this lead to potential post-installation problems on systems that don't have the usual large number of PHP extensions installed? If the PHP extensions are only suggested,, they should be disableable for testing.
I don’t think we need to do anything in the templates for this case. Hopefully the above links will help you achieve what you need.
An automated test for both cases is a precondition for the merge of this kind of core issue. Maybe an addional image is necessary for the additional test.
sleitner → created an issue.
I don't think it's necessary because drupal/core is a dependency, but maybe better safe than sorry.
sleitner → changed the visibility of the branch 3532187-composer-issue-when to hidden.
I wonder when (root)/composer.json for drupal/drupal is involved in install or update? I still have the problem that phpcodesniffer-composer-installer 1.1.0 is installed when updating to drupal 10.5.1 with composer.
Shouldn't the conflict setting be placed in core/composer.json for drupal/core?
Users may set their own time zone OFF does not mean that the website timezone is used, the users simply cannot change the settings via UI. I assume there was a different timezone set. Now the user time zone defaults to website timezone if user timezone is not configurable. Please review MR
Breaks all my sites. Only workaround is go back to 10.4.8 or 11.1.8
Any news on this update? When can we expect a D11 compatible tagged version?
Any news on releasing a tagged Drupal 11 version?
Please merge and release a taggged version
@vasyok : I cannot reproduce this issue, if I set the time manually to 31.3.2025. Which system timezone and user timezone are you using? Which field type is your date field?
sleitner → created an issue.
sleitner → created an issue.
@leon kessler , @rodrigoaguilera : any news on this issue?
Another field_group plugin was blocking the update not field_group_as_class
sleitner → created an issue.
Functional tests are green with Drupal 11 and Field_group 4.0.0
sleitner → created an issue.
sleitner → created an issue.
I could reproduce it locally. It was a problem on top of the timezone problem with the mapping of the current date to the dates in the pager. Please test and review 🐛 Paging seems to be done using UTC and not local time zone. Active
Now fixes the problem with some special dates e.g. March 31th, please review
Could you reproduce this on a new Drupal installation, e.g. on simplytest.me ? Do you patch something in date_pager? Or Javascript changing content in frontend? What is the URL in the false 05 link?
I couldn't reproduce it with the steps given above on simplytest.me.
Any idea how to test the fallback to symfony/polyfill-intl-icu ?
I think this is also UTC / local time zone related
Please review the related issue
sleitner → made their first commit to this issue’s fork.
sleitner → made their first commit to this issue’s fork.
@kkonuhov: Any news on this update? When can we expect a D11 compatible tagged version?
@daften, @nick_vh, @nielsaers, @reszli: Any news on this update? When can we expect a D11 compatible tagged version?
sleitner → created an issue.
@rené bakx : Any news on this update? When can we expect a D11 compatible tagged version?
I'm not 100% sure, but I think that the reason for this is that all dates are handled as UTC in date_pager . German summer time is +2
@dark05 I think you have to take a look at https://github.com/mglaman/composer-drupal-lenient/
That is normal behavoir. The patch does not update metadata in composer or packigist, which composer update uses.
@acbramley : Test manually or automatically? Manually: "View live preview" via Tugboat next to the MR on the top of this issue page. In the tugboat PHP intl extension is not installed, at the moment. Same in Simplytest.me
@bnjmnm, @davidhernandez, @lauriii : Please release a new tagged version which is Drupal 11 compatible
Fixed the problem in MR11697 and tested it here in tugboat. Please review.
It turned out that my intl free test environment had still intl installed.
Tested the patch against 11.x manually on simplytest.me (where 11.x fails without patch) . Please review
sleitner → created an issue.
Rebased. What else needs to be done before the merge?
Please review MR
sleitner → made their first commit to this issue’s fork.
The date range was set too late, after the filter was applied. Please review the MR
@phjou , I could reproduce the issue
Rerolled
Did you try the latest MR? The attached patches are outdated.
joachim namyslo → credited sleitner → .
Duplicate of #3433824
Duplicate of #3433824
Duplicate of #3433824
Duplicate of #3433824
Duplicate of #3433824
Duplicate of #3433824
Duplicate of #3433824
Duplicate of #3433824
Duplicate of #3433824
Duplicate of #3433824
Duplicate of #3433824
Duplicate of #3433824
Duplicate of #3433824
Duplicate of #3433824
Duplicate of #3433824