@catch, in #80 @tim.plunkett has self-assigned this issue and no progress for over a year ... is anyone has a better idea on how to overcome this issue without dependency on the route system?
Per @smustgrave suggestion I've made messages translatable, but this causes unexpected fatal errors in a few tests (I assume sometimes string_translation service is not ready yet/not available, but redirect already happens)
So, I've reverted those changes, so messages are as they are (i.e. not translatable)
However, I've one concern: UrlHelper is a simple class that does not depend on the container at all, and we are adding hook invocation to it.
A few tests are still failing, will take a look later
Addressed feedback by @smustgrave
Converted patch from #3098245-8: Clone nested inline blocks when translating → into MR + updated it after ✨ Fails on translated inline blocks Closed: duplicate got merged.
Went ahead and fixed this .... still supporting 9.5, it's up to you if you want to go like that
thanks for the fast turnaround!
Does not work actually
Blocked by 🐛 Error uploading svg from the media tab Active
taran2l → changed the visibility of the branch 3482121-error-uploading-svg to hidden.
hi @jwilson3
this pipeline shows that it works now with D11 -> https://git.drupalcode.org/issue/svg_image_field-3482121/-/pipelines/403938
I'm removing gitlab CI staff from this one, as there is another one for that already 📌 Make CI green again Active
Should be OK now - no PHP warnings + all validators are preserved
Uh ... it kills the built-in validations now ...
taran2l → created an issue.
hi @dblanken @seanb
I've added FieldableEntityInterface back, the original change is doing a good refactoring, but it out of scope for this issue imo and makes it harder to understand and review (plus it's harder to combine patches)
the conversion to OOP hooks broke this MR, corresponding code should be moved to the class files, I can take a look later this week
I've removed all refactoring to make everything a little bit easier to review and added a BC layer for the service constructor arguments change
With a post update hook it works as expected. Please review
No, sorry, it does not work like that
Green again, I think this can go in ?
thanks @voleger
what about a single php-star-ignore line statement, it anyways will go away with the next major release?
it's here 🐛 Add a BC layer for service argument change Active
@anybody hi
Unfortunately, this is not how this thing should be fixed, as update runs after cache rebuild (usually), so I can't get to that.
Core always adds a BC layer when arguments change, this should be done here as well.
could a new release be tagged?
@catch, updated branch with the latest changes from the upstream (actually a different issues was causing merge conflict), should be good to go now
@anybody, the MR is ready, PHPStan issue in unrelated deprecation, double asterisk in another issue, this is RTBC as far as I can tell
taran2l → created an issue.
There is a typo corrupting existing configs!
It's green now.
I've refactored test a bit to be more robust and support more cases.
Small code update + added a change record. Please review
taran2l → changed the visibility of the branch 3202631-11.x-test-only to hidden.
hi @tim bozeman
Removing content from all fields feels counterproductive, especially for complex components that have conditional logic. Creating an empty sample value generator and changing ALL fields of ALL components to use it an overkill
To be honest, the expectation is an empty form, as core does.
taran2l → changed the visibility of the branch 3467485-fix-tests-and to hidden.
Added a draft change record + concrete module version + fixed PHPunit
taran2l → changed the visibility of the branch issue/entity_print-2860122-2860122-how-to-set to hidden.
@mfb thanks for applying the suggestions. I think the result will be different if someone has more than 1 segment for APCu.
taran2l → changed the visibility of the branch project-update-bot-only to hidden.
taran2l → changed the visibility of the branch 3434099-automated-drupal-11 to hidden.
hi @smustgrave, thanks for the offer, but in general it's D11 ready already (there is no deprecations), the only thing that I want to include is the new field categories UI ... plan to release it this week
Thank for the offer, but I don't think it's needed atm (At least for sole purpose of D11 version)
this requires a follow-up, as now there is a warning with comparing 32 Mb to 32 MB (and the reason is described by @Nikit )
PHP APCu caching
Enabled (32 MB)
Depending on your configuration, Drupal can run with a 32 MB APCu limit. However, a 32 MB APCu limit (the default) or above is recommended, especially if your site uses additional custom or contributed modules.
I would deprecate weight as a follow-up, as it's quite a piece of an extra work
There were reports of the similar behaviour on one of our projects as well, but I cannot reproduce it reliably
Taran2L → created an issue.
Taran2L → changed the visibility of the branch 2969051--patch-rollout--8.x-3.6 to hidden.
@Emircan Erkul there is no point of creating a new MR (unless the current one cannot be updated easily)
Taran2L → changed the visibility of the branch Taran2L-9.2.x-patch-21075 to hidden.
Taran2L → changed the visibility of the branch 3040556-duplicate-entity-source-fix to hidden.
Taran2L → changed the visibility of the branch 3040556-duplicate-create-hook to hidden.
Taran2L → changed the visibility of the branch 3040556-duplicate-entity-source to hidden.
Taran2L → changed the visibility of the branch 3040556-duplicate-entity-source-9.5.x to hidden.
@berliner @aaronpinero creating a static patch from the MR is ok-ish, but continue working on the issue in patch mode - not
@Diwakar07 @Rajeshreeputra just adding all the incorrect words to the ignore list is not the correct solution