🇧🇪Belgium @RandalV

I was looking for this functionality as well.
We have a website that has pricelists 'linked' to a value on the user entity.

We import our pricelists from an ERP, and we've worked around this issue by hooking onto the user & pricelist insert/update events.

Pricelist on insert/update:
- Find all users with the custom value and attach them to the customers field
User on insert/update:
- Remove the user from pricelist(s) with the old value (if applicable) and add to pricelist(s) with the new value

The main problem here is that, if no users have the value of that pricelist, the pricelist applies to EVERY user. That's something that conditions would have easily solved.
In our use case, we've solved this by creating a 'dummy' user and if no other users apply for the pricelist, we attach the 'dummy' user to the pricelist.

Configuration/development wise this would have been much faster and cleaner if we had conditions, but I understand the argument of speed is a factor here too.
I'll set this as postponed, it's not and hasn't been really an active issue and if the need arises later on it can be reopened.

Ah.. my bad, you're absolutely right. I overlooked the default value of the class property.

I'm not sure if a backport to 1.x is still necessary, I suppose it depends on how long 8.x-1.x will remain supported? If it will, then maybe it would be good to have that fix there too 😇

Hi @mably, apologies, I hadn't seen that!

Although if I'm not mistaken that doesn't entirely fix the issue I was experiencing, because the encoder will still not strip tags or trim strings unless a setting is specifically provided (whereas before it would strip/trim by default).

With the fix currently in the 2.x branch, the warning message is gone, but if the encoder is used in Views Data Export it'll still let any and all HTML through (without the possibility of configuring it otherwise 😞).

It would be easily solved if encoders allowed configuration forms, but since (I think?) they don't, would it be preferred to keep the old functionality intact?

I've created an MR that adds default values. This preserves the behavior pre-#3108301.

randalv → created an issue.

Hi @mably and @dejan0,

Thanks for your solutions! I've tested the MR, and it seems to work fine for me.

randalv → created an issue.

I haven't got the time to fully debug this in facets itself, but in my case it was solvable by rendering it in a custom block like below.
I had to render in a custom block anyway because I wanted to add extra items before and after the exposed filters, so this was a quick fix for me.

/** @var \Drupal\views\Plugin\Block\ViewsExposedFilterBlock $plugin_block */
$plugin_block = $this->blockManager->createInstance('views_exposed_filter_block:events-overview');

// Make sure the facets are populated.
$view = $plugin_block->getViewExecutable();
$view->preExecute();
$view->execute();

return [
  // ...
  'filters' => $plugin_block->build(),
  // ...
];

I'm also experiencing this issue in a new project of ours using Facets 3.0.0-beta4, exactly as described above.

On the view page itself, everything is fine. Anywhere else, all the facets are empty :(

I'll see if I can find anything, haven't had the time yet to debug.

Drupal 11 compatibility is already implemented.

Hi @mitsuko,

I'm not entirely certain what the case was anymore but when I built this module, I ran into some strange behaviour when the authenticated role wasn't present.
I could test it again, but I figure it's not really important anymore.

In any case, the reason you didn't run into any such incidents is because with your patch, behind the scenes the module would still apply the authenticated role (even if you didn't select it) in the submit handler.

I think regarding the validation, we shouldn't worry about that anymore. Before it was deliberately made impossible to leave the role selectbox empty, so we had to double check in the validator to see if people didn't get around HTML validation and leave it empty anyway.
But since we now want it to be left empty when required, we don't need that extra validation anymore.

Any extra roles that are added through the inspector will also fail the form, since Drupal automatically handles that as invalid input as it wasn't in the form element's `#options` array.

It's been released in 1.0.18.
Thanks for your suggestion!

Hi @mitsuko,

I see your point, it would be useful to only masquerade as the authenticated role, however I think I'll fix it somewhat differently.

The authenticated role *should* always be selected, so removing it from the automatically selected roles might produce strange results.
I'll just remove the 'required' parameter from the roles selector, leaving the field empty will result to only the authenticated role being enabled.

That should cover every use case.

I'll reopen this since the fix hasn't actually been released yet, nearly 2 years later.

@Maintainer, could you please release a new tagged version with this fix present? Thanks!

I can confirm the MR applies to 1.25.

I now get the aria-label="Cookie privacy banner" parameter in the popup's HTML tag.

(PS. Let's keep working in the MR -if anything needs to change- rather than attaching patches)

Please, feel free to review.

This fixes the issue of terms always being rendered in their default language, rather than the current language.

randalv → created an issue.

Thanks for the patch/MR.
I've applied the MR diff to one of our sites, and the issue has been resolved.

Hopefully this finds its way into a release 🙏

That's a very interesting development... an array containing the serialized content with `50` as its key, thanks for sharing @mahde!
I'll debug some more too and see if I can reproduce it somehow.
I also notice it adds both roles twice, interesting!

Hi @mahde,

Thanks for taking the time to debug and updating the MR!
This brings us back to my comment in #5 🐛 TypeError_: unserialize(): Argument #1 ($data) must be of type string, array given in _unserialize() Postponed: needs info though, there's only one piece of code in the module that updates the user data for roles, and it always serializes it..
I don't understand how it could possibly contain an array unless some other module messes with it 😓

I'm sorry guys, I've tried debugging this but nothing seems to point to an error 😓

Could you perhaps provide me with a list of contrib modules currently in use?
That way I could test with those, maybe one of them triggers something malicious in msqrole.

PS. I did fix some little bits here and there in the latest release, in the D11 compatible version there were some regressions, but none of which should have caused the main issue raised here.
The "access denied" error you mentioned, @mahde, should be fixed though.

Hi @mahde,

If you could also please provide more information on how to reproduce this bug, we could move forward with this.
Currently on a fresh install of D10/11, nothing of the sort seems to happen..

Thank you!

Hi markconroy,

Thanks for reporting a possible bug.
Could you provide a little more information on how to reproduce this error? I don't seem to get this on a clean install.
Any contrib modules that might interfere?

From what I can tell, the unserialize function in the below piece of code should only be run if the data isn't empty.

    if (!empty($this->getData($uid, 'roles'))) {
      $data = unserialize($this->getData($uid, 'roles'));
    }

However, it should be impossible for this data to be anything but a string, since it's only set by one function (the below code) and that code serializes the value before committing it to the DB.

  public function setRoles($uid, array $roles) {
    return $this->setData($uid, 'roles', serialize($roles));
  }

Hence why it sounds like some external source might be messing with the msqrole user data 🤔

PS. While the MR seems just fine, it simply shouldn't be needed.. Hence why I currently see that check more as unnecessary clutter, so I'd prefer to be able to reproduce it and perhaps fix it in a different way 😇

Kind request for the current maintainer of this module to grant this person co-maintainership.
I see there's no longer any supported version, while this is definitely a useful feature.

Thanks in advance!

@ozin MR updated according to the last patch provided by @Dylan Donkersgoed.

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

Hi @remoschneider,

Please, refrain from posting a patch that isn't functionally brought up to date.
The patch you posted applies, but is buggy due to the lack of the 'getPluginBlockId'-method in the InlineBlockEntityOperations class.

I'll post a patch that is functionally in line with the old one, if someone wants to turn it into an MR.

@alexpott

* MR applies cleanly to 10.3.x
* Done some tests and the results are as expected:
* Same hash salt -> same session cookie name
* Different hash salt -> different session cookie name
* Can stay logged in across all subsites of a multisite on the same hostname with different hash salt
* Giving all subsites the same hash salt has the expected behavior of being logged out when visiting a different subsite

Seems ready to me! Thanks for the MR.

Rerolled #41 against 10.3.x

Hi @google01,

Merge request definitely applies to 10.3.x.

The contents of this: https://git.drupalcode.org/project/drupal/-/merge_requests/5373.diff
Should be downloaded and placed in a local folder (e.g. YOUR_PROJECT/patches/core/3091336.patch), make sure there's an empty line at the end, and then add `patches/core/3091336.patch` in your composer patches list.

Could a maintainer please take a look at this issue?
It doesn't change the module's initial installation state, and it adds a lot of possible functionality.

I think this could really spearhead this module's already superb usefulness.

Is there any progress on this, or any way to circumvent this and move forward?
Recipes are included in 10.3.x, I feel like the priority of solving this should be a little higher now.

I can't seem to get it fixed myself, other than patching core and removing the functionality entirely, but that seems a little nuclear...

On the other hand, I personally do think that this copy functionality should be removed.
It definitely doesn't make much sense to copy blocks from one theme to another, given that regions could be entirely different.

Thank you for your patch, alecsmrekar, it seems to work.

It seems to work, but I am however unclear on why this issue pops up at all. why is the `layout_builder.move_block_form`-route being triggered when the arguments clearly call for the `layout_builder.move_block` route.

I'm wondering if changing the path for one of the two routes would be a more stable solution?
Two routes with very similar paths and arguments, that seems like asking for trouble to me.

Perhaps all non-publicly accessible routes (like ajax routes) should get some prefix, for example.

Thank you for your fix, Anmol. It's been committed and released.

The fix looks good at first glance, but please leave issues in needs review until the maintainer has actually committed the changes.
I'll try to do this ASAP.

RandalV → created an issue.

Merge request added.

RandalV → created an issue.

The problem seems to be that in file core/modules/field_ui/field_ui.module,
The $form['field_storage']['subform'] doesn't seem to exist, in the function below.
I don't know what the correct solution would be.. I'd say the form still needs to be alterable, and we still need to trigger the alter hooks on the bottom.

/**
 * Implements hook_form_FORM_ID_alter() for field_config_edit_form.
 */
function field_ui_form_field_config_edit_form_alter(&$form, FormStateInterface $form_state) {
  if (!isset($form['field_storage']['subform'])) {
    return;
  }

  $field_config = $form_state->getFormObject()->getEntity();
  assert($field_config instanceof FieldConfigInterface);

  $form_id = 'field_storage_config_edit_form';
  $hook = 'form_' . $form_id;

  $field_storage_form = \Drupal::entityTypeManager()->getFormObject('field_storage_config', $form_state->getFormObject()->getOperation());
  $field_storage_form->setEntity($field_config->getFieldStorageDefinition());
  $subform_state = SubformState::createForSubform($form['field_storage']['subform'], $form, $form_state, $field_storage_form);

  \Drupal::moduleHandler()->alterDeprecated('Use hook_form_field_config_edit_form_alter() instead. See https://www.drupal.org/node/3386675.', $hook, $form['field_storage']['subform'], $subform_state, $form_id);
  \Drupal::theme()->alter($hook, $form['field_storage']['subform'], $subform_state, $form_id);
}

Hi frederiko_,

Certainly!
Editing the "body"-field will lead you to a URL like:
/admin/structure/types/manage/page/fields/node.page.body

Replace the last part (the field's machine name, in this case 'body'), with the locked field's machine name, for example:
/admin/structure/types/manage/page/fields/node.page.layout_builder__layout

And it'll give you the WSOD.

RandalV → created an issue.

Thanks to #9 and #16, I can confirm that adding the "wrap"-item even as the last item on the bar is a solid workaround until a permanent fix can be provided.
It wraps the excessive items neatly on a second row (as was the behaviour in CKEditor4 if I'm not mistaken).

I'm closing this issue, it's been committed to the next release and it seems to work fine.

It would be nice if this could be committed.

I'm unable to upgrade right now due to this issue, I'll take the module out of composer and put it in custom for the time being until this is released.

In general, the composer.json file seems to lack behind the info.yml file?
In the info.yml file, drupal 10 is supported.. But in composer.json, it's not.

I added a fix for the non-scalar value problem that relates to this issue.

I can't seem to create a merge request from the issue fork though... Hopefully you can?

Can confirm I also still get this, I'm using the google_tag module and in Context (any) the value was: *

Simply removing * and leaving it empty works for me, but that won't work for anyone using a value like: generic_name_*

Latest commit moves the responsibility of escaping the search result labels to the controller, rather than every plugin having to do it separately.
This also ensures any results added through the (perhaps deprecated after introducing the plugin type?) coffee_commands-hook.

Thank you for reporting and fixing the issue 🙏🏼 🙏🏼

I pushed it, and released 1.0.14 containing this fix.

I altered the default config so it's identical to the current situation for the end user.
Extra plugins (content + people) can be enabled and configured afterwards.

MR wasn't mergeable anymore due to added commit: https://git.drupalcode.org/project/coffee/-/commit/371eadfd13e34d053aba9...

This has now been fixed.

RandalV → created an issue.

Patch attached that fixed the issue for me.

RandalV → created an issue.

@phjou Strange, if you use `.diff` instead, then it does work.
https://git.drupalcode.org/project/quick_node_clone/-/merge_requests/22/...

Make sure to add an empty line at EOF, though.

Sorry for the delayed response.

Thanks for giving a good start on the merge request, I did have to alter some more stuff (removing the dependencies on token etc).

I added a new tagged release (1.0.13) that should fix this!

Also noticed this issue on a 10.2.x site.
Copied the diff locally, used it as patch with composer -> it works!

Hi @hmdnawaz,

See the warning on the main module page, due to some mishaps in compatibilities, version 1.1.x of the module is still installed on 9.5.x installation but this should not be the case.

If you're working on 9.5.x, you'll have to use version 1.0.3 of this module.
composer require 'drupal/fileslog:1.0.3'

See also:
💬 Declaration of FilesLog::log(...) must be compatible with Drupal\Core\Logger\RfcLoggerTrait::log(...) Fixed

The title of that issue wasn't representative of the actual issue, I've changed it now to the above.

Changing metadata

Hi @hmdnawaz,

Could you tell me what Drupal and PHP version you're working on?
Sadly some compatibility issues arose with later versions of fileslog in combination with earlier PHP versions.

See the module page warning:

WARNING: Version 1.0.3 is the last one that is compatible with Drupal 9! Version 1.1.x should be used for PHP 8.1 + Drupal 10.
Apologies for the mishaps in versioning, 1.0.4 shouldn't have existed in that range and 1.1.x should not be compatible with 9.5.x according to composer.

Hi @smustgrave,

Thank you for the report.

Sadly, renaming the service would partly nullify this module's functionality.
We need to override the account proxy object so the active roles are taken into account by anyone addressing the `current_user` service.

If we didn't do this, calling \Drupal::service('current_user')->getRoles(); would just return the configured roles for that user rather than the roles selected in Msqrole.

Currently, the token service is used in msqrole.manager to allow for tokens in the custom cache tags to be invalidated.
Maybe this is not needed, the less services we can have msqrole.manager depend on, the less situations could lead to circular references.

So essentially I see two possible solutions..

1. Remove token dependency in the msqrole.manager service (and perhaps more if possible)
2. Don't add the msqrole.manager service via the service arguments in the overridden `current_user` service

I do not have the time right now, but I'll do some testing to see what works best performance wise etc, and will push a solution ASAP.

RandalV → created an issue.

@Tregonia feel free to take it for a spin and see how it feels.

Either way this will probably be committed in the next release, but I'd rather someone test it out first.

Hi @Nelo_drup,

Could you try fixing the version to 1.0.3?
composer require "drupal/fileslog:1.0.3"

Sadly some dependencies got mixed up between version 1.0.4 and 1.1.0, version 1.0.4 was supposed to be in the 1.1.x range because it requires PHP 8.1 + Drupal 10.x.

In reality, Fileslog 1.0.3 is the last version that supports 9.5.x.

This also happens to me.

The client was created as an offline client, yet the authorization keeps dropping? This is incredibly intrusive, this is a system that needs to work automatically..

Needing to manually reauthorize this frequently makes it completely unusable on production environments.

I'm setting this back to active, I hope a maintainer can provide a workaround / solution.

Oops. Only saw afterwards that you want to automatically generate it, and not manually by submitting the form.

The last commit on 1.0.x-dev should contain that functionality in the RoleManager service.

\Drupal\msqrole\RoleManagerInterface::generateUrl(array $roles, bool $single_usage = FALSE, array $url_options = []): Url
The arguments are all self explanatory.
Url options you could use to add a destination to the query parameter or something like that.

Example usage:

\Drupal::service('msqrole.manager')->generateUrl(['editor', 'visitor'], FALSE, [
  'query' => [
    'destination' => '/path/to/page',
  ],
];

Hi Tregonia,

I've pushed a first attempt to the 1.0.x-dev version → of this module.
Feel free to give it a try, see how it feels and report back with your findings.

If the functionality feels well and complete, I'll release it in a new version of the module.

Kind regards,

RandalV

Hi Tregonia,

Thanks for your ticket.
I'll look into this, but I can't promise if and when this could be released.

Kind regards,

RandalV

I see this has made its way into a new release.

Thanks!

MR 's been updated, although I don't see the changes come through yet here in the issue itself.

RandalV → created an issue.

@Steven Jones Ah, yikes.. I completely glanced over that.
So sorry, thanks for the help!

I'm not sure if this is the correct place to report this, but in my project this 'hook_query_TAG_alter'-hook in LH is never even called?
I bumped into this because I noticed fallback aliases weren't working (D 10.1.5, LH 2.0.0-RC5)

Not sure whether it's a bug, but when debugging the select query object in the AliasRepository, I also can't find the tag in the 'hook_query_TAG_alter'-hook used by LH.

If this should be its own issue, let me know and I'll create one, no worries.

Can confirm that this still happens when items are wrapped in a fieldset.
For example, the Webform Scale-element.

I'm not sure how to fix this.

Bumping again...

Can the maintainer please take a look at this??
Is there even still an active maintainer?

I am also getting this issue.
The original PR seems to work for me, altho I'm not sure on how complete it is.. I'll leave that up to the maintainer.

I would however like to see this committed somewhat soon, because it is disruptive during the sitebuilding stage of a project.

Sorry, I forgot a closing ';'.

Sorry, I forgot a closing ';'.

Rerolled #35 against 10.1.x

Hi Andy!

Thanks for reporting the issue. Strange one, indeed.

Interesting that this causes a circular reference. In any case, the proposed changes are an improvement, so I'll merge this and release a new tag.

Thank you for figuring out the issue!

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

I also found an entire piece of code that basically does nothing, I deleted this as well.
Additionally, I added a comment to a piece of code that also seems weird (identical operands), to be fixed by the maintainer if possible.

RandalV → created an issue.

Hi @Salvis,

Thanks for your reply and patch! You're right, ignoring the lack of the moderator element is not the way.

With your patch however, I'm still getting the following error when navigating to the 'Forum add'-form.
I haven't got the time to debug this right now though, I'm afraid.

The website encountered an unexpected error. Please try again later.
TypeError: count(): Argument #1 ($value) must be of type Countable|array, null given in _acl_edit_form_after_build() (line 126 of modules/contrib/acl/acl.admin.inc).
_acl_edit_form_after_build(Array, Object)
call_user_func_array('_acl_edit_form_after_build', Array) (Line: 1083)
Drupal\Core\Form\FormBuilder->doBuildForm('taxonomy_term_forums_forum_form', Array, Object) (Line: 1075)
Drupal\Core\Form\FormBuilder->doBuildForm('taxonomy_term_forums_forum_form', Array, Object) (Line: 1075)
Drupal\Core\Form\FormBuilder->doBuildForm('taxonomy_term_forums_forum_form', Array, Object) (Line: 579)
Drupal\Core\Form\FormBuilder->processForm('taxonomy_term_forums_forum_form', Array, Object) (Line: 325)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 48)
Drupal\Core\Entity\EntityFormBuilder->getForm(Object, 'forum') (Line: 259)
Drupal\forum\Controller\ForumController->addForum()
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 580)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 169)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 81)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 718)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

I would actually like to see this issue reopened, because it persists in Geocoder 4.x.

Could maintainers please take a look at this?

This issue is going to have to land at some point.

We have two core(!) modules that haven't been able to be enabled at the same time out of the box for the past 4 years, I see that as a big issue.
The patch only changes two lines, I think it's safe to have this committed?

Also yes, don't use .diff links from MRs in your composer patches. Download the diff contents to a local patch file, and add that as a patch.

I'm running into an issue with the beta5 and beta6 versions where an anonymous user will not see the view results. Logged in users do not get this issue.
The view itself is being rendered (the exposed form and so on is there), but the results never are.

I can't for the life of me figure out why. There are no console errors, and the #lazy_builder placeholder gets replaced properly as well.

I'm also feeling forced to revert to beta4 to restore the functionality. If I do find a cause/solution, I'll post it here.

I've tested the MR and that also solves the issue for us.
HTML mails are turned on via a contrib module, all other HTML mails / markup works.

Thanks for the fix. Hopefully it gets committed.

I have had this issue as well, thank you for the patch. It seems to work for me.

I had my doubts about retrieving the entity from the form object, but I suppose in the end it makes sense to do it this way.

Added a second module_load_include() to the MR, it was needed elsewhere too.

Now I haven't run in any other issues.

RandalV → created an issue.