🇧🇪Belgium @kriboogh

I would propose to extend the 'spamaway_anti_spam_field_names' option to be a regex and then adapt the code to only (maybe in a first iteration) scan all text/area fields. Maybe then also add a 'spamaway_anti_spam_field_names_exclude' to exclude certain fields.

kriboogh → created an issue.

kriboogh → created an issue.

I added the use of the DeprecationHelper. I left in the class_exists and function_exists otherwise the IDE would complain it couldn't find the class (on D10) or the function (on D11).
This module is also only going to support 10.3 (I need to update the info.yml for this in another issue).

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

kriboogh → created an issue.

thanks for the update.

Just pitching in here, we now have navigation_extra_tools support in our navigation_extra module. It allows you to place the links under the "drupal" logo as it was with the toolbar version. We can add the option so you can put them under the "user" menu too.
Our navigation_extra module is currently still in dev only, but we are working on a stable release.

This options is provided by core itself (choose "Custom")

Tested the install of the module on 10.3, 10.4 and 11, I don't get this error. Please provide more info on how to reproduce.

kriboogh → changed the visibility of the branch 3473023-fix-the-issues to hidden.

Still a small phpstan issue, no biggy.

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

Added local tasks plugin. This mimicks the behavior of gin_toolbar_local_tasks.

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

yes

kriboogh → created an issue.

kriboogh → created an issue.

kriboogh → created an issue.

kriboogh → created an issue.

kriboogh → created an issue.

Fixed in latest dev

Fixed in latest dev

Fixed in the latest dev.

Development on this module has stopped, since D11 uses a new navigation bar.
I'll refer you to our other D11 module (navigation_extra) currently in dev version, which is a rewrite and replaces this module to be used with D11's 'nagivation'-module.

Since there was no response and alternatives are provided lets close this.

I added the langcode of the original referrer route to be passed along the login chain so that in the end the redirect url can be translated into this language. This eliminates the extra redirect.

This has been in place several months now in the stable release. If this still happens in your case feel free to re-open.

kriboogh → created an issue.

Temporarly fixed by fixing the settings form with the new create parameters and using the same template as the core module. Should be looked at properly to make this module up-to-date to the latest core version.

Hi, if I understand correctly you have:

Language negotiation on domain level set to:
www.dutch.com => NL (alternative language)
www.english.com => EN (default language)

You have a custom controller route:
/some/controller/english

A path alias:
/some/controller/english => /some/controller/dutch (langcode NL)

Multidomain success url is set to:
/some/controller/english

When you login from EN domain you get:
www.english.com => www.dutch.com => www.english.com/some/controller/english

When you login from NL domain you get:
www.dutch.com => www.english.com => www.dutch.com/some/controller/english

But you expected:
www.dutch.com => www.english.com => www.dutch.com/some/controller/dutch

Correct?

Should be fixed now.

Applied your patch.

Module name updated.

The exception bug is fixed. See also https://www.drupal.org/project/simple_password_policy/issues/3454616 🐛 Password policy bypass for admin not working Active for explanation on the permission settings.

The exception bug is fixed (other issue).

I also added an extra note in the module's readme on how the "bypass password policy" is supposed to be interpreted.

When you assign this permissions to a role, it doesn't mean that this role can create users with a password not following the policy. It means users who have this permission, their password is not validated. The validation is done on the actual user being created, not the current user creating the new user.

So in order to create users as an administrator, who's password is not suppose to follow the policy, you simple apply a role with this permission to that new user .

kriboogh → created an issue.

kriboogh → created an issue.

Maybe this isn't the ticket to mention this, but when

SessionConfiguration::getOptions is called we do:
$options['cookie_domain'] = $this->getCookieDomain($request) ?: '';

A few lines after we do:
$options['name'] = $this->getName($request);

=> getName calls getUnprefixedName which in turn depends on $this->options['cookie_domain']:
elseif (isset($this->options['cookie_domain'])) {

but at this point $this->options doesn't have cookie_domain key, since we are using a locally scoped variable $options in the getOptions call.

I think this a duplicate of #3303145

"But I don't see anyway of doing that with the current code as it does not contain the host entity anywhere..."

I was looking at the code for this a bit. From the submitForm methods you could pass the section_storage context 'entity' which is assigned to $layout_entity (this is the node being edited) and pass that to the deepClone methods. There you can then use the $layout_entity->getLanguage()->getId() to set the langcode.

Also then set the langcode on the section being create or updated before the $section->save in the submitForm code after the cloning has been done.
$section->set('langcode', $layout_entity->language()->getId());

I will try to cook up some patch.

kriboogh → created an issue.

Added patch of MR8 for use in composer.

Re-worked the behavior attach a bit, cleaned out the functions and removed the cloneNode call which caused the Ajax callback being removed from the form element.

kriboogh → created an issue.

Follow up: We were still having issues on a site by this. The problem was the site has only one language (NL) which is also the default language. I'm now trying to also have English installed and set EN as the default language. This will force config to be EN. I updated the updb hook above to swap and fix config translations (see attached file). The only downside now is that what used to be a single language website, now has two languages (NL and EN). We installed disable_language module to hide EN in the site. Also this module needs a patch to also hide the disabled language in translation overview.

Again disclaimer: To anyone else reading this, this is specific project code given as an example, do not run this blindly on your production site !!!

Would be better in my opinion if this is just part of the main module. One module to install, cleaner.

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

Yeah I was looking into this, because of some issues we have regarding locale messing up config translations. In my opinion, core shouldn't redefine default config into the default language (if different from EN, but rather store all config in English (source) and use language overrides as translations. Now it just seems like a mess :-) I came across your module when looking into how Symfony does its translations and then wondered why drupal just doesn't do it that way... But I guess locale is too tangled up in core to really leave it out.

Ok nice, will check it out. Thanks for the quick reply ;-)

kriboogh → created an issue.

Patch didn't apply to alpha5, updated it.

Added the patch for the MR!180 as it stands now to use in composer.

Hi Dave (@DYDave), that should do it yes (tested that a couple of minutes ago). In the mean time I override the getDescription method in our subclass and check it also. The fix for that is in our 2.0.9 release.
But your fix to that line you mentioned would make the code more robust.

Added a workaround, although discussion is ongoing in admin_toolbar to provide a fix there.
See https://www.drupal.org/project/admin_toolbar/issues/3465604#comment-1572... 🐛 TypeError: method_exists(): Argument #1 ($object_or_class) must be of type object|string, null given Needs review

Changed css rules in 2.0.9.

Maintainer of admin_toolbar_content here. I can confirm that our module is causing an issue with the "recent content" menu items. The getDescription method is expecting an entity which in some case isn't the case for the recent content items. I will add a workaround for this, but I really think for good measures that in admin_toolbar, there should be a check on the $this->entity being not null for the getDescription method, since you also do it for the getTitle.

Update of MR patch reflecting last fix (remove double status key in config).

Added patch of MR for use in composer.

Added patch of MR for use in composer.

Added patch of MR for use in composer.

kriboogh → created an issue.

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

Please review the branch https://git.drupalcode.org/issue/entity_share-3350213/-/tree/3350213-fix... it should fix most if not all issues reported by phpstan. It's got a lot of changes, maybe run it through cilab to see the state of it.

Added patch of MR for use in composer.

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

Added patch of MR for use in composer.
Applies to 10.3.x

Fixed a spelling error so tests could run.

Created MR for 11.x based on patch from #42.
Added patch of MR for use in composer.
Applies to 11.x and 10.3.x.

Created MR from #3 on 11.x
Added patch from MR for use in composer.
Applies to 10.3.x and 11.x

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

Added patch of MR5230 for use in composer.
Applies to 11.x and 10.3.x

Rebased MR for latest 11.x
Added patch of MR for use in composer.
Applies to 11.x and 10.3.x.

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

Create a MR based on #72.
Added patch of MR for use in composer.
Applies to 11.x and 10.3.x.

Added patch of MR for use in composer.
Applies to both 11.x and 10.3.x

Added a MR based on the patch from #2.
Added patch of MR for composer use.
Applies to 11.x and 10.3.x.

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

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

#22 Also applies to 10.3.x

Corrected MR from latest 11.x.
Added patch for composer.
Applies to 11.x and 10.3.x.

kriboogh → changed the visibility of the branch 2880011-add-a-disableinlineformerrorssummary to hidden.

Created a MR from patch #107.
Added patch for composer use.
Applies to 11.x and 10.3.x.

Still some weird error is happening with the use of "withConsecutive" (which the MR solves, but phpstan still complains about...)

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