We are getting a lot of these errors. This issue would be in the fourth grade if it were a person :-)
Any chance we can roll this forward or better yet merge it? :-) It is not applying to 2.1.0
Sorry I missed the question above (#15). I can report that the locking mechanism in the MR did resolve our duplicate user issue. Thanks much for your attention to this!
bob.hinrichs → created an issue.
If you come across this, check your theme debug settings and make sure the feature is turned off.
bob.hinrichs → created an issue.
bob.hinrichs → created an issue.
bob.hinrichs → created an issue.
bob.hinrichs → created an issue.
bob.hinrichs → created an issue.
bob.hinrichs → created an issue.
bob.hinrichs → created an issue.
Same error. This is very hard to troubleshoot, as the exception does not have a message and it is not clear from the stacktrace what is causing it.
I ran into a similar issue having updated my version of lando, tried some of these things and they did not work.
Make sure to remember the lando destroy command, this worked for my problem and has sometimes been necessary to clear up similar issues.
There is a new merge request here that introduces using Drupal::lock() to prevent running authenticateUser() in parallel for the same user. We have not yet made this change live, will do so 1/5/24.
bob.hinrichs → made their first commit to this issue’s fork.
We are experiencing quite a few errors where google comes back with this to our callback:
/user/login/google/callback?error=access_denied&state=54e334cd95aa9e74c...
This creates an error in dblog like:
BadMethodCallException: Required parameter not passed: "code" in League\OAuth2\Client\Grant\AbstractGrant->checkRequiredParameter() (line 35 of /code/vendor/league/oauth2-client/src/Tool/RequiredParameterTrait.php).
Is this the same issue? It appears perhaps so, and the callback ought to catch this.
There is an additional question here about whether this constitutes an actual error to be logged. It could be argued, when users are generally able to log in, but some do not have access via google, that is normal functioning.
Drupal 10:
I had a field named field_show_number_grantable that I added via form_alter, that was a toggle state field (didn't submit any value but was used on the front-end). I needed it within a field group with group_name of 'group_administrative'
1) In my form_alter hook in the field_show_number_grantable array, add '#group' => 'group_administrative'
2) add this function to my module:
function MYMODULE_field_group_form_process(array &$element, &$group, &$complete_form) {
if ($group->group_name == 'group_administrative') {
$group->children[] = 'field_show_number_grantable';
}
}
bob.hinrichs → created an issue.
Thank you! I updated the issue with some new information I discovered about how to reproduce the issue.
Would it be possible to merge this? It is the only module among many that is still lagging. Drupal 9 is nearly unsupported.
bob.hinrichs → created an issue.
We are going to use this patch in order to squelch the flood of spurious errors in the logs. Because thsi issue creates noisy log files, it is a pretty important core bug, IMO. Thank you for this nice little patch.
I am trying to get a D10 up and running and I can't get any of these patches to apply either.
+1
I spent all day fixing this. The best way is unclear, but I had to create a custom Access class like this:
class IsMyUserOrAdmin implements AccessInterface {
protected $routeMatch;
public function __construct(RouteMatchInterface $route_match) {
$this->routeMatch = $route_match;
}
public function access(AccountInterface $account) {
// return true if the useris an admin or the user id in the route matches the current user id
return AccessResult::allowedIf($account->hasPermission('administer users')
|| $account->id() == $this->routeMatch->getParameter('user'));
}
}
Then set it up as a service like:
mymodule.is_my_user_or_admin:
class: Drupal\skillscan_system\Access\IsMyUserOrAdmin
arguments: ['@current_route_match']
tags:
- { name: access_check, applies_to: _mymodule_is_my_user_or_admin }
Then since this is a view, I made it a views custom access plugin, with this being the operative part.
public function alterRouteDefinition(Route $route) {
$route->setRequirement('_custom_access', 'skillscan_system.is_my_user_or_admin::access');
}
I am kind of blown away by how much knowledge and engineering was needed to solve this very simple problem. There is perhaps an easier way but this was the most functional way, that can be reused in the system in similar cases.
Yes, seeing that empty border. Not good. Have to downgrade.
Just chiming in, that this is still an issue.
From AWS:
"We will begin deploying updates to the TLS configuration for Amazon CloudWatch Log APIs to a minimum of version TLS 1.2 by September 15, 2023, even if you still have connections using these versions. These deployments will complete by no later than December 31, 2023. This update removes the ability to use TLS versions 1.0 and 1.1 with all AWS APIs in all AWS Regions [1]."
We look forward to a D10 release, thank you!
Thank you, looking forward to a D10 release soon!
This is a nice module. Looking forward to a D10 release soon.
Just chiming in, that we observed this issue in a form that is using the ever-popular inline_entity_form module to manage related entities to a node. One can see that inline_entity_form uses tables. In light of others working on this issue with CKE5, we worked around the issue by editing the toolbar in the text filter configuration to add line breaks into the toolbar. This eliminates the nice vertical-dots-see-more feature of the cke5 toolbar and does not look as nice, but it stops the toolbar from pushing out the editor's width.
bob.hinrichs → created an issue.
Any word on a D10 release?
Any word on a D10 release?
A release with d10 compatibility would be welcome!
bob.hinrichs → created an issue.
Any chance a release could be made soon?
bob.hinrichs → created an issue.
Hope for a release soon! Thanks
Interested in a release soon! Thanks
Hope this can get released!
Anyone going to release a D10 version?
bob.hinrichs → created an issue. See original summary → .
There aren't even any posts on the internet that talk about this feature or what it does. Even the forms and fields do not have suitable descriptions or field titles or help. For example, is 'weight' the weight of the packaging or does it mean it is maximum weight that the package can use? I found that adding a package type made a package selection magically appear on a totally different screen, the shipping method. You literally would need to read all the code to see what this thing does. I tried to use the usps module and it seemed to completely not work. Nor does it have any documentation at all. My guess is that somehow I need to set up packages in order to make usps work. This is a tremendous waste of time, that even a small paragraph would have avoided, perhaps. I say perhaps because it's usually safe to assume that undocumented features, without even any mention on the internet at all, are experimental or can't be expected to work, because it's not a serious effort and no one is using them. Is that the case here? Sorry for my rant-y tone. I like Drupal Commerce in general.
bob.hinrichs → created an issue.
Hi @ruvus, this seems to happen anytime an item is added to the cart. It works fine in the cart, but we just get a ton of status messages on the page, one for each item in the cart
I am sorry to change status, but in order for this to work, I believe the adjustments in #12 would be necessary in order to avoid the errors reported?
I might not be understanding something.
What is the upgrade path for someone running v3, who upgrades Drupal 9 to Drupal 10, if "there is no upgrade path from v3 to v4" as stated on the project page? Am I reading that right?
Using this module with patch #7, I am noticing on our site, when a user adds a product to their cart, it generates a status message for all the products in the cart, including products that were already in the cart and not added in that request.
Thank you for this #7 patch!
Thanks for this info, is a patch or update available that fixes #12 also?
Confirming, this is a bug. Sounds like for a while. My same issue, very simple to reproduce: create an entity on the system (content type, etc.) and use an entity reference field in it, and make it an autocomplete field. Create an entity ref View and use that View for the field. If you put a filter on the View, it is not honored in the autocomplete.
bob.hinrichs → created an issue.
Thanks, this fix is confusing. Any progress on this problem? Php 7 is no longer supported.
I installed this module (8.x-2.0-alpha19) and once installed, it will not uninstall. There was no action taken other than installing it (no configurations made).
Message: dynamic_entity_reference: The Dynamic entity reference field type is used in the following fields: media.field_terms, node.field_category
Is there a way to uninstall it?
New finding. This is also broken on a lando site running the pantheon recipe. Might make this easier to replicate if you are not on pantheon. I worked with pantheon support ton this and they are of course clear that the issue is with this module. Which is reasonable since other functions of the site use temp directory and everything else works.
This is very bothersome, the area of the configuration form says it is Page Settings. Not View Settings. This is a pretty bad bug, it bit me. If this is how it works then we need to create a bunch of different views, one for each access setting? I can't recall it working this way in Drupal 7.
This problem is real. I have implemented the temporary fix of using the private:/ file stream, but we already use private, so I cannot point it to a temp directory -- so I guess we will be accumulating unwanted files in there until this is fixed, eh? In any case, the best theory I could come up with, discussing with Pnatheon support, is that the module maintainers are wrongly referencing the tmp directory, without anticipating multiple application servers in a modern environment such as pantheon’s. The issue did not appear during our QA, because we test on a multidev site, which does not use the same file handling as the live site. The other functionality of our site apparently uses the temp directory just fine, so that is why our best guess is that there is a problem with this module.
I suppose that the stream was changed to 'temporary' form 'public' because tmp directories have special functionality, and these are not files we want in with our permanent files. So we will be watching this issue carefully! Thanks all.
Same issue as #14. The text filter on ckeditor forces p tags around the text around the media tag.