🇺🇸United States @markusa

markusa → created an issue.

Thanks for reporting. The error is a symptom and not a one-line bug.

This is challenging.
https://github.com/eileenmcnaughton/civicrm_entity/blob/4.0.x/src/Entity...

That plugin works for simple things, but when conditions are condition groups, it does not.

I'm not aware of being able to do condition groups in CiviCRM APIv3

This maybe possible in a future update when we upgrade CiviCRM Entity to use APIv4, we haven't used APIv4 in this module yet. It maybe possible to attempt in only this plugin, and not modifying the API service, quicker

I'm calling this a feature request due to the complexity and effort of the solution.

If you need a solution for your site in the near term, I'd suggest not using the EntityQuery at all, but APIv4 Directly
https://docs.civicrm.org/dev/en/latest/api/v4/usage/

\Drupal::service('civicrm')->initialize();
// APIv4 code here

I've created a PR that will be included in a release shortly:
https://github.com/eileenmcnaughton/civicrm_entity/pull/488

We've made this module, works in D10 and now D11
https://www.drupal.org/project/civicrm_reroute_mail →

The MR was merged

MR is merged.

markusa → created an issue.

Confirmed the MR works with both 10.2.13 (before change) and 10.2.14 (after change)

I'm not sure how far back that fix will work for, the create() method we're adding to the extended object, from the original, has been in its current form for 4 years, other than the change from "static" to "self"

Should actually work for much older versions then.

I'm inclined to merge this MR

markusa → created an issue.

Merged, and this will be in next release

We've created a PR with this change in the github repo: https://github.com/eileenmcnaughton/civicrm_entity/pull/486

Good to reference this: https://civicrm.stackexchange.com/questions/39989/drupal-9-views-rich-te...

Should be able to rewrite the field value in Views, and use a twig "raw" filter

Replace "description__value__value" with the machine name of the Views field.

We merged this: https://github.com/eileenmcnaughton/civicrm_entity/pull/478

PR merged and will be included in 4.0.0-beta3

PR in Github has been created here: https://github.com/eileenmcnaughton/civicrm_entity/pull/477

Looking to merge and put in upcoming release

Made PR in github repo to run tests: https://github.com/eileenmcnaughton/civicrm_entity/pull/479

I'm looking to see if this change would cause problems in any older versions of CiviCRM.

Merged to 3.x and 4.0.x https://github.com/eileenmcnaughton/civicrm_entity/pull/476

PR Merged in github, going out in next release

I think this is a leaflet issue.
Leaflet integration was pulled out into a separate module: https://www.drupal.org/project/civicrm_entity_leaflet →

Did a custom template recently and the custom fields were available and showed values when the template was rendered.

Views relationships from Events to price sets, then to price field, then to price field values entity types was made in the past and merged. This feature is supported now.

This was fixed with this PR: https://github.com/eileenmcnaughton/civicrm_entity/pull/371

PR was merged and is going out in new release soon.

I've seen this error in a number of situations. This error bubbles up if there is a CiviCRM error when CE invokes the alter entities hook. I've seen a number of different errors cause this, like missing extensions, a PHP compatibility bug in extensions.

There is nothing to fix in CE for this.

Not supporting the D7 version excepting for critical issues.

Several PRs recently to deal with timezone / date issues. Marking as fixed

The updated database user / password should be set in the settings.local.php

$databases['civicrm']['default'] = array (
  'database' => 'database_name',
  'username' => 'database_user',
  'password' => 'database_password',
  'prefix' => '',
  'host' => 'localhost',
  'port' => '3306',
  'namespace' => 'Drupal\\Core\\Database\\Driver\\mysql',
  'driver' => 'mysql',
);

I could replicate this issue. "Manage Display" can be broken if addtocalendar module is installed

errors like
Drupal\Core\Field\FieldException: Attempt to create a base field bundle override of field birth_date without a bundle in Drupal\Core\Field\Entity\BaseFieldOverride->__construct() (line 110 of /var/www/web/distro10.skvare.com/web/core/lib/Drupal/Core/Field/Entity/BaseFieldOverride.php).

Backtrace:

Backtrace	
#0 /var/www/web/distro10.skvare.com/web/core/lib/Drupal/Core/Config/Entity/ConfigEntityStorage.php(222): Drupal\Core\Field\Entity\BaseFieldOverride->__construct()
#1 /var/www/web/distro10.skvare.com/web/core/lib/Drupal/Core/Entity/EntityStorageBase.php(232): Drupal\Core\Config\Entity\ConfigEntityStorage->doCreate()
#2 /var/www/web/distro10.skvare.com/web/core/lib/Drupal/Core/Field/Entity/BaseFieldOverride.php(75): Drupal\Core\Entity\EntityStorageBase->create()
#3 /var/www/web/distro10.skvare.com/web/core/lib/Drupal/Core/Field/BaseFieldDefinition.php(784): Drupal\Core\Field\Entity\BaseFieldOverride::createFromBaseFieldDefinition()
#4 /var/www/web/distro10.skvare.com/web/modules/contrib/addtocalendar/includes/addtocalendar.form.inc(91): Drupal\Core\Field\BaseFieldDefinition->getConfig()
#5 /var/www/web/distro10.skvare.com/web/modules/contrib/addtocalendar/addtocalendar.module(34): _addtocalendar_build_form()
#6 /var/www/web/distro10.skvare.com/web/core/modules/field_ui/src/Form/EntityViewDisplayEditForm.php(162): addtocalendar_field_formatter_third_party_settings_form()
#7 /var/www/web/distro10.skvare.com/web/core/lib/Drupal/Core/Extension/ModuleHandler.php(388): Drupal\field_ui\Form\EntityViewDisplayEditForm->Drupal\field_ui\Form\{closure}()
#8 /var/www/web/distro10.skvare.com/web/modules/contrib/config_track/src/Extension/ModuleHandler.php(236): Drupal\Core\Extension\ModuleHandler->invokeAllWith()
#9 /var/www/web/distro10.skvare.com/web/core/modules/field_ui/src/Form/EntityViewDisplayEditForm.php(168): Drupal\config_track\Extension\ModuleHandler->invokeAllWith()
#10 /var/www/web/distro10.skvare.com/web/core/modules/field_ui/src/Form/EntityDisplayFormBase.php(451): Drupal\field_ui\Form\EntityViewDisplayEditForm->thirdPartySettingsForm()
#11 /var/www/web/distro10.skvare.com/web/core/modules/field_ui/src/Form/EntityViewDisplayEditForm.php(41): Drupal\field_ui\Form\EntityDisplayFormBase->buildFieldRow()
#12 /var/www/web/distro10.skvare.com/web/core/modules/layout_builder/src/Form/LayoutBuilderEntityViewDisplayForm.php(227): Drupal\field_ui\Form\EntityViewDisplayEditForm->buildFieldRow()
#13 /var/www/web/distro10.skvare.com/web/core/modules/field_ui/src/Form/EntityDisplayFormBase.php(213): Drupal\layout_builder\Form\LayoutBuilderEntityViewDisplayForm->buildFieldRow()
#14 /var/www/web/distro10.skvare.com/web/core/modules/layout_builder/src/Form/LayoutBuilderEntityViewDisplayForm.php(47): Drupal\field_ui\Form\EntityDisplayFormBase->form()
#15 /var/www/web/distro10.skvare.com/web/core/lib/Drupal/Core/Entity/EntityForm.php(107): Drupal\layout_builder\Form\LayoutBuilderEntityViewDisplayForm->form()

I made a PR from the patch to run tests:
https://github.com/eileenmcnaughton/civicrm_entity/pull/475

The original issue here is fixed and will be in next release

I've merged this PR and will publish a new 7.x release soon

markusa → created an issue.

It is always possible to add a patch with composer
The patch is available by adding ".patch" to the PR url
https://patch-diff.githubusercontent.com/raw/eileenmcnaughton/civicrm_en...

So in the "extras" portion of composer.json
"patches": {
"drupal/civicrm_entity": {
"raw values fix": "https://patch-diff.githubusercontent.com/raw/eileenmcnaughton/civicrm_en..."
}
},

Patches with composer requires cweagans/composer-patches

This is great, thanks for the patch and instructions!!

I see that the ckeditor5 wysiwyg is very short. Has anyone experienced that?
Same issue that was fixed in D10 here: https://www.drupal.org/node/3330010 →

The "Rows" property of the long text field is not respected.

As any one encountered this, and fixed it?

We're seeing sites getting affected now.
Files appear in sites/default/files/js
$ find ./ -name "*wysiwyg_ckeditors*"
./sites/default/files/js/wysiwyg_ckeditors_uWMoMQ5qlhtyHc-FJlMT-azsAxhCeS89weKBiAtXujlM.js
/sites/default/files/js/wysiwyg_ckeditors_uWMoMQ7qlhtyf-cFJlMTazsAxhCeS88weKBiAtXujAQ.js

These files contain list of links to phishing sites.

1 site fully compromised, and another looking like its happening.

Disable or remove Ckeditor from being used immediately.

Ok, i understand now .. a CiviCRM custom contact reference field :) I was thinking something else.

I'll play around and see what I can provide for a snippet, and/or experiment with this PR

Something like this may work too:

$contact = $row->_entity->get('field_reference')->entity;
$contact_id = $contact->id();

Would you like to make a PR in the github repo as well? Primary development happens there at this time.
https://github.com/eileenmcnaughton/civicrm_entity/

I feel it shouldn't be necessary, but perhaps I don't understand the situation exactly.

What about:
$row->_entity->get('field_name')->target_id

I've got at least 5 production sites with Drupal 10 that don't have the Rules module, and do have the CiviCRM Entity module, running without error.

There's got to be some other reason.

Was Rules installed for some time, but has been recently uninstalled?

Perhaps there is another module that is discovering the plugin, that I don't have.

Regardless, it is not hard to move anything Rules related to a submodule

Here is a PR which you can use to patch with: https://github.com/eileenmcnaughton/civicrm_entity/pull/462
https://patch-diff.githubusercontent.com/raw/eileenmcnaughton/civicrm_en...

I tested on a local setup of Drupal 10.2.2 and CiviCRM 5.69

I uninstalled the Rules module for this test, after uninstalling, removing Rules code, and clearing caches, I am still able to edit custom blocks

I see in the error message you documented, that it is a CiviCRM Entity Rules Condition plugin that is not finding the base class from Rules. That is a plugin, and should be able to be in the codebase without Rules installed. Rules during its plugin discovery would look for modules that implement plugins

Being unable to replicate, I wonder if there is something cache in your case, that may need a reset.

Perhaps there is some other reason other than Rules being uninstalled that maybe the cause.

markusa → created an issue.

When I "View Source" of admin vs. front end pages ..
On admin pages:
I see an aggregated js file, then 2 gtm js scripts NOT aggregated and then a couple more aggregated JS files
On the front end, I don't see the un-aggregated gtm scripts in the source.

So whatever its doing, when the gtm scripts are NOT in the aggregated scripts, the condition occurs.

If I configure the Google Tag module to exclude /admin/* pages, the condition disappears.

What bothers is why on the admin theme only, is there some 3rd component interacting?

markusa → created an issue.

This module is causing a JS aggregation issue in Drupal 10.1
Advanced Aggregation module is not installed.

Symfony\Component\HttpKernel\Exception\BadRequestHttpException: Invalid filename. in Drupal\system\Controller\AssetControllerBase->getGroup() (line 224 of ./web/core/modules/system/src/Controller/AssetControllerBase.php).

Recent versions of Inline Entity Form require additional development in CiviCRM Entity.

We are aware of this error but have not had funding or time allocation for this feature as of yet. I think that will happen in due course, but please reach out if you are interested in helping with this feature, for that development to be expedited.

We started a WIP PR here: https://github.com/eileenmcnaughton/civicrm_entity/pull/434/files
It is simplistic, and known not to work with entity types that support bundles (Activity, Event)

That patch will not apply cleanly to updates in the module, but it is simple, few line patch to get started.

This WIP PR, it will make it so there is no "Is All of" operator

Changing to IN or NOT IN

This seems ok to me, as no activity would ever have 2 statuses, nor event types (not fixed in PR yet)

WIP/Draft PR for activity_status and activity_type_id properties

https://github.com/eileenmcnaughton/civicrm_entity/pull/460

The changes which Core filter plugin is used for these properties.

This may not be the final solution. We're considering what is best. The error seems like a Core issue
https://www.drupal.org/project/drupal/issues/2829178#comment-13751033 🐛 Views Term ID has broken filters ("All of", "Is none of") and contextual filters "allow multiple" Needs work

Or its very similar.

Note if you use this PR, you will need to clear Drupal caches, and edit the View to adjust settings for the filter plugin

markusa → created an issue.

I tested upgrading a site from 5.63 to 5.67.3 and then upgrading CiviCRM, and also requiring into a blank D10 site
composer create-project drupal/recommended-project new-blank-d10
composer require civicrm/civicrm-core civicrm/civicrm-packages civicrm/civicrm-drupal-8
as of this date, 5.67.3 pulled in for CiviCRM, then
composer require 'drupal/civicrm_entity:^4.0@beta'

Composer kept civicrm at 5.67.3 afterwards.

I'll need more specific information to assist

I think its possible that something else is causing a downgrade. CiviCRM Entity itself is not making any version requirements for CiviCRM
https://github.com/eileenmcnaughton/civicrm_entity/blob/4.0.x/composer.json

{
    "name": "drupal/civicrm_entity",
    "type": "drupal-module",
    "description": "Expose CiviCRM entities as Drupal entities.",
    "homepage": "http://drupal.org/project/civicrm_entity",
    "license": "GPL-2.0+",
    "require": {
        "drupal/core": "^10",
        "civicrm/civicrm-drupal-8": "*"
    },
    "require-dev": {
        "drupal/fullcalendar_view": "^5.0"
    },
    "minimum-stability": "dev"
}

I'll look into it, but can't think of why it would downgrade from 5.67.3 to 5.67.1

SQLSTATE[HY000] [1045] Access denied
This would be that the database user does not have access to the CiviCRM tables.

Yeah, could try changing the password.

It is normal not to see any fields here:
/admin/structure/civicrm-entity/civicrm-contact/fields

This is the form for adding any Drupal native fields, but there would not be any there when first installing or setting up.

Do you see contacts listed here?
/admin/structure/civicrm-entity/civicrm-contact

Back to your Drupal View.

Have you tried adding "Display Name" field to the view?

What "Format" and "Show" values do you have on your View configuration?
Try "Format" = "Unformatted List" and "Show" = "Fields"

Views of contacts should not require 'view all contacts'.

For my information are you rendering an display of the contact entity, or do you only have fields on the View.

Can you provide the the configuration export for the View?

Some of the ways this could work could be a matter of opinion on bug vs. feature, but I want to make sure I undesrstand your case most clearly.

ALso, there is a contributed PR that we chose not to merge, but maybe helps you, and maybe we re-consider it.
https://github.com/eileenmcnaughton/civicrm_entity/pull/262

Code was merged to 4.0.x branch in the github repo. We're gearing up to push updates to Drupal.org repo very soon for a new release.

My example "Entity Form Display" core.entity_form_display.civicrm_event.civicrm_event.default.yml

uuid: c60b85ee-a8cc-44d2-9eec-9e3ad441cb55
langcode: en
status: true
dependencies:
  module:
    - civicrm_entity
    - datetime
    - field_group
third_party_settings:
  field_group:
    group_fieldset_test:
      children: {  }
      label: 'Fieldset Test'
      region: hidden
      parent_name: ''
      weight: 5
      format_type: fieldset
      format_settings:
        classes: ''
        show_empty_fields: false
        id: ''
        description: ''
        required_fields: true
    group_accordian_parent_test:
      children:
        - group_accordion_one
        - group_accordion_two
      label: 'Accordian Parent Test'
      region: content
      parent_name: ''
      weight: 4
      format_type: tabs
      format_settings:
        classes: ''
        show_empty_fields: false
        id: ''
        direction: vertical
        width_breakpoint: 640
        effect: none
    group_accordion_one:
      children:
        - event_type_id
      label: 'Accordion One'
      region: content
      parent_name: group_accordian_parent_test
      weight: 21
      format_type: tab
      format_settings:
        classes: ''
        show_empty_fields: false
        id: ''
        formatter: closed
        description: ''
        required_fields: true
        effect: none
    group_accordion_two:
      children:
        - registration_start_date
        - registration_end_date
      label: 'Accordion Two'
      region: content
      parent_name: group_accordian_parent_test
      weight: 22
      format_type: tab
      format_settings:
        classes: ''
        show_empty_fields: false
        id: ''
        formatter: closed
        description: ''
        required_fields: true
id: civicrm_event.civicrm_event.default
targetEntityType: civicrm_event
bundle: civicrm_event
mode: default
content:
  description:
    type: civicrm_entity_textarea
    weight: 0
    region: content
    settings:
      rows: '5'
      placeholder: ''
    third_party_settings: {  }
    rows: 8
  event_type_id:
    type: options_select
    weight: 10
    region: content
    settings: {  }
    third_party_settings: {  }
  is_online_registration:
    type: boolean_checkbox
    weight: 2
    region: content
    settings:
      display_label: true
    third_party_settings: {  }
  registration_end_date:
    type: datetime_default
    weight: 9
    region: content
    settings: {  }
    third_party_settings: {  }
  registration_link_text:
    type: string_textfield
    weight: 3
    region: content
    settings:
      size: 60
      placeholder: ''
    third_party_settings: {  }
  registration_start_date:
    type: datetime_default
    weight: 7
    region: content
    settings: {  }
    third_party_settings: {  }
  title:
    type: string_textfield
    weight: 1
    region: content
    settings:
      size: 60
      placeholder: ''
    third_party_settings: {  }
hidden:
  allow_same_participant_emails: true
  allow_selfcancelxfer: true
  approval_req_text: true
  bcc_confirm: true
  campaign_id: true
  cc_confirm: true
  confirm_email_text: true
  confirm_footer_text: true
  confirm_from_email: true
  confirm_from_name: true
  confirm_text: true
  confirm_title: true
  created_date: true
  created_id: true
  currency: true
  custom_2: true
  custom_3: true
  custom_4: true
  custom_5: true
  custom_6: true
  custom_7: true
  dedupe_rule_group_id: true
  default_discount_fee_id: true
  default_fee_id: true
  default_role_id: true
  end_date: true
  event_full_text: true
  expiration_time: true
  fee_label: true
  financial_type_id: true
  footer_text: true
  has_waitlist: true
  initial_amount_help_text: true
  initial_amount_label: true
  intro_text: true
  is_active: true
  is_billing_required: true
  is_confirm_enabled: true
  is_email_confirm: true
  is_map: true
  is_monetary: true
  is_multiple_registrations: true
  is_partial_payment: true
  is_pay_later: true
  is_public: true
  is_share: true
  is_show_location: true
  is_template: true
  loc_block_id: true
  max_additional_participants: true
  max_participants: true
  min_initial_amount: true
  parent_event_id: true
  participant_listing_id: true
  pay_later_receipt: true
  pay_later_text: true
  payment_processor: true
  requires_approval: true
  selfcancelxfer_time: true
  slot_label_id: true
  start_date: true
  summary: true
  template_title: true
  thankyou_footer_text: true
  thankyou_text: true
  thankyou_title: true
  waitlist_text: true

Testing on a local, I am able to have field groups work on edit form, testing on the civicrm_email and civicrm_event entity types.
Using exact copy of 8.x-3.x available on D.O

In D9 you have to add a field group of type "Tabs" .. then add additional field groups of type "Tab", and nest that under the "Tabs" one, and then next your fields inside the tab groups.

if you have only a "Tabs" without "Tab" groups, or vice versa, it will not work correctly.

Using Field Group 8.x-3.4 in testing

We had a bug earlier in the year for Event and Activity types, but fixed it: I thought we took care of this here: https://github.com/eileenmcnaughton/civicrm_entity/pull/415

So field groups is supported.

markusa → created an issue.

markusa → created an issue.

D8+ version doesn't work with Search API

I did just try it recently actually, and if Civi tables are in a separate database, doesn't work at all as the DataSource tries to query from the Drupal database.

Do you have Civi tables in the same database as Drupal?

The MR is merged into the github repo 4.0.x branch and will go out in next release to the public

For people hunting for a workaround fix
https://drupal.stackexchange.com/questions/300821/import-single-view-con...