I agree a UI option to enable/disable cron processing of the queue would be ideal. But as a workaround, here's some code I've added to a custom module to make the cron process the queue:
/**
* Implement hook_cron()
*/
function MYMODULE_cron()
{
$queue_worker = \Drupal::service('plugin.manager.queue_worker');
$bulletinQueue_worker = $queue_worker->createInstance('govdelivery_bulletins');
$bulletinQueue_worker->processQueue();
}
(Replace MYMODULE with the name of your custom module.)
Thanks for the explanation. The performance and reliability aspects make sense, as well as the UI only being a developer/debugging tool.
I agree, it would be ideal if there was a setting to have the cron send any queued items. But we can workaround that limitation using one of the methods you suggested. The second method of using the API trigger endpoint does require a Unix timestamp (it would be nice if it defaulted to the current time) but I suppose we could just use a very far future timestamp in every request if we don't want to have to programmatically calculate a timestamp.
This is probably my biggest sticking point with the module right now (figuring out how to bypass or automate sending the queue) so any advice here would be greatly appreciated. Thank you!
FYI When this happened to me, it truncated the message at the critical part. i.e. "An error occurred because you must... (truncated)". I ended up having to use Postman with the XML shown on the queue page to manually issue the API call and reproduce the error so I could see the full message.
swirt → credited RichardDavies → .
swirt → credited RichardDavies → .
swirt → credited RichardDavies → .
swirt → credited RichardDavies → .
swirt → credited RichardDavies → .
swirt → credited RichardDavies → .
RichardDavies → created an issue.
Thank you for the quick response. I applied the patch from the MR and it fixed the problem. I no longer get the errors on /admin/structure/block/manage/[theme]_breadcrumbs/settings-tray and the modified help text for the Pages field is still present on /admin/structure/block/manage/westy_breadcrumbs
RichardDavies → created an issue.
RichardDavies → created an issue.
RichardDavies → created an issue.
Ah, thanks, I didn't realize I could edit that documentation. I've removed that row and made a couple of other additions to improve it.
Regarding static vs non-static, no, my VS Code editor doesn't alert to to that issue. Perhaps I don't have it configured correctly. Just goes to show you can't assume everyone's using an IDE that would point that issue out. I guess I just feel that a section of documentation that is dedicated to listing API changes should state when a method changes from static to non-static because that's just as important of an API change as the method name changing or parameters changing.
- Corrected incorrect information about removal of
GroupRelationship::loadByEntity()(Method wasn't actually removed) - Added additional information about new methods for old methods that used to support filters.
Yes, I eventually figured it out. But I do feel this is a good example of how you could make your documentation clearer and easier to understand because technically the documentation is currently incorrect.
You have a section describing changes to the GroupContent/GroupRelationship class which says that the loadByEntity method was removed. This is incorrect because that method still exists and works just fine (and actually does what the documentation recommends doing instead).
Don't state that a method has been removed if it hasn't actually been removed. (And if it was actually removed and the old method was static but the new method is not static, then you should state that change in the documentation when you mention the new method's name so that we don't have to go hunting through the source code to figure it out.)
I would recommend just removing that entire table row from the documentation because loadByEntity was not removed so the user doesn't need to do anything other than use the new class name.
FYI I filed a bug report with Drush for the extra blank lines: https://github.com/drush-ops/drush/issues/5911
Update:
After further review, GroupRelationship::loadByEntity() is actually working correctly for me. So I assume that's the correct function to use, and it does actually use \Drupal::entityTypeManager()->getStorage('group_content')->loadByEntity() under the hood.
So I just think the documentation is not very clear when it says "Use GroupRelationshipTypeStorage class and it's loadByEntity method" because that lead me to mistakenly think I should replace GroupContent::loadByEntity() with GroupRelationshipTypeStorage::loadByEntity()
Nevermind, I think I just found the answer. It looks like in this specific case, I can use getRelationshipsByEntity($entity, $plugin_id)
RichardDavies → created an issue.
Before I reviewed that documentation page, I just assumed the method changed to GroupRelationship::loadByEntity() which interestingly does exist, but it doesn't seem to be working as expected for me. It's not returning any entities when there should be some.
So I'm not sure if the documentation is wrong, or if there's a bug in the new function, etc.
RichardDavies → created an issue.
Thank you, I finally got to the bottom of my issue. It was indeed caused by some of our custom code that maintains some automatic group memberships based on some data from the user's Active Directory profile. This code was calling Group::load($group_id)->getMember($account)->getRoles() which returns all roles, even our new insider/outsider roles, and then it was unintentionally assigning those roles to the user. Changing it to getRoles(FALSE) fixed the problem.
kristiaanvandeneynde → credited RichardDavies → .
My "other suggestions" in #18 were in direct response to your question in #17 "I think this is rather clear, no?". So I'm confused as to why you think this was not the right place for that response... Obviously you can do whatever you want with my feedback--take it or leave it, create a new issue for it, incorporate it into a future release, etc. But if you'd prefer not to receive feedback in a closed issue, then maybe best not to ask for it there. :)
I'm having a similar issue, but not sure if the problem is something on my end or a bug in Groups module. I'm upgrading a site which was using Groups 1.6 to 2.2. The site has the concept of an "public" group which any authenticated user can view without being a member. I've configured an Outsider scoped role that is synced with authenticated users to allow non members to view the group. There are also Outsider and Insider roles synced with the global administrator role so admins can manage all groups.
If a user views a group and they're interested in it, they can "follow it" which means becoming a member and being assigned the "following" individual-scoped role. However, whenever a user tries to follow a group, they get the permission error mentioned in the original post. Group admins also get the error when they click the Add member button on a group and try to add themself with the "following" role. However, if they add any other user beside themself then they don't get the error.
I've debugged the IndividualGroupPermissionCalculator as suggested and it is also returning an insider scoped role (either the "member" role synced with authenticated users or the administrator role synced with global admins). You said this means that "You have an insider role assigned to someone"... but I've looked at all of the groups that I'm a member of found one where I was assigned the "member" role and removed that role but I'm still getting the error. So does the error mean that the user being added to the group is assigned an insider role somewhere that I've missed somehow, or will I get the error if ANY user on the site is assigned an insider role (because it's possible we might have other others still assigned the "member" role)
I'm experiencing another issue related to the `separator: |+` config line and extra rows. I'm finding that `drush cex` often wants to insert additional blank lines under the separator line. It doesn't seem to matter how many blank lines are already there, it keeps adding another one every time I export the configuration. Interestingly, when it lists the config that will be exported, search_api.index.my_index isn't listed as having changed, but the yml file is still modified with an additional blank line when the export is executed.
As someone upgrading from Groups 1 to 2 I hadn't actually seen this text until just now, so although it's helpful to new users, it doesn't really help users who are migrating and have already created their groups under a previous version of the module. Regardless, it is reasonably clear to me, but I think it could still be improved a little. Here's my suggested version:
Please note that Drupal accounts, including user 1, do not have access to any groups unless configured so. It is therefore important that you at the very least do one of the following:
- Assign the group creator a role below and set some permissions on that role. You can edit this group type at any time to set more creator roles, but this won't affect previously created groups.
- Allow certain global roles to automatically get some group permissions via Outsider or Insider group roles.
Optionally, you can set a role (whether the group creator's role or an Outsider/Insider role) as an admin role if you want that role to have all permissions for the group. If your use case does not require the group creator to be an admin of the group, then it is strongly advised to at least create an Outsider and/or Insider group role that synchronizes with whatever administrator global role you have configured.
* Note that the word "administrator" is currently misspelled in your last sentence.
I certainly appreciate all of your work on this module. Now that I understand the change, I can see that all of the information was there, albeit spread across release notes, change records, and videos. But for someone trying to understand this for the first time, it's difficult to have to go to multiple sources to glean little tibits of information and successfully assemble all of the puzzle pieces together in order to form a complete mental understanding.
I can only speak for myself, but since you asked, an explanation like the following in the release notes would have been easier for me to understand:
Roles and their UI have been reworked
No more advanced outsider roles or any of that nonsense. You can now define one of three roles:
- Outsider: This group role is automatically assigned to all users who are not a member of the group and have a specific global role.
- Insider: This group role is automatically assigned to all users who are a member of the group and have a specific global role.
- Individual: This group role can be manually assigned to a specific group member to give them extra permissions on top of the above.
For example, in order to give all group members admin permissions if they have the global role "Site administrator", do the following:
1. Create a group role "Site Administrator"
2. Scope: Insider
3. Global role: Administrator
4. Check "Admin role"
This group role will now sync with the site role "Site administrator".
@JordiK Thank you for providing simple instructions on how to recreate the version 1's sitewide administrator permissions. Despite having read the release notes multiple times, this change was not clearly explained in my opinion (e.g. it wasn't obvious to me that the new group roles could be auto assigned to users with a specific sitewide role.)
Anyway, I just wanted to point out that to fully recreate version 1's sitewide administrator access to all groups, you need to create two new roles: an "insider" one like you mentioned, and a corresponding one with scope set to "outsider". That way a user with the sitewide administrator role will have admin access to any group, regardless of whether they're a member of it or not.
@dqd You just barely said in your previous comment that you're considering closing this issue since Drupal 7 is EOL soon. Why not just repurpose this existing ticket (with all it's history) for the same issue with D10 and Conditional Fields 4.0? Seems pointless to close this ticket and reopen a new one for the same issue.
RichardDavies → created an issue.
I'm experiencing the same issue with Drupal 10 and Conditional Fields v4. So I think this should remain an open issue.
This module is now being flagged as unsupported. Can we get a new release soon? This patch has been working fine for us.
RichardDavies → created an issue.
Updated @shweta__sharma's patch and changed key() to keys(). Patch now cleanly applies for me in 10.2.0.
@shweta__sharma Thank you, but the patch won't apply for me with 10.2.0:
@acbramley Ah, thank you for the clarification. I didn't understand how the 11.x branch worked and couldn't find this item listed in any of the 10.2x release notes so I assumed it wasn't in the 10.2 release. But I've just confirmed it is indeed there.
Can someone please reroll the patch for Drupal 10.2.0?
Can someone please reroll the patch for Drupal 10.2.0?
RichardDavies → created an issue.
I encountered the following error when attempting to upgrade from v1.6 to v2.0.2
Drupal\google_tag\Migration\GoogleTagMigrateBase::getRequestPathCondition(): Argument #1 ($request_paths) must be of type string, null given, called in /app/web/modules/contrib/google_tag/src/Migration/GoogleTagUpgradeManager.php on line 126
Although this patch allowed me to run the database update without error, it does not appear to have correctly/fully migrated my previous container settings. For example, here is my previous container YAML:
uuid: 0c9d3f73-ef36-48ab-9c86-28b4cc41bc2b
langcode: en
status: true
dependencies:
module:
- webform
id: employees_portland.gov
label: 'Employees Portland.gov'
weight: 0
container_id: GTM-[REDACTED]
data_layer: dataLayer
include_classes: false
whitelist_classes: |-
google
nonGooglePixels
nonGoogleScripts
nonGoogleIframes
blacklist_classes: |-
customScripts
customPixels
include_environment: true
environment_id: env-3
environment_token: [REDACTED]
path_toggle: 'exclude listed'
path_list: |-
/admin*
/batch*
/clone/*
/devel/*
/node/add*
/node/*/edit
/node/*/delete
/node/*/revisions
/node/*/usage
/user/*/edit*
/user/*/cancel*
/user/*/scheduled*
/user/*/connected-accounts
/user/*/submissions
/group/*/edit
/group/*/delete
/group/*/content*
/group/*/nodes
/group/*/revisions
/group/*/members
/group/*/media*
/group/*/usage
/group/*/subgroups
/group/*/create
/media/*/edit
/media/*/delete
/media/*/usage
/taxonomy/*/edit
/taxonomy/*/delete
/taxonomy/*/usage
role_toggle: 'exclude listed'
role_list: { }
status_toggle: 'exclude listed'
status_list: |-
403
404
conditions: { }And here is the new YAML:
uuid: 0c9d3f73-ef36-48ab-9c86-28b4cc41bc2b
langcode: en
status: true
dependencies: { }
id: employees_portland.gov
label: 'Employees Portland.gov'
weight: 0
tag_container_ids:
- null
advanced_settings:
gtm:
data_layer: dataLayer
include_classes: false
allowlist_classes: ''
blocklist_classes: ''
include_environment: false
environment_id: ''
environment_token: ''
dimensions_metrics: { }
conditions: { }
events:
search: { }
webform_purchase: { }
login:
method: CMS
custom: { }
generate_lead:
value: ''
currency: ''
sign_up:
method: CMS
As you can see, it didn't transfer the container ID, environment, or path exclusion settings.
RichardDavies → created an issue.
@hudri Thank you for figuring this out and providing a fix. We were experiencing the exact same error and I couldn't figure out why until I found this bug report and discovered we were also unsetting the administration menu just like you were in order to hide it from certain users. Your fix works perfectly!
Patch #39 works for me. I'm now able to use the To filter on /admin/config/search/redirect to search by URL alias values shown in the To column. Searching by the internal node ID still works as well.
Moving this issue to https://www.drupal.org/project/lightning_workflow/issues/3176759 🐛 Lightning Workflow-created revisions not getting correct time Active because we're using the lightning_scheduler that is included with lightning_workflow.
We're also having this same problem with v3.19. I see that supposedly this was previously fixed with https://www.drupal.org/project/lightning_workflow/issues/3022898 → so I'm not sure why it still doesn't seem to be working correctly.
RichardDavies → created an issue.
RichardDavies → created an issue.
Hmm, I'm trying config_ignore for the first time and seeing my config split entities appear as ignored in the config UI. I'm using version 2.4.0.
In case anyone else runs into this issue, here's a patch to remove the redundant Revisions tab that's now being added by Groups. (The other tab is coming from Drupal 10's system.links.task.yml.)
After upgrading to Drupal 10, all of my groups now have two "Revisions" tabs:
Both tabs link to /[group_alias]/revisions. I'm using Groups 1.5 and Drupal 10.1.2.
This is a confusing warning. The Classy and Stable themes are part of Drupal 9 core and are both located in the web/core/themes directory. So you can't uninstall them like you would with a contrib theme that has been added to your site. You should verify that you're not using another theme that relies on either of those themes as a base theme. As long as they're not being used directly or as a base theme, they should just silently go away when upgrading to Drupal 10.
But, like you reported, I don't know how to satisfy the upgrade status report so that it doesn't complain about these themes even if I'm not using them. So for now I just ignore that warning.
For some reason Composer would not apply the given patch file for me. I had to manually recreate the patch file to get it to successfully apply.
No, I don't think I did other than to manually translate the view through the native Drupal translation UI.
Updating the issue summary with more information.
RichardDavies → created an issue.
Yes, I can confirm that this error still frequently occurs even with Search API 1.29. In fact, it is currently the most frequently occurring error on our site at the moment. For us, we started seeing this error on April 28th and it's been frequently occurring ever since then.
@ressa The regex searches the $output string for all occurrences of \\uXXXX where X is a hexadecimal character consisting of a digit 0-9 or letter A-F (case insensitive). e.g. \\u0026
For each match that it finds, it uses the mb_convert_encoding() function to convert that character from one encoding to another encoding. Then any double quote characters (") are prefixed with a slash character (\) so that they're properly escaped according to the JSON string requirements.
I encountered this on 9.5.x
RichardDavies → created an issue.
I just found another issue:
- Before enabling this module, start with the CKEditor 5 media plugin setting "Allow the user to override the default view mode" checkbox unchecked. This way you should not have configured any allowed view modes here yet
- Enable this module
- Now check the box to "Allow the user to override the default view mode"
- Configure your allowed view modes per media type
- Click save and note the following error message
The CKEditor 5 "Media" plugin's "Allow the user to override the default view mode" setting should be in sync with the "Embed media" filter's "View modes selectable in the "Edit media" dialog" setting: when checked, two or more view modes must be allowed by the filter.
It's checking the original config to make sure at least two view modes were selected, but that config has been replaced with per media type config by this module so the validation needs to check the new config settings now.
RichardDavies → created an issue.
Based on our testing, the OP's suggested code change does indeed resolve this issue and we've been unable to identify any problems or side effects with the change. So I'm attaching a patch file for this fix and reopening this issue because if you can create a revision I feel like you should be able to view that revision.
I just upgraded to CKEditor 5 and I've been troubleshooting a very similar situation where clicking on some links in the editor caused the browser to instantly navigate to the link. Although my root cause was different than what is described in this original issue, I'm leaving a comment here in case it helps anyone else.
What was different in my case was that my links didn't contain an anchor and it only happened when editing certain pages on my site. It was really difficult to pinpoint exactly what conditions were causing this behavior, but I finally determined that the issue was caused by our Google Tag Manager code which tracks clicks on outbound links. We had tried to exclude GTM on our admin/editor pages, but had overlooked some so GTM was unintentionally loading when editing certain types of pages. After reconfiguring GTM to exclude those pages I can now click on the links without navigating to them.
@SoulReceiver I tried the change you suggested and seems to be working correctly now for me. The user can now view /latest when they authored the latest revision. I'm curious why you stated it didn't seem to be a complete fix or working as expected for you... can you elaborate on the problem you continued to experience after trying your fix?
I just encountered this exact same issue and I'm not sure "works as designed" is technically accurate or that the current behavior is the ideal desired behavior. As the OP explained, a user can view the published node and can create a new draft revision of the node. But when they click Save on the draft revision, they're taken to /[node_url]/latest which returns access denied.
I completely understand and agree that the 'view own unpublished content' permission shouldn't give you access to all of the unpublished revisions if you didn't author those revisions, but it's currently denying access to an unpublished revision that you just authored! That doesn't make any sense and is confusing to a user to say in essence "Yes, I just let you successfully save a new revision, but sorry, you can't see it now."
Interestingly, the user can actually view their revision by using the Revision tab and clicking on their revision link which points to /[node_url]/revisions/[revision_id]/view. So it seems like /latest should allow you to view the latest revision if you have the 'view own unpublished content' permission and you authored the revision, regardless of whether or not you were the original author of the node.
Thanks for the patch. It's working for us to remove the extra string in the environment names.
After digging into this a bit, I believe this commit in v4.7 is the culprit. It changed how JS/CSS gets applied to entity browsers. I've verified that after upgrading to 4.7 or above, my entity browser no longer has the JS/CSS that was formally applied to the entity browser and adds the "click" event handler.
I don't fully understand the rationale behind that change, but it seems to be intentionally more selective about when the JS/CSS gets applied... is there something different I need to do to my entity browser configuration so that it meets the more selective criteria now?
@alfattal Did you ever figure out the cause or solution to the entity browser items no longer being clickable after upgrading lightning_media? I'm experiencing the exact same issue.
@jb I don't know if there is a Drupal core issue with this patch. I think someone posed the patch in Pantheon's Slack channel so that's where I got it from. We just saved it to a local file and applied the patch via Composer to work around the issue.