πŸ‡ΊπŸ‡ΈUnited States @markusa

Account created on 9 May 2007, almost 17 years ago
  • Senior Developer at SkvareΒ  …
#

Merge Requests

Recent comments

πŸ‡ΊπŸ‡ΈUnited States markusa

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.

πŸ‡ΊπŸ‡ΈUnited States markusa

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

πŸ‡ΊπŸ‡ΈUnited States markusa

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.

πŸ‡ΊπŸ‡ΈUnited States markusa

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

πŸ‡ΊπŸ‡ΈUnited States markusa

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...

πŸ‡ΊπŸ‡ΈUnited States markusa

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.

πŸ‡ΊπŸ‡ΈUnited States markusa

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?

πŸ‡ΊπŸ‡ΈUnited States markusa

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).

πŸ‡ΊπŸ‡ΈUnited States markusa

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.

πŸ‡ΊπŸ‡ΈUnited States markusa

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)

πŸ‡ΊπŸ‡ΈUnited States markusa

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

πŸ‡ΊπŸ‡ΈUnited States markusa

markusa β†’ created an issue.

πŸ‡ΊπŸ‡ΈUnited States markusa

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

πŸ‡ΊπŸ‡ΈUnited States markusa

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

πŸ‡ΊπŸ‡ΈUnited States markusa

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.

πŸ‡ΊπŸ‡ΈUnited States markusa

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"

πŸ‡ΊπŸ‡ΈUnited States markusa

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

πŸ‡ΊπŸ‡ΈUnited States markusa

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.

πŸ‡ΊπŸ‡ΈUnited States markusa

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
πŸ‡ΊπŸ‡ΈUnited States markusa

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.

πŸ‡ΊπŸ‡ΈUnited States markusa

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?

πŸ‡ΊπŸ‡ΈUnited States markusa

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

πŸ‡ΊπŸ‡ΈUnited States markusa

Is it metatag 2.0.0 ? We've experienced issues with that new version. There maybe more problems to sort out. The 1.x version has worked fine in the past, may use that in the meantime if possible.

In D10 with CE 4.0.x and Metatag 2.x, going to any of the Drupal version of pages, e.g. /civicrm-contact/[contact-id] fails with error

πŸ‡ΊπŸ‡ΈUnited States markusa

Thanks!! We'll be looking into why these fields are not automatically available in the template as variables

πŸ‡ΊπŸ‡ΈUnited States markusa

Website is a separate CiviCRM Entity. There is no url provided by the API, so we don't have a property. All the fields returned by an entity type's 'getfields' call (action create), have Drupal base field definitions automatically generated.

A contact can have multiple Websites as well.

In Drupal 7, I had a field type, "CiviCRM Entity Reference FIeld" .. which acted as a "remote reference field" or a "reverse reference field" .. The Inline Entity Form widget could be used as the field widget. Basically a standard entity reference field, but draws its values not from a Drupal field table, but from the CiviCRM database via API. We've explored porting this, but work remains in an early stage. Funding welcome :)

A bespoke programmatic computed field would be another way to do this, in a small custom module.

πŸ‡ΊπŸ‡ΈUnited States markusa

It is possible to add the way you did, or also adding bundle_property key to the civicrm_contact array in SupportedEntities, same as was done for events and activities.

https://github.com/eileenmcnaughton/civicrm_entity/blob/4.0.x/src/Suppor...

There simply hasn't been the desire or work put in to support that for contacts.

I'd want to test it well on module upgrade to make sure the experience is good for people upgrading.

Some people would want that feature and others would not. Would be neat if it was optional for people.

πŸ‡ΊπŸ‡ΈUnited States markusa

Hey Peter

Yep, you can do this.

To be able to manage display for an entity type, and create additional view modes, first you have to enable the CiviCRM Entity type at /admin/structure/civicrm-entity/settings

Check "CiviCRM Contact" to be able to do this for contacts.

After that you'll be able to add View display modes /admin/structure/display-modes/view/add/civicrm_contact

Then you can navigate to the "Manage Display" page, /admin/structure/civicrm-entity/civicrm-contact/display
After you've made a custom view module, you'll see a field set at the bottom of the page, "Custom display settings"
Enable your new view mode
Save, and after that you'll see a submenu item underneat the tabs to manage the fields on the new display.

Then you can configure the entity reference field on your node type, to use that display.
You can use different displays for different entity reference fields.

Let me know if further questions!

πŸ‡ΊπŸ‡ΈUnited States markusa

Working on a PR here: https://github.com/eileenmcnaughton/civicrm_entity/pull/430/files

Right now it can "trash" a contact from the edit form, but "un-trashing" doesn't work

The value of the "Contact in trash" field is reflected both on view pages / edit forms with this update.

πŸ‡ΊπŸ‡ΈUnited States markusa

Pushed this out to a release, in 8.x-3.5 and 4.0.0-alpha4

πŸ‡ΊπŸ‡ΈUnited States markusa

Ok great, if it fixes your error, that's what I need to know.
I'm testing the other scenarios we tested when originally making these updates. So far so good.

Likely to get merged soon and in next release sometime in June.

πŸ‡ΊπŸ‡ΈUnited States markusa

Here's a PR for the 8.x-3.x branch, which is what you are using for Drupal 9
https://github.com/eileenmcnaughton/civicrm_entity/pull/432
https://patch-diff.githubusercontent.com/raw/eileenmcnaughton/civicrm_en...

Please let me know if this fixes the issue for you, and if so, I'll get it merged.

πŸ‡ΊπŸ‡ΈUnited States markusa

@davej

Ok, yep, I think we need to enhance that logic. Double underscore was a way we tried to assume a table is a Drupal table.

πŸ‡ΊπŸ‡ΈUnited States markusa

The available documentation is here: https://docs.civicrm.org/sysadmin/en/latest/integration/drupal/views/#dr...

CiviCRM Entity never sets database user in any way. It uses the database connections in the settings.local.php

Fact is CE + Views will contruct one query when accesses data across two databases .. but only one database connection is used, thus its database user is used.

When using separate databases, and separate database users / passwords for each connection .. then Drupal needs to use one db user to connect to both databases. If one database user does not have access to both databases, then when the query that uses a join across tables is generated, then there is this error.

I think it would depend on whether the base table of the View is a CivICRM table or Drupal table, for which database connection, and thus database user is used.

In Drupal 7 and 8, we were able to use database prefixes, so the "Views integration" code that was used in Drupal 7, did work in 8 and 9, but was deprecated in 9, and was slated to be removed in Drupal 10, so we stopped relying on it. I'm not sure if that would help your case, but it may still work in D9.

I realize that if you use 2 different containers, that's the same as 2 different servers .. so giving the same user access to both databases is not easy/possible.

Another option you have is to install the CiviCRM tables into the Drupal database. In that scenario, you wouldn't need the extra connection in the civicrm.settings.php, and wouldn't have any issue

So your options are:
1) Both databases in one container, use same database user for both databases
2) Both databases in one container, give both database users privileges for both databases
3) Install CiviCRM tables into Drupal database and remove $databases['civicrm']['default'] from settings.local.php

Any other options that include code changes, if any are possible, would be a research project. That project would involve figuring if database queries can be constructed with Drupal API, that use 2 separate database connections. 1 query 2 connection credentials. AFAIK this is not possible in Drupal.

πŸ‡ΊπŸ‡ΈUnited States markusa

I don't think there is anything in CiviCRM Entity that needs to be done for this error.

"SELECT command denied to user" would mean that the database user accessing the database does not have permissions to query the CivICRM tabes .. this could be because CiviCRM tables are installed in a different database, and the database user would need access to both databases.

Note, that if CiviCRM tables are installed in a separate database, the Drupal settings.local.php needs a connection to it:

$databases['civicrm']['default'] = array (
  'database' => 'database name', // update this
  'username' => 'database username', // update this
  'password' => 'database password', // update this
  'prefix' => '',
  'host' => 'DATABASE_HOST' // maybe update this,
  'port' => '3306', // maybe update this
  'namespace' => 'Drupal\\Core\\Database\\Driver\\mysql',
  'driver' => 'mysql',
  'charset' => 'utf8mb4',
  'collation' => 'utf8mb4_general_ci',
);
πŸ‡ΊπŸ‡ΈUnited States markusa

It must be that the case is first saved without an assignee, or if assignee is assigned in a hook_civicrm_pre() implementation it is happening after CiviCRM's hook implementation is running.

CiviCRM validates based on what the api action.validate gives it.

It maybe possible to goto: /admin/structure/civicrm-entity/settings
"Advanced Settings"
Check "Disable pre/post hooks"

See if it works without error.

Let me know if that allows it to work.

πŸ‡ΊπŸ‡ΈUnited States markusa

Oh wow, that's nice. Thank you!

πŸ‡ΊπŸ‡ΈUnited States markusa

For anyone finding this via Google.
In the Nginx config for the site, had to turn off fastcgi_cache .. I didn't dig deeper yet as to why or how to conditionally enable that.
fastcgi_cache off;

πŸ‡ΊπŸ‡ΈUnited States markusa

Well now I feel dumb, I can't replicate on a local instance, something Nginx-y perhaps.

Changing to support request. Thanks for your time.

πŸ‡ΊπŸ‡ΈUnited States markusa

Here are headers for a request, using the right user credentials with HTTP Basic, after making a request with wrong credentials. The data property in the response is empty.

Using the -i flag with curl to get the headers.

HTTP/2 200 
server: nginx
content-type: application/vnd.api+json
x-powered-by: PHP/8.1.16
cache-control: must-revalidate, no-cache, private
date: Mon, 20 Mar 2023 22:01:33 GMT
x-drupal-dynamic-cache: HIT
x-ua-compatible: IE=edge
content-language: en
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
expires: Sun, 19 Nov 1978 05:00:00 GMT
x-generator: Drupal 9 (https://www.drupal.org)
content-security-policy: frame-ancestors 'self'
x-xss-protection: 1; mode=block
referrer-policy: no-referrer-when-downgrade
x-robots-tag: noindex, nofollow, nosnippet, noarchive

For more information, I am using JSONAPI Extras, and JSONAPI Include modules. I do have a small custom EventSubscriber, subscribing to KernelEvents::RESPONSE which unsets a value in the JSON response when one of the node's fields has a certain value. It simply decodes the response JSON, and if a certain url parameter in the request exists, I unset a value from the JSON, encode the JSON again, and do $event->getResponse()->setContent($content) .. Nothing in their specific to caching, or the authentication, but full disclosure.

πŸ‡ΊπŸ‡ΈUnited States markusa

I'm using this patch in Drupal 9.5.4 .. this fixed the not respecting the "row" setting.

https://www.drupal.org/files/issues/2023-01-01/3241295-ckeditor-height-9... β†’

πŸ‡ΊπŸ‡ΈUnited States markusa

Will reCaptcha be having a Drupal 10 version?

πŸ‡ΊπŸ‡ΈUnited States markusa

We did find another bug, and this was fixed and pushed out in the 3.4 release.

Production build https://api.contrib.social 0.61.6-2-g546bc20