🇪🇸Spain @rodrigoaguilera

Got included into another MR

Thanks!

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

All my spelling mistakes exposed 😰😅

About page overrides: this breaks the hero. I think is quite prominent and easy to fix so I won't release a new major version, just a minor

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

Sure, very appreciated contribution.

Thanks!

Adding credit

I tried to merge it some days ago but I couldn't. It kept on creating merge trains

Great! Thanks

I think the branch you created doesn't start from the latest 2.x from yesterday.

D11 compatibility is already declared

rodrigoaguilera → created an issue.

Quite similar if you look at the code. extra_field aims more at providing just an API and no implementation, no config form, just examples.
entity_extra_field provides ready-to-use implementations but nothing stops a developer from providing additional plugins that render anything that is possible to render with extra_field.

Extra_field also makes a distinction between form extra fields and display extra field but it feels artificial.

I'm thinking to translate my logic to entity_extra_field to confirm all this.

We can look into moving features from extra_field into this module like the code generators.

From my point of view what is missing is some addition to the module description that links to the views embed comparison → and explaining that it can do much more like blocks, SDC, etc.

Oh, it would be so great if it could also replace EVA → .

I will keep my offering to maintain extra_field, even if only to bring D11 compatibility and eventually recommend this module as replacement.

Yes, vincentlanglet/twig-cs-fixer is a tool with more adoption, more maintained and is more aligned with drupal releases in aspects like phpstan and following symfony releases.

I don't see the failure in the current PR but anyway it needs a rebase.

Just tested manually the patch in a Drupal 11.0.0-beta1 installation and I can confirm it works as expected.
Please roll a release with this patch included

When there is a white screen there is an error message associated. Can you try to configure your site with this debug info enabled so we can determine the problem? Please follow the instructions from the docs https://www.drupal.org/docs/develop/development-tools/enable-verbose-err... →

Please reopen if the issue still occurs

Since extra_field is marked as unsupported I offered to maintain it 📌 Offering to maintain module Active

Maybe someone from this issue has a better idea on how to move forward with some kind of merged functionality of the two modules.

rodrigoaguilera → created an issue.

hook_event_dispatcher has a stable release now. It shouldn't give more problems

So the "next major version" testing failure means that until paragraphs and webform have D11-compatible releases hook_event_dispatcher can't have a D11 release with proper testing?

Have you considered spliting the paragraphs and webform functionality into a separate project to avoid this kind of situation?

I guess eck is just pending removal since is deprecated in 3.x

Regarding #4
I don't know what is required to be able to get the node from the context in the class that needs to be modified.
Maybe use the trait like blockbase does.
https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Plugin%21...

Regarding the patch I think it might still fail as the code is initializing $node to NULL but later is used as $node->isTranslatable()
when it still might be NULL.

I think this issue is becoming relevant again with the rise of LLMs

https://eigenmagic.net/@NewtonMark/112455578857917485

We can close it then. Can you try to use the latest Dev version?

I am on the phone. The code looks good. If you create a MR I can include the change in the repo.

If not I will apply it during the weekend.

Deleting the

core.base_field_override.*.*.moderation_state.yml

worked for me. They were created by saving the content translation form and just like in comment #12 they did not change anything from the defaults so there was no need for an override.

After exporting the config, trying to install the site from that config leads to the error from the IS.

To verify the last patch from this issue I followed the steps from #3399032 with the metatag module and I still see the "meta" fields in the export despite the fact that they are computed.

Maybe I am doing something wrong or something changed in the metatag module in the meantime

Please bear with me as I'm trying to understand.

I think allowing failures for phpcs should be as simple as overriding the job from the include

phpcs:
    allow_failure: false

This should give one phpcs error. Fail the pipeline, proving that phpcs errors are reported and we won't allow more in future MR.
Then fix the actual phpcs error (sorting uses alphabetically) commit the change and make the pipeline green again.

There is a 1.1.1 release now of that rather useless package.

Thank you so much for the effort on this.

Sure. Those are back from the drupalspoons era

I'm not that familiar yet with the default Drupal template for gitlab-ci.
Can you upload a commit that allows phpcs to fail, fail the pipeline and then fix the phpcs error to make the phpcs pipeline green?

rodrigoaguilera → created an issue.

For folks that use patches, the patch from #156 doesn't apply to 10.2.5 so here is one without the phpstan-baseline changes that applies to both.

Just one more confirmation that the patch yields the expected results.
Before: replicas shared paragrahs in non-default translations
After: replicas create new clones of paragraphs for the new replica.

Thanks for the contribution

rodrigoaguilera → created an issue.

I just came across this way of translating the string and is quite different from how Drupal core translates string that are defined in a view.

The t() function should always receive a literal strign defined in code, not through configuration. One of the shortcomings of this solution is that a site can be build in a different language than English and therefore the placeholder won't be an English string. The t() function only receives English strings.

I'll open an issue

Great. Thanks!

rodrigoaguilera → created an issue.

I think is a great opportunity for a 3.0 release that drops support for Drupal 8 and 9

The code looks good to me. The only bit I am missing is some lines in the post_update that enable the new module. Or does Drupal enables dependencies automatically now?

This issue happened to me with facets 3.x and better exposed filters 6.0.3. I'm not sure which one caused it.
I think is quite legitimate to define a prefix without a suffix

Thanks for the contribution

Add a utility module that I created recently.

I proposed a different approach that outputs the suffix as an empty string since the latest patch was not closing the div.

Claro is now in core but it suffers from the same

rodrigoaguilera → created an issue.

Yes, I use the redirect module too.

In my case error logs where not helpful. I had to follow the code.

One more cent: If you use https://www.drupal.org/project/trusted_reverse_proxy →
that priority also needs to be raised to 601, or you won't be restoring any IPs from cloudflare.

Took me a while to arrive to this issue after experiencing broken ajax on sites with cloudflare.

I'm not familiar with the error applying the patch but the fix and the test look fine to me.

I think I can merge it if you add a publishcontent.api.php with an example on how to use it.

rodrigoaguilera → created an issue.

jlbellido → credited rodrigoaguilera → .

rodrigoaguilera → created an issue.

Sure

Please review my the enabling of media library for the linkit widget

rodrigoaguilera → created an issue.

rodrigoaguilera → created an issue.

I was digging on this bug and I came with the same fix as the MR so I think is RTBC

jlbellido → credited rodrigoaguilera → .

Thumbs up!

The MR fixes the access checks but the test deprecations from the comment above still need to be fixed

I understand now. I went with a slightly different solution to have some defaults.

Any steps to reproduce?

I meant to roll a release with the tag but didn't happen. I just added the release

The fix was in the dev version. I just released a new tag

Ooops. I made the git tag but not the release. You are totally right

The above patch did not apply to 9.5.11 installation.

Attached a new version without code changes

I was given maintainership over the media orange logic module that requires these patches
https://www.drupal.org/project/media_orange_logic →

I can't justify the need for the form_state because I haven't study the code yet but here is the reference to the usage of form_state:
https://git.drupalcode.org/project/media_orange_logic/-/blob/1.0.x/modul...

It is kind of a rabbit hole to follow the code but in the end it just gets the values of the media selected.

Thanks

Changing to the proper status if there is no work left to do

Thanks for the info. It made clear that the problem was upstreamable/jsdelivr-api-client
I released the version 1.0.2 that accepts psr/http-message ^2 as a dependency.

This should get us closer to an easier install

I'm reopening because of hook_event_dispatcher not having a stable version yet and that makes this module difficult to install. I accept patches to remove the dependency.

Looks good. Thanks for the contribution

The treaty is a fixed value just like the other treaty formatters and gets applied to all the roles that the contact has.

rodrigoaguilera → created an issue.

rodrigoaguilera → created an issue.

Thank you for the patch.

Waiting for a stable release is my preferred path for this to be resolved but I also accept MRs to remove the dependency.