🇺🇦Ukraine @Taran2L

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

taran2l → created an issue.

taran2l → made their first commit to this issue’s fork.

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

taran2l → changed the visibility of the branch 8.x-1.x to hidden.

With a post update hook it works as expected. Please review

No, sorry, it does not work like that

taran2l → made their first commit to this issue’s fork.

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?

taran2l → created an issue.

it's here 🐛 Add a BC layer for service argument change Active

taran2l → created an issue.

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

taran2l → made their first commit to this issue’s fork.

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 → created an issue.

taran2l → changed the visibility of the branch 3467485-fix-tests-and to hidden.

taran2l → made their first commit to this issue’s fork.

taran2l → made their first commit to this issue’s fork.

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.

taran2l → changed the visibility of the branch 8.x-2.x to hidden.

taran2l → made their first commit to this issue’s fork.

@mfb thanks for applying the suggestions. I think the result will be different if someone has more than 1 segment for APCu.

taran2l → made their first commit to this issue’s fork.

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 → made their first commit to this issue’s fork.

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 9.5.x to hidden.

Taran2L → changed the visibility of the branch 11.x 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.

Taran2L → created an issue.

@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

What about of moving to the post_update mechanism here, i.e. instead of numbers start using names & just keep the record of the executed ones.
Core can just move to this approach while still allowing numbered updates (mostly for contrib).

Probably, existing post_update code can be reused here. The issues I can think of are: order of the updates and the last removed update thing.

Taran2L → created an issue.

Taran2L → created an issue.

Taran2L → made their first commit to this issue’s fork.

Taran2L → created an issue.

alexpott → credited Taran2L → .

Taran2L → created an issue.

btw, I think when CI_DEBUG_SERVICES: "true", access to the job logs is protected, for example I cannot access logs of this pipeline https://git.drupalcode.org/issue/range-3437346/-/pipelines/154088

Whenever I want to see any details about any job I'm getting

The current user is not authorized to access the job log.

Taran2L → made their first commit to this issue’s fork.

Taran2L → made their first commit to this issue’s fork.

This is a quite huge regression, setting this to critical, a new release is needed

Taran2L → created an issue.

@saurabh rawat, please stop producing patches, and use MR, thanks

So, there is one unresolved threadm everything else has been addressed afaik.

Bot seems to be wrong, latest MR passes everything and it contains latest changes from the core

So, I've converted #59 to a MR, then fixed a few nitpicks.

My idea of modernizing it a bit is not working as expected, so I've given up on that

Please review

Taran2L → made their first commit to this issue’s fork.

hi all,

I've created an alternative PR which follows recommendations from #58 📌 Use form element type instead of Needs work by @dawenher

Fix the bugs we have in core which disallow the usages of buttons
Expose buttons, make it opt in
Discuss later, whether we want it to be buttons by default. Changing the HTML structure there is IMHO a big BC break when you actually would have to deal with CSS and more.

The main difference is that we are not introducing any new form element properties but rather allowing usage of button whenever needed (#uses_button_tag feels weird and unnecessary imo)

The question is how far should we go with that approach as clearly <button> element can do more, and atm it's not possible to achieve that, for example

• Button can be one of 3 types: button/reset/submit
• At the moment submit button does not execute submit handlers, which is odd at minimum
• Button can have separate value (which is handy for the form handling) and label (which is purely UI)
• Button can have elements inside of itself (currently children are being rendered outside)

I would love to address those things here without any changes to the Drupal forms (there is only a single usage of #type => button across all core codebase) so impact of such changes is minimal (as most of the form will still be using input type=submit)

Then in the follow-up we can start converting some form elements from input type=submit to a button leveraging the new features of the latter, like in #17 📌 Use form element type instead of Needs work :

I belive the benefit of going with button is that we can finally remove that type of code from form processing:

if ($request->request->get('op') != $this->t('Preview')) {
And replace is with a more sensible:

if ($request->request->get('op') != 'preview') {
Because the value and the text displayed for button can be different. Granted that is the only use of get op that I could find. D7 is littered with that kind of stuff so I guess it's much less important now.

Taran2L → changed the visibility of the branch 11.x to hidden.