🇺🇸United States @markusa

There were fixes in newer versions of the module, if you're still using beta1, I recommend upgrading to latest.

nginx fastcgi caching was the culprit. Nothing with this module wrong for this issue

markusa → created an issue.

Created PR for this. https://github.com/eileenmcnaughton/civicrm_entity/pull/489
Replicated the condition with Metatag 2.0
Similar fix was for viewing entities: https://github.com/eileenmcnaughton/civicrm_entity/pull/481/files

I dug into this a bit.

I found that the civicrm api call used to retrieve the contact values from the database, does not return addressee_custom in the result.

In Core, this function determines fields to exclude:
https://github.com/civicrm/civicrm-core/blob/master/CRM/Contact/BAO/Cont...

Normal CiviCRM API3 Contact.get calls are the same. So it would take something different than what we do to retrieve and populate this field.

It will work for saving a value from the /civicrm-contact/[id]/edit form, as the contact.create API accepts the value.

We could do a separate direct db query, or perhaps a DAO sql query, and then populate the values. This has been this way for a long long time, and this is the first request for it.

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.