I am facing the same issue with this version of the megamenus and some dc charts along with their filters that I've been using on a page/view.
After a couple of clicks on my charts or filters, the page becomes unusable to the point that Firefox hangs due to excessive memory/cpu.
Doing a profiling on my browser shows the data (see image)
I can confirm that reverting to alpha2 didn't help but removing the module completely did (obviously, that's not what we want)
Hi there!
I'm afraid that this operator ( `<=10.2` ) is limiting anything higher than 10.2.0 on the 10.2.x range.
I do run Drupal 10.2.7 and I am unable to pass the dependencies issue in Composer.
In theory, in order to cover also the 10.2.x range, it should be
"drupal/core": "^9.3 || ^10.0 || <10.3"
I'm updating this issue just to report my findings.
On the module `webform_civicrm.module`, on line 212 (of version 6.2.5) as seen here: https://git.drupalcode.org/project/webform_civicrm/-/blob/6.2.5/webform_... I've reworked that line so that instead of:
$data[$key] = $element['#options'][$val];
it assigns the variable as such:
$data[$key] = $val;
This allows me to rectify the issue, however, one more issue was there after that: The state_province field was being showing as numeric instead of a label/string, so I've additionally used the PR https://github.com/colemanw/webform_civicrm/pull/941 which seems to resolve all my issues.
I've been running the above fix more than a week now without any mentioned side-effects. Can someone confirm that this is the right approach and I'm not missing anything valuable?
Thanks!
VangelisP → created an issue.
Hi mdphoto.
Please try this patch that I've created, it should work/patch itself properly on the tag/version 3.1.1 of the module.
Please keep in mind that all my optimisations were made towards the users and not the classes. I currently have just a bunch of classes (less than 100)
VangelisP → created an issue.
I see, then we can mark this as a duplicate and continue on the #3388293 issue ? I believe it needs to be a combination of those 2 issues (the conditional actions need to apply on whatever subscriber event takes place)
VangelisP → created an issue.
Hello !
Attaching a new patch (r4) for the install/uninstall process part (mostly dependency and uninstall hook) as also some minor corrections (added description to the menu item of the reports)
Cheers!
1. Normally if I search for a date I would search for a specific date like "2023-10-12" or in between.
in between works, though we need to put 2023-10-11 and 2023-10-13 to search for entries 2023-10-12.
but equal to does not work for me. So currently I cant list the items with date of 2023-10-12 unless I use the in between above.
As far as I am aware, that's the way with the built in Drupal Views on D9/10 at the moment (unless I'm completely mistaken!). Take the "Recent Logs" for example, if you add a date filter and expose it along with the operator, you get the exact same behaviour, so unless we add dependency with popup selectors/3rd party drupal modules, I can't do much about it.
However, even if annoying, my personal belief is that experienced users can still work with it.
2. The config_log_views module should depend on config_log, so when config_log is uninstalled we also uninstall the submodule.
That I can do, yes (I'll create a new patch tomorrow for that)
(And a followup issue could be that normally we should not log config changes that are "no change", for example i got like 5 lines with no change on language.types. But that is unrelated to this issue.)
I agree, we can create a new issue and deal with those tasks
If that's the case, then attaching the r3 patch that covers this.
A basic date filter yes, besides, it's just a view that anyone can alter for his own purposes once they have the submodule installed.
What I wouldn't do is to add popup date selector as it's a separate module at the moment.
Excellent points!
Here are my thoughts:
1. That's my fault, I didn't see the warning/deprecation warnings on the page as i had them mute. For that issue, I would cover it by altering the explode function like this:
$newValue = ($values->config_log_data) ? explode("\n", $values->config_log_data) : [];
$originalValue = ($values->config_log_originaldata) ? explode("\n", $values->config_log_originaldata) : [];At the end, Drupal's Diff module wants array(s) to work with.
2. I think that's the most challenging part and here's what I would do: Since this is an array, I can get a count of its elements. If, for example, the elements are more than 7, I can instead make this field collapsible and hide the difference inside there (see the example screenshot).
That's just a thought, feel free to spam your ideas if you got any!
You have a point, I assumed that everyone was having the config_update module installed, which is not the case.
I've reworked the upgrade hook to use core functions instead.
VangelisP → created an issue.
You're right!
Attaching a revised version of the latest patch with a separate upgrade hook (8002)
I'm posting an updated .patch file that also includes the upgrade for the new column `originalData`.
This patch applies also some minor coding standards
Attaching a screenshot on how it looks.
I've actually hidden the data fields (excluded in the view) to make the diff appear properly
@nagy.balint if you think that this can work for the module, I can also provide an upgrade hook.
Additionally, I'm working on a revised view (I saw that you've merged the submodule/view) that will use the `diff` class to show the differences and also display the entry date.
VangelisP → created an issue.
I had the same issue and i can confirm that this patch on #2 works as expected. Can we merge this?
Thanks Shaggy!
Hello, is there a plan to merge this patch on #11 and make a new release?
Dear @jitendrapurohit it works perfectly well! I've tested it in both single-page and multi-page webforms and I can confirm that it retains the altered data and submits them properly.
Many thanks for the fix!
VangelisP → created an issue.
Coming back to this issue, I was able to identify how this issue/console error gets triggered.
On my main theme, I have the dependency: - core/jquery.once instead of - core/once.
That means that if we don't explicitly define in the webform_civicrm.libraries.yml that we want the dependency core/once for each js library that we're using, the webform will use the one of the theme (parent), which (in my case) was core/jquery.once.
My personal take on this is that we should enforce the proper dependencies so as to avoid any potential situations like mine, although I don't know how many people continue to use the old dependency core/jquery.once.
VangelisP → created an issue.
VangelisP → created an issue.
Hiya. Here's a patch for this issue, it seems to resolve it.
I rewrote the way to write the status message in Drupal.
The code was tested on 1.2.0/1.2x branch on Drupal 9.4.8