Same error on config:import on Drupal 10.4.5.
[error] Error: Call to a member function setSyncing() on null in Drupal\Core\Config\Entity\ConfigEntityStorage->importDelete() (line 383 of /var/www/html/drupal/web/core/lib/Drupal/Core/Config/Entity/ConfigEntityStorage.php) #0 /var/www/html/drupal/web/core/lib/Drupal/Core/Config/ConfigImporter.php(1068): Drupal\Core\Config\Entity\ConfigEntityStorage->importDelete()
#1 /var/www/html/drupal/web/core/lib/Drupal/Core/Config/ConfigImporter.php(851): Drupal\Core\Config\ConfigImporter->importInvokeOwner()
#2 /var/www/html/drupal/web/core/lib/Drupal/Core/Config/ConfigImporter.php(672): Drupal\Core\Config\ConfigImporter->processConfiguration()
#3 /var/www/html/drupal/web/core/lib/Drupal/Core/Config/ConfigImporter.php(570): Drupal\Core\Config\ConfigImporter->processConfigurations()
#4 /var/www/html/drupal/vendor/drush/drush/src/Commands/config/ConfigImportCommands.php(259): Drupal\Core\Config\ConfigImporter->doSyncStep()
#5 /var/www/html/drupal/vendor/drush/drush/includes/drush.inc(62): Drush\Commands\config\ConfigImportCommands->doImport()
#6 /var/www/html/drupal/vendor/drush/drush/includes/drush.inc(53): drush_call_user_func_array()
#7 /var/www/html/drupal/vendor/drush/drush/src/Commands/config/ConfigImportCommands.php(230): drush_op()
#8 [internal function]: Drush\Commands\config\ConfigImportCommands->import()Patch from #30 seems to fixed the error.
Same error here.
Is there a way to disable or bypass the moderation model to flag the content?
Similar error while having v3.1.1 installed.
$ ddev drush gdpr-sql-dump --gzip > dump.sql.gz
> bash: line 1: gdpr_clone_users_field_data: command not found
> bash: line 1: users_field_data: command not found
Same error:
PHP message: Error: Attempt to assign property "view" on null in /var/www/html/web/core/modules/views/src/Entity/Render/TranslationLanguageRenderer.php on line 87 #0 /var/www/html/web/core/modules/views/src/Plugin/views/row/EntityRow.php(221): Drupal\views\Entity\Render\TranslationLanguageRenderer->preRender(Array)
#1 /var/www/html/web/core/modules/views/src/Plugin/views/style/StylePluginBase.php(444): Drupal\views\Plugin\views\row\EntityRow->preRender(Array)
#2 /var/www/html/web/core/modules/views/src/ViewExecutable.php(1513): Drupal\views\Plugin\views\style\StylePluginBase->preRender(Array)
#3 /var/www/html/web/core/modules/views/src/Plugin/views/display/DisplayPluginBase.php(2459): Drupal\views\ViewExecutable->render()
#4 /var/www/html/web/core/modules/views/src/ViewExecutable.php(1667): Drupal\views\Plugin\views\display\DisplayPluginBase->preview()
#5 /var/www/html/web/core/modules/views_ui/src/ViewUI.php(611): Drupal\views\ViewExecutable->preview('page_1', Array)
while using Views with CiviCRM entities.
The patch from #3 worked for Drupal 9.5.11.
I've tried to provide credentials as https://user:pass@example.com/access_token, but didn't work and ended up with too many redirect error (ERR_TOO_MANY_REDIRECTS).
Ok, thank you. I've got a good setup, so maybe it's something altering/disabling it. No errors in DevTools.
I'll have a look, debug and let you know the result.
kenorb → created an issue.
Tested changes from PR and it seems to work fine. Search API indexing for Civi entities works while having 2 databases ($databases['default']['default'] & $databases['civicrm']['default']).
Thanks for the patch, I'm going to test it.
I'm attaching patch for 8.x-3.x (so I can use it with Composer), since 4.x was slightly failing to apply.
The configuration in civicrm.settings.php points to the different db than local Drupal. So maybe mistakenly is using Drupal local db instead of what's configured in Civi's settings file?
This is duplicated of 🐛 Argument #1 ($value) must be of type Countable|array, null given in count() (line 57 of core/lib/Drupal/Core/Render/Element/Radios.php). Needs work .
It's actually supported out-of-box.
Steps:
1. Enable entities at /admin/config/search/path/settings
2. Then add patterns at /admin/config/search/path/patterns/add
Did access them using different approach, by extending some classes.
Then loading them via {% set civicrm_entity = content.contact_type['#object'] %}
Some code customization which I did:
https://www.drupal.org/project/civicrm_entity/issues/3382166#comment-152...
✨
Website URL not exposed
Active
Ok, did it in custom module by extending the existing classes (relevant parts below):
namespace Drupal\custom_civicrm;
class CustomCiviEntityStorage extends \Drupal\civicrm_entity\CiviEntityStorage {
private function getCiviCrmApi() {
if (!$this->civicrmApi) {
$this->civicrmApi = \Drupal::service('civicrm_entity.api');
}
return $this->civicrmApi;
}
// Copied from CiviEntityStorage.
function doLoadMultiple(array $ids = NULL) {
...
if (!empty($ids)) {
$options = [
'api.CustomValue.get' => [],
'api.Relationship.get' => [],
'api.website.get' => [],
'id' => ['IN' => $ids],
'options' => ['limit' => 0],
'return' => $field_names,
//'api.Contribution.get' => [],
//'api.GroupContact.get' => [],
//'api.Note.get' => [],
];
...
Then extended CivicrmEntity to support these custom fields on load:
namespace Drupal\custom_civicrm\Entity;
class CustomCivicrmEntity extends \Drupal\civicrm_entity\Entity\CivicrmEntity {
/**
* {@inheritdoc}
*/
function get($field_name) {
switch ($field_name) {
case 'api.CustomValue.get':
case 'api.Relationship.get':
case 'api.website.get':
return $this->values[$field_name];
default:
return parent::get($field_name);
}
}
}
Then registered these classes in hook_entity_type_alter:
function custom_civicrm_entity_type_alter(array &$entity_types) {
if (isset($entity_types['civicrm_contact'])) {
$entity_type_id = 'civicrm_contact';
$civicrm_entity_info = \Drupal\civicrm_entity\SupportedEntities::getInfo()[$entity_type_id];
$entity_types[$entity_type_id]->set('class', \Drupal\custom_civicrm\Entity\CustomCivicrmEntity::class);
$entity_types[$entity_type_id]->set('handlers', [
// ... here - same as original, exempt this one:
'storage' => \Drupal\custom_civicrm\CustomCiviEntityStorage::class,
// ...
if (isset($entity_types['civicrm_event'])) {
// Same can be used for civicrm_event.
}
}
Then in Twig template I could use:
{% set civicrm_entity = content.contact_type['#object'] %}
{% set website_url = civicrm_entity.get('api.website.get').values[0].url %}
{% set custom_value civicrm_entity.get('api.CustomValue.get').values %}
{% set relations = civicrm_entity.get('api.Relationship.get').values %}
This helped from https://www.drupal.org/project/drupal/issues/3258987#comment-14384134: 📌 Status report should warn about OPcache bug in PHP 8.1.0 to 8.1.5 Fixed
systemctl restart php8.1-fpm.service
drush crFYI: Had this error with the latest version 6.0.2 due to the old dependency found in the custom module, the namespace is now called Drupal\migrate_tools\Drush\MigrateToolsCommands.
Actually I've run "drush cr" and the error was gone. So it's probably fixed in #3315358 as mentioned.
I'm using 1.3.0-rc2 (which seems to be having the latest patch from #3315358) and I still have the same error. Happens on "drush status".
# composer exec -- drush -r web status
[warning] Undefined array key "config_overrides" MailerConfigOverride.php:93
[error] TypeError: array_merge(): Argument #2 must be of type array, null given in array_merge() (line 93 of /var/www/html/drupal/web/modules/contrib/symfony_mailer/src/Processor/MailerConfigOverride.php) #0 /var/www/html/drupal/web/modules/contrib/symfony_mailer/src/Processor/MailerConfigOverride.php(93): array_merge()
#1 /var/www/html/drupal/web/modules/contrib/symfony_mailer/src/Processor/MailerConfigOverride.php(52): Drupal\symfony_mailer\Processor\MailerConfigOverride->buildCache()
#2 /var/www/html/drupal/web/core/lib/Drupal/Core/Config/ConfigFactory.php(209): Drupal\symfony_mailer\Processor\MailerConfigOverride->loadOverrides()
#3 /var/www/html/drupal/web/core/lib/Drupal/Core/Config/ConfigFactory.php(169): Drupal\Core\Config\ConfigFactory->loadOverrides()
#4 /var/www/html/drupal/web/core/lib/Drupal/Core/Config/ConfigFactory.php(104): Drupal\Core\Config\ConfigFactory->doLoadMultiple()
#5 /var/www/html/drupal/web/core/lib/Drupal/Core/Config/ConfigFactory.php(89): Drupal\Core\Config\ConfigFactory->doGet()
#6 /var/www/html/drupal/web/core/lib/Drupal/Core/Extension/ThemeHandler.php(70): Drupal\Core\Config\ConfigFactory->get()
#7 /var/www/html/drupal/web/core/lib/Drupal/Core/Template/Loader/FilesystemLoader.php(46): Drupal\Core\Extension\ThemeHandler->listInfo()
...
> Unable to install modules bootstrap_barrio due to missing modules bootstrap _barrio
This happens when you're trying to enable module as a theme. To enable theme instead, use: drush theme:in bootstrap_barrio
As per #26 comment, "if (!$redisDatabaseIndex" won't work, as it's ignoring "0", change it to "!isset($redisDatabaseIndex)" instead.
Got similar issues.
Did some patch for 8.x, potentially fixing the issue. Needs some testing.
It's fixed for XLS, but not for CSV.
This patch generates the error in the newer version of Search API:
php Error Drupal\Component\Plugin\Exception\PluginException: Plugin (search_api_node) instance class "Drupal\search_api\Plugin\views\filter\SearchApiNode" does not exist. in Drupal\Component\Plugin\Factory\DefaultFactory::getPluginClass() (line 97 of web/core/lib/Drupal/Component/Plugin/Factory/DefaultFactory.php).
I think it needs to register its new class in search_api.services.yml
Patch works fine.
PR has been merged.
Looks like the PR has been merged and fixed in 6.2.4 (I think).
Tested #16 and it works fine straight away fixing broken e-mail (Invalid address: (Sender):).
Workaround for Drupal 8.x:
1. Add js/once.js into your theme from
https://www.drupal.org/project/once →
(https://git.drupalcode.org/project/once/-/blob/v1.0.1/src/once.js?ref_ty...).
2. Load it as dependency in your_theme.libraries.yml
global-components:
js:
js/custom.js: {}
js/once.js: {}
D8.x, for the reference:
1. Copy ./modules/contrib/htmlmail/templates/htmlmail.html.twig into themes/custom/YOURTHEME/templates/htmlmail--htmlmail.html.twig
2. drush twigc
3. drush cr
The last patch #18 needs review.
This seems to happen in webform_civicrm_admin.js and webform_civicrm_options.js. At the bottom of the script it's using })(Drupal, jQuery, once);
I've added:
admin:
dependencies:
- core/jquery
- core/once
to webform_civicrm.libraries.yml as suggested, but didn't seems to help.
Same issue on D8, I had to downgrade to 6.2.1.
Not fixed in 6.2.1 D8.x. However I've upgraded to 6.2.3 (D8.x), works fine.
I'm attaching a patch file.
Shouldn't the dependency be updated to not include D8.x for 4.1.x?
Currently 4.1.6 shows as supporting D8, but the code breaks.
$ composer show drupal/views_bulk_operations
name : drupal/views_bulk_operations
versions : * 4.1.6
...
requires
drupal/core ^8 || ^9
Ok, thanks, I'll try to upgrade.
I've found the fix in 3ef828ff10130eb52d9092a60e9790dd32bea349 (Dec 11 2021), unfortunately it was not ported to 8.x-5.x.
Still happening in 8.x-5.0-beta8, where it was fixed?
If you're using CiviCRM, this feature can be achieved using Webform CiviCRM module → . At /admin/structure/webform/manage/%/civicrm you can specify number if forms which can be submitted ('Create Fieldsets' in 'Additional Settings' tab). If you need to make it dynamic, use field conditions.
Looks great.
Drupal 6.x branch issue: #461700: Get rid of menu groups which are empty in Administer →
+1 for 6.x backport