I tried the hack in #7 but it didn't work for me under 10.x
I have had some success in combating the problem by using https://www.drupal.org/project/better_exposed_filters → but it's not perfect.
This is a very annoying bug for filtering dates (manifesting as timestamps) by exposed filter... :/
You may find that you need to implement a security "fix" for your instance of Drupal.
See these:
https://www.drupal.org/project/drupal/issues/3150614#comment-13740271 📌 Set SameSite on session cookies Fixed
Issue was narrowed down to IMCE.module - Closing; thanks Wim.
We've been using the patch from #73 since it arrived, without issue.
This is a warning, not an error, apologies. Would be great to remove all issues during a payment process however.
NikLP → made their first commit to this issue’s fork.
Whilst I would still suggest this change to the module - and sorry again for the state of this thread - I have finally deduced that you can override (for the meantime) this problem by specifically adding IEF to your composer.json with a fixed version of ^1 or whatever you want. This will supercede the version "required" by this module. Unless there is a change to the status of the 2.x branch in IEF this will continue to cause potential problems without this workaround/patch/MR.
Sorry. Not massively au fait with the whole "new" drupal contribution setup, it's been a while.
What we were trying to do is make a version of the module available that would pass (most?) rector tests. I think we have these in our testing pipeline and need (a certain number of?) them to pass. What I did here was run rector across the module and basically commit the diff, with a few manual tweaks. This was last week so memory already fading.
Corrected the errors and what-not as suggested.
Sorry. Got rather confused chasing this around.
This is being brought into 2.x and needs changing
Passes all rector checks to "functionally" run payment in D10 - further updates required for test modules etc.
Little bit unusual perhaps, but I notice that there is another module that does almost exactly the same as this one, altho exposes functionality slightly differently in the UI - https://www.drupal.org/project/condition_path →
I also notice that this module is using conditional plugins, so perhaps you could modify this module to work in the same way as that one, whilst keeping the (IMO, slightly better) position in the UI the same?
I've taken everything I can find from the two threads marked as D10, and combined them here https://www.drupal.org/project/menu_attributes/issues/3241545 ✨ D10 compatibility & fixes Active - use the "plain diff" from that thread
This combines existing D9/10 issues and a couple of other patches we had here locally that seemed pertinent
OT really but just a quick note for people upgrading to D10 that https://www.drupal.org/files/issues/2021-12-10/scheduled_updates-htmlspe... → applies cleanly on top of the latest patch here and https://www.drupal.org/files/issues/2023-09-05/scheduled_updates-2872239... → after that for the missing column error.
So, [latest patch here] then 2872239 then 3253884, on top of 1.x-dev
As mentioned by @somersoft in #6, the fix AND the necessary changes for the D10 upgrade are included in the branch https://git.drupalcode.org/issue/course_relationships-3220941
@eelkeblok I believe the reason that this (and all improvements/fixes to Drupal) are targetted at D11 is because it is deemed better to fix in a place that is future-proof, and then backport to current releases.
Reopening because on further inspection, if we switch to E164 in order to accommodate multiple countries, we then have to use a different format for the data input, which isn't what we want. All the +44 'countries' have the same format, and we want to input them identically to how they are written locally, i.e. 07777123456.
Simple fix for this is to allow multiple selections whilst using the National option in the field config. This means changing the multiple to always be true, and less importantly removal of the now-unnecessary ajax callback etc.
Closing with a grovelling apology, because it appears everything is by design. However, during dev the js on our local machines does not correctly activate the ajax callback which transforms the select into a multi - and there were no errors to illustrate this. Similarly, on a separate dev instance on gitpod, the error checking failed to work altogether, which I have no explanation for.
So as it goes, this works fine. If you need multiple "countries" (this is contentious in my use case) this will in fact work fine, you just have to make sure it isn't something else that's making you look like an a$$! :|
To work around this, we simply deleted the field, which was empty for us.
** NB this might not apply as well to other users! **
Here's a patch against v3.1.0 via @somersoft, but please note this patch is specifically against the opigno_learning_path.module - this issue might have been better reported in the more specific queue: https://www.drupal.org/project/issues/opigno_learning_path →
Happened to me today with 9.4.15 but as the crowd suggests, #5 is still working.
Would I be correct in saying that this is the part of the patch that fixes the "$.cookie is not a function" error?
-(function ($, Drupal, drupalSettings, once) {
+(function ($, Drupal, drupalSettings, once, cookies) {Patch at https://www.drupal.org/project/quicktabs/issues/3189439#comment-14958818 ✨ Last clicked tab history should be configurable RTBC fixes the "Uncaught TypeError: $.cookie is not a function" error.
Probably should have added a note to say, you will need to use this command in your drupal deployment procedure for it to work!
Updated patch to remove casting errors and improper string var to function.
Patch applies cleanly to 2.0.2 also :)
To use the drush command:
drush css_editor:writecss
drush cewc (alias)Patch against 2.0.1 attached
We needed this for an Opigno-based project so I re-rolled #68 against 1.0.3 if helpful.
Having tested this patch, can confirm it removes the immediately offending errors.
It didn't fix an underlying problem with access checks that I'm having, but this was definitely blocking progress.
<?php
// each of a delta-keyed array
foreach ($referenced_entities as $ref) {
// $ref->id() points to fid in my case which is e.g. 3018, soooo....
if (isset($referenced_entities[$ref->id()])) {
// never hits here
}
}
?>
+1 for the patch, existing code makes no sense, at least in my use case of "10 files attached to a user profile".