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.
Created MR from 56 and added a patch for composer use.
Applies to 11.x and 11.3.x.
kriboogh → made their first commit to this issue’s fork.
Applies to 10.3 and added patch of MR for composer use.
Added MR's for 11.x and 10.3.x
kriboogh → changed the visibility of the branch 10.3.x to hidden.
kriboogh → changed the visibility of the branch 11.x to hidden.
kriboogh → made their first commit to this issue’s fork.
Failing tests due to https://www.drupal.org/project/drupal/issues/3041318 →
Since both patches (#20 and #24) deal with fixing this issue at different stages in the import sync by adding better code checks, I combined both into the MR. Also added the patch for the MR as it stands now to use in composer.
kriboogh → made their first commit to this issue’s fork.
Patches added
MR !9067 is for 10.3
kriboogh → changed the visibility of the branch 10.1.x to hidden.
kriboogh → changed the visibility of the branch 11.x to hidden.
kriboogh → changed the visibility of the branch 10.3.x to hidden.
MR !3209 is for 10.1
MR !9044 is for 11.x
Fixed remarks.
MR!9023 is for 10.3 (patch 127)
MR!7968 is for 11 (patch 124)
Fixed mysql issue with primary key creation on 10.3
Added MR for roll-back to 10.3 and patch.
Add patch for MR!7968.
Fixed phpcs and tests.
Patch for new MR!9018 against 11.x (which also applies to 10.3)
Added patch and interdiff.
I was looking a bit more into the test that is failing (data index 3). The test data uses a non existing bundle id. What happens then is loadContentLanguageSettings initially cannot find the config and then creates a new one for the non existing bundle.
So either a couple of things should happen:
- the test data is incorrect and tries to test a situation that can never happen, being a non existing bundle id and the hasexception flag set to false or
- loadContentLanguageSettings should not create a config for a non existing bundle, and should return null. So loadContentLanguageSettings should check if the entity_id and bundle actually exist?
MR with patch from #58 and fixed remaining issues. Please review.
Created MR with patch from #58.
Let's see if the tests fail or not.
patch for MR
Tests are working now, but someone should have a look at what those test values should do...
Patch of !MR8986 (works on 11.0 and 10.3, 10.2)
kriboogh → changed the visibility of the branch drupal-2868294-10.3 to hidden.
kriboogh → made their first commit to this issue’s fork.
Patch and interdiff for MR95.
Currently MR95 causes a deprecation error, when using >PHP8.2:
Deprecated function: Creation of dynamic property Drupal\entity_share_client\RuntimeImportContext::$tmpEntityJsonData is deprecated in Drupal\entity_share_client\Plugin\EntityShareClient\Processor\LayoutBuilder->prepareImportableEntityData() (regel 59 van /home/fedpol_webplatform/public_html/web/modules/contrib/entity_share/modules/entity_share_client/src/Plugin/EntityShareClient/Processor/LayoutBuilder.php)
kriboogh → created an issue.
I have the same while playing with the groups eco system.
* Install clean D10 (10.3)
* require drupal/group
* enabled "group" and "group node".
* Create a group type (default settings, but check all admin/role related checkboxes for creating groups in this type).
* Allow node content (default settings).
* Create a group in this type (default settings, just a name and a path added)
* Group shows up in the list.
* require drupal/group_sites (default installed config)
* Group is gone (but still works if you goto it's path or group/1 url)
Created a patch with the extra check.
kriboogh → created an issue.
Looks ok for me.
I see in the log you posted, that on some domains it says "already logged in". Maybe some error happens and the login process cuts out. Not sure when I will be able to test this, but I will check if this can cause such a white page error.
On your end, can you logout out of all domains. Delete all cookies for each domain just to be sure. And then try to do a "clean" login (starting from .es domain for example). Just see if it goes through in this case.
If you have access to your webserver or php-access and error logs, may there you can see what error is being thrown.