Myself and another tester were unable to replicate the error you were getting with the PR @jitendrapurohit.
Please see https://github.com/colemanw/webform_civicrm/pull/894#issuecomment-212528....
To me it seems reasonable to expect the CiviCRM handler to not run at all if it is disabled. So please review again and hopefully can get something in to fix this issue.
Thank you @stefan.butura!
On the Drupal side, set it up to multi-lingual: French and English. Drupal only has French (France) available.
On CiviCRM side, set it up to be multi-lingual with French (Canada) and English (Canada) (the latter is optional I think).
Then in civicrm.settings.php add:
define('CIVICRM_LANGUAGE_MAPPING_FR', 'fr_CA');
define('CIVICRM_LANGUAGE_MAPPING_EN', 'en_CA');
It doesn't matter what page; no need to create events (I think). I think it displays an error only mentioning "event" because that's the first entity where it encounters the error. I got the error on the home page too. example.org/fr
According to https://www.drupal.org/project/drupal/issues/3456176 🐛 10.3 upgrade now missing status-message theme suggestions Postponed this may be something that this theme needs to implement. So reopening the issue.
MessageCommand and the associated JavaScript API was added to Drupal core in 2019/Drupal 8.8.0, but was not used widely in Drupal core until 10.3.0, when the bigpipe module began using it to render messages created within bigpipe placeholders.
Because MessageCommand has not been used widely, many custom themes have not themed custom JavaScript messages.
For examples of how to override message theming, see:
core/themes/olivero/js/message.theme.js
and
core/themes/claro/js/messages.js
And the associated libraries-extend entries in those themes' .info.yml files.
I've got a PR https://github.com/eileenmcnaughton/civicrm_entity/pull/497. It will generate the entity types for all enabled locales instead of just the active one. The problem is that the code didn't account for the fact that entity types are cached so clearing cache depended on what the interface language was so it missed all the non-active locales.
nubeli → created an issue.
Might be related to this PR? https://github.com/colemanw/webform_civicrm/pull/866
This issue should still be marked as open. The PR is still active. https://github.com/colemanw/webform_civicrm/pull/866
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.