Thank you ChrisDarke for the patch. I've applied it to the Backdrop version of the module: https://github.com/backdrop-contrib/auto_entitylabel/issues/17
The password validation error currently shows the password score, which is not a good user experience.
This claim is debatable. Without any kind of supporting evidence, or general agreement of those using the module, I'm inclined to say I won't change this.
I would also argue the opposite: providing some indication of the bar that must be met to have a strong-enough password is helpful, even if imperfect.
Thanks for the fix!
nubeli → made their first commit to this issue’s fork.
A simple way to recreate this:
1. Create a new paragraph type "Wrapper" and add a new paragraph field to it.
2. Allow that paragraph field to reference Columns (equal).
3. Create a content type, add a new paragraph field which can reference "Wrapper" paragraph types.
4. Create a new node and add a wrapper paragraph. Then add a Columns (equal) inside that and a Simple paragraph inside that.
5. Set either/both Columns / Simple to Medium/Narrow, whatever. Save.
The widths will be lost on all nested paragraphs.
The CSS assumes that the floats, margin-left and width should only apply to a column that's a direct child of .paragraph--type--bp-columns__* .paragraph--width-*, which makes some sense.
In my case, my workaround was to copy the columns css and add the wrapper class to the beginning so they float again if inside the wrapper. I haven't fully tested if it breaks any nested. I'm sure there's a better way to do this.
Looks like this is unlikely to be fixed in the 7.x-1,x branch. Thank you Tom and Manuel for the patches. I ended up using the batched process patch ( https://www.drupal.org/files/issues/2018-05-31/2314327-16.patch → ) in my patch to the Backdrop port of this module: https://github.com/backdrop-contrib/field_encrypt/pull/6/files. It is almost identical so I thought I'd share it here. I had to fix some issues with that patch:
- It should be comparing this:
$vid == $result->revision_id, not$id == $result->revision_id. In the latter it never populates thefield_data_*table - I have it checking if the entity exists in case an entity was deleted but didn't delete the record in the table (which happened to me).
- There is one
field_encrypt_encrypt()call that has a fatal error because it's missing a line to load the inc file. Should havemodule_load_include('inc', 'field_encrypt', 'field_encrypt');above the foreach. - I also added some checks for
db_table_exists()because you never know.
After that it ran fine, and I believe it should work fine for Drupal 7 as well. I had a client that was using the old beta and there is no working upgrade path for the 7.x-1.x branch so I decided to incorporate it into the Backdrop port so others can benefit as well.
It's merely a courtesy to the maintainers to know that the fork exists in case they wish to respond or contribute. It can be closed.
This module was ported to Backdrop CMS from the Drupal 7 version. I'm a current maintainer of the port.
If anyone is interested in contributing—by reporting issues, providing Pull Requests, testing, providing documentation, or co-maintaining—visit the project page on Github.
This module was ported to Backdrop CMS from the Drupal 7 version. I'm a current maintainer of the port.
If anyone is interested in contributing—by reporting issues, providing Pull Requests, testing, providing documentation, or co-maintaining—visit the project page on Github.
This module was ported to Backdrop CMS from the Drupal 7 version. I'm a current maintainer of the port.
If anyone is interested in contributing—by reporting issues, providing Pull Requests, testing, providing documentation, or co-maintaining—visit the project page on Github.
This module was ported to Backdrop CMS from the Drupal 7 version. I'm a current maintainer of the port.
If anyone is interested in contributing—by reporting issues, providing Pull Requests, testing, providing documentation, or co-maintaining—visit the project page on Github.
This module was ported to Backdrop CMS from the Drupal 7 version. I'm a current maintainer of the port.
If anyone is interested in contributing—by reporting issues, providing Pull Requests, testing, providing documentation, or co-maintaining—visit the project page on Github.
That works for me. Code change is tiny.
Works for me.
This repo exists: https://github.com/fuzionnz/webform_civicrm_migrate. A better approach may be to have that module move to drupal.org and be officially supported.
PR here: https://github.com/backdrop-contrib/backdrop_upgrade_status/pull/37. If it works for you @irinaz I'm merge it in github and sync it here.
Yeah, let's do that, but when it's got an official release.
PR: https://github.com/colemanw/webform_civicrm/pull/894 - it check if handler is enabled in _fillCiviCRMData(). This at least seems to ensure that the webform_civicrm service isn't called.
Turns out even disabling the webform_civicrm handler doesn't quite prevent webform_civicrm from being called. https://www.drupal.org/project/webform_civicrm/issues/3375337 🐛 Disabling the webform_civicrm handler doesn't prevent it from being called Needs work
nubeli → created an issue.
nubeli → created an issue.
This issue is marked as fixed but the PR is still open: https://github.com/colemanw/webform_civicrm/pull/866. What was fixed and where?
I've got the same error running cron from drush. The MR works for me and the code looks good.
I've reviewed and tested the patch in #9. It works -- HTML looks fine -- and code appears good. Simple change (plus a few cosmetic fixes).
This issue appears to be outdated.
The MR looks mostly okay as a minimal README. Incorrect spelling: "stablish" should be "establish".
This seems similar to https://www.drupal.org/project/civicrm_member_roles/issues/3254493 🐛 Member Role sync failing with membership with Pending status Fixed so marking this as duplicate. Please reopen if I'm mistaken.
I've tested without the patch → to confirm that it doesn't sync properly and also tested with the patch. The patch works and the code looks good.
The code looks good in this patch https://www.drupal.org/files/issues/2022-09-29/3312593-3.patch → and it works.
This issue is a duplicate of https://www.drupal.org/project/civicrm_member_roles/issues/3270435 💬 Manual synchronization error Fixed . The latter has a working MR so closing this one.
The MR https://git.drupalcode.org/project/civicrm_member_roles/-/merge_requests/2 works for me. The code looks good to me.
@seamus_lee your patch gives this error: "Class "Drupal\civicrm_member_roles\Database" not found". Need to add use Drupal\Core\Database\Database; I think.
I just found out that this module will work for the end date, but not the start. Perhaps it's related to how start and end dates are treated in the filter UI. End date appears like: field_date:end_value and start date like: field_date
This also happens when adding a Relationship to "CiviCRM Contact (Contact(s) assigned to this activity.)" or "CiviCRM Contact (Contact(s) participating in this activity.)". But there's a relationship called "CiviCRM (Relate CiviCRM contact to CiviCRM activity.)" that does work.
I've reviewed and tested the patch in #112, which includes tests. Looks like it's all in order. I've applied the patch with composer locally and then did a drush cache rebuild. The error disappears.
I'm not clear why this was switched to the 11.x-dev version back in #103. According to https://www.drupal.org/about/core/policies/core-release-cycles/schedule → it seems that this bug fix could even go into 9.5.x. At the very least 10.0.x.
So I propose then that we update the documentation to include the caveats: https://docs.civicrm.org/sysadmin/en/latest/integration/drupal/views/#dr... and also add a link to the docs in civicrm/admin/setting/uf, which currently looks like this for Drupal 9:
But this is misleadingly simplified, as noted in this conversatoin.
I will create an issue here https://lab.civicrm.org/documentation/docs/sysadmin/-/issues to do that.
@markusa, it seems like you didn't read the whole issue description. I detail *exactly* when this happens but your response seems like it didn't address any of that.
It's not a problem of the settings files, because they *do* work when just creating a simple View of contacts (or whatever). The error only arises when trying to do a JOIN across contacts to users. *And* it only happens if the databases are in separate service containers (or servers). If they are in the same container the error doesn't appear (all else being the same).
I also mentioned above what CiviCRM Entity *could* do: that is, provide documentation so people know that currently CiviCRM Entity won't fully work if the CiviCRM database is on a different server or service container.
Currently I don't see any documentation of this module for Drupal 9+.
nubeli → created an issue.
nubeli → created an issue.
I can confirm that this patch fixes the issue. Simple enough $views_field has to be an array so it should never be assigned anything else.
Before patching:
I see this error on many pages, including Extend, Admin Content, ...:
Warning: foreach() argument must be of type array|object, null given in Drupal\Component\Utility\NestedArray::mergeDeepArray() (line 327 of core/lib/Drupal/Component/Utility/NestedArray.php).
Drupal\Component\Utility\NestedArray::mergeDeepArray(Array) (Line: 295)
Drupal\Component\Utility\NestedArray::mergeDeep(Array, NULL) (Line: 452)
Drupal\views\EntityViewsData->mapFieldDefinition('civicrm_activity', 'details', Object, Object, Array) (Line: 110)
After patching:
No error.
Thank @milos.kroulik! Merged.
I was able to determine the issue on this particular site. This is not required.
Though aside, I'm wondering why webform_civicrm has \Drupal::service('civicrm')->initialize(); for some things but not others when the handler itself deals with initializing CiviCRM. Maybe it's not required in those cases either.
@Ranjit1032002 there are a few problems with the patch:
- WebformCivicrmPostProcess::adjustPageBreak() doesn't exist.
- WebformCivicrmPostProcess::checkBillingPagination() doesn't exist.
- Replacing drupal_set_title() with just $this->t('...) doesn't do anything. You need to assign it to something and figure out a way to alter the title.
- webform_submission_access() doesn't exist.
- WebformCivicrmPostProcess::preprocessComponentsForm() doesn't exist.
Please put in a bit more thought into the PR before submitting it.
The only thing that potentially works in this PR is putting in \Drupal::service('civicrm')->initialize();.
After fixing things, I suggest testing out the PR first before posting it for others to review or test.
@jitendrapurohit that's not the issue - the CiviCRM handler is on the webform. So I'm not sure where things are wrong. But I figured that it's probably better to ensure that CiviCRM is initialized at that step anyway. Similar patterns are used elsewhere in the module, though inconsistently. For instance in webform_civicrm.module, on Line 141, 876, ... in Utils.php line 566
PR ready for another review https://github.com/colemanw/webform_civicrm/pull/866#pullrequestreview-1...
nubeli → created an issue.
nubeli → created an issue.
nubeli → created an issue.
I created a pull request: https://github.com/colemanw/webform_civicrm/pull/865
nubeli → created an issue.
In regards to this question by Karen:
And why are you migrating webform submissions that have civicrm components? The key usage for webform module is to get data into CiviCRM so it's just a front end/method to do so.
Our client is using it as semi-permanent storage. They have over 40 webforms connected to CiviCRM and some of them are tracking data long-term for users/contacts. And they've also got a webform with a component that references a content type that is also "owned" by the user. Users make yearly submissions that can then tracked in Views to show changes over time in user responses.
So that's why we're making sure submissions get migrated over properly.
I can confirm that jensschuppe reported. Not only does it write to the CiviCRM tables, such as recreate activities, etc, it also will send out confirmation emails if a webform was used to subscribe to mailing groups. The latter can be handled by disabling outgoing emails during the migration, but it cleaner if there was a way to avoid all processing on a migration since the processing already happened the first time.
Perhaps there's a way to temporarily disable the CiviCRM handler in a migration script. I've been using https://github.com/fuzionnz/webform_civicrm_migrate so perhaps it could be done there. This looks like a promising hook:
hook_webform_handler_invoke_alter(\Drupal\webform\Plugin\WebformHandlerInterface $handler, $method_name, array &$args)
. If the CiviCRM handler is disabled then there would need to be a submission handler specific for the webform_civicrm_submissions table, similar to D7WebformSubmission in the webform_migrate module.
nubeli → created an issue.
I see the change in the repo. So this is fixed no?
Trying a simplified version of the patch. Not sure why it didn't apply.
Gotcha. I've uploaded a patch for the entire MR. See if that works.
Good point Liam. Even simpler. I've updated the MR. (I'm still confused by the Drupal/gitlab workflow so hopefully I did that correctly - I mostly use github or gitlab with CiviCRM).
I realized how to reliably recreate it: if a component is added after the submission was created then the $value is NULL. And this is for any kind of component so they all need to ensure $value is not NULL.
@RenatoG's MR is probably fine. Or we could also do:
$return[] = (is_array($value) && count($value)) ? implode(',', $value) : '';
which is a bit more concise and won't change the output.
The funny thing is that all instances of _webform_csv_data_component() seems to assume that $value is an array (as far as I can tell), but in webform_results_download_rows_process() it can be either an array or NULL (maybe other?). In this part:
// Let each component add its data.
$raw_data = isset($submission->data[$cid]) ? $submission->data[$cid] : NULL;
if (webform_component_feature($component['type'], 'csv')) {
$data = webform_component_invoke($component['type'], 'csv_data', $component, $options, $raw_data);
For the most it part it doesn't seem to be a problem, but here it is.