🇨🇭Switzerland @titouille

Here is the patch to resolve the problem with custom video media field.

I'm not very comfortable with git but I committed the change on the issue fork. I don't know if I must create a merge request or if a manager of this module can do it and merge to apply the changes.

It would be nice to implement that.

A first try to retrieve the field name :

        /** @var \Drupal\oembed_providers\Plugin\media\Source\OEmbed $source */
        $source = $media->getSource();
        $plugin_definition = $source->getPluginDefinition();
        $media_entity_type = \Drupal::entityTypeManager()->getStorage('media_type')->load($plugin_definition['id']);
        /** @var \Drupal\field\Entity\FieldConfig $a */
        $field_definition = $source->getSourceFieldDefinition($media_entity_type);
        $fieldname = $field_definition->getName();

Seems to do the work.
I will try to make at least a patch asap.

Here a patch to resolve the problem.

titouille → created an issue.

Little mistake on my code. booking_instance field of opening must be filled with new instance too...

/**
 * Implements hook_entity_update().
 */
function MYMODULE_entity_insert(EntityInterface $entity) {
  // Exit if the entity is not an opening instance.
  if (!$entity instanceof BookableCalendarOpeningInstance) {
    return;
  }
  /** @var \Drupal\bookable_calendar\Entity\BookableCalendarOpeningInstance $entity */
  $date = $entity->get('date')->getValue();
  $instance_date = $date[0];
  /** @var \Drupal\bookable_calendar\Entity\BookableCalendarOpening $opening */
  $opening = $entity->getParentOpening();

  $opening_dates = $opening->get('date')->getValue();
  $exists = FALSE;
  foreach ($opening_dates as $d) {
    if ($d['value'] == $instance_date['value'] && $d['end_value'] == $instance_date['end_value']) {
      $exists = TRUE;
      break;
    }
  }
  if (!$exists) {
    // Insert new date into opening.
    $opening_dates[] = [
      'value' => $instance_date['value'],
      'end_value' => $instance_date['end_value'],
      'duration' => $instance_date['duration'],
      'timezone' => $instance_date['timezone'],
      'rrule' => NULL,
      'rrule_index' => NULL,
    ];
    $opening->set('date', $opening_dates);

    // Set new booking instance in opening.
    $booking_instances = $opening->get('booking_instance')->getValue();
    if (!isset($booking_instances)) {
      $booking_instances = [];
    }
    $booking_instances[] = [
      'target_id' => $entity->id(),
    ];
    $opening->set('booking_instance', $booking_instances);

    // Save opening.
    $opening->save();
  }
}

My two cents, because simply running cron, either via UI or drush, can't work in some cases and fully block uninstall of the module...

Found here : https://drupal.stackexchange.com/questions/230156/how-can-you-completely...

run

drush php-eval 'field_purge_batch(1000);'

will resolve the problem in my case.

Hi josh,

Thank you for your answer. And yes, it's exactly the case. I must create opening instances with different prices / locations / additional informations, so it's not a way to store data in opening and use some sort of render to display it.

I saw another problem on the current implementation and the manual creation of instances. Because the opening doesn't store the date of the manually created instance, if I try to update the opening itself, it iterate over existing instances and delete the ones that doesn't has a date in opening, except if the instance has already some bookings.

So the problem is if some manually created instances has no booking, they will be deleted if the opening is updated...

I resolved the unidirectional problem with hook_entity_insert :

/**
 * Implements hook_entity_update().
 */
function MYMODULE_entity_insert(EntityInterface $entity) {
  // Exit if the entity is not an opening instance.
  if (!$entity instanceof BookableCalendarOpeningInstance) {
    return;
  }
  if ($entity->bundle() == "bookable_calendar_opening_inst") {
    // Get the current instance date.
    /** @var \Drupal\bookable_calendar\Entity\BookableCalendarOpeningInstance $entity */
    $date = $entity->get('date')->getValue();
    $instance_date = $date[0];

    // Get all dates in parent opening.
    /** @var \Drupal\bookable_calendar\Entity\BookableCalendarOpening $opening */
    $opening = $entity->getParentOpening();
    $opening_dates = $opening->get('date')->getValue();

    // Check if the instance date exists on opening. It can be the case if the instance is 
    // created on filling the opening itself with a new date.
    $exists = FALSE;
    foreach ($opening_dates as $d) {
      if ($d['value'] == $instance_date['value'] && $d['end_value'] == $instance_date['end_value']) {
        $exists = TRUE;
        break;
      }
    }
    if (!$exists) {
      // Insert new date into opening.
      $opening_dates[] = [
        'value' => $instance_date['value'],
        'end_value' => $instance_date['end_value'],
        'duration' => $instance_date['duration'],
        'timezone' => $instance_date['timezone'],
        'rrule' => NULL,
        'rrule_index' => NULL,
      ];

      $opening->set('date', $opening_dates);
      $opening->save();
    }
  }
}

I'm not sure for the following, but I must implement hook_entity_delete to clear cache of opening when an opening instance is deleted. I noticed that when I remove an opening instance from the opening instances list, the cache of the parent opening is not cleared. The date for the deleted instance remains in opening, and if I edit and save the opening, it recreate the deleted opening instance...

/**
 * Implements hook_entity_delete().
 */
function MYMODULE_entity_delete(EntityInterface $entity) {
  if (!$entity instanceof BookableCalendarOpeningInstance) {
    return;
  }
  /** @var \Drupal\bookable_calendar\Entity\BookableCalendarOpeningInstance $entity */
  /** @var \Drupal\bookable_calendar\Entity\BookableCalendarOpening $opening */
  $opening = $entity->getParentOpening();
  \Drupal::entityTypeManager()->getStorage('bookable_calendar_opening')->resetCache([$opening->id()]);
}

Maybe you can try yourself and make a correction on these problems.

Best regards.

titouille → created an issue.

titouille → created an issue.

Hi,

Not sure if the case is the same, but...

I have a custom entity module that build a "single page" system. This one is based on two entities : single_page and single_page_item.

The single_page entity is a basic entity to build single pages. The single_page_item entity is a system of items that are attached to the single page to create multiple contents.

single_page_item has a canonical path to show a list of items in a tab of the single_page entity instance. On this list, I have a "create new item" button as action link (in single_page.links.action.yml). The route to create a new single page item (in single_page.routing.yml) has as requirement :

_entity_create_access: 'single_page_item'

But when I display the single_page item list within a group, the button doesn't exists.

I implemented the getPermission and buildPermissions like this :

  /**
   * {@inheritdoc}
   */
  public function getPermission($operation, $target, $scope = 'any') {

    switch ($operation) {
      case "create single_page_item":
        return $this->getEntityCreateSinglePageItemPermission();
    }

    return $this->parent->getPermission($operation, $target, $scope);
  }
  /**
   * {@inheritdoc}
   */
  public function buildPermissions() {
    $permissions = $this->parent->buildPermissions();

    // Instead of checking whether this specific permission provider allows for
    // a permission to exist, we check the entire decorator chain. This avoids a
    // lot of copy-pasted code to turn off or rename a permission in a decorator
    // further down the chain.
    $provider_chain = $this->groupRelationTypeManager()->getPermissionProvider($this->pluginId);

    $prefix = 'Single Page Item:';
    if ($name = $provider_chain->getPermission('create single_page_item', 'entity')) {
      $permissions[$name] = $this->buildPermission("$prefix Create new entity");
    }
    return $permissions;
  }

  /**
   * Gets the name of the create single page item permission for the entity.
   *
   * @return string|false
   *   The permission name or FALSE if it does not apply.
   */
  protected function getEntityCreateSinglePageItemPermission() {
    if ($this->definesEntityPermissions) {
      return "create $this->pluginId single_page_item";
    }
    return FALSE;
  }

The permission appears on the list of permissions in the group, the tested user has the "administrator" role and the permission is checked for it, but when I navigate to the items list, the button is not displayed. I set up a breakpoint to see if the permission is checked but there is only calls for entity.view, entity.update and entity.delete. It seems the action links are not triggering the permissions checks...

Maybe anyone can point me what I'm doing wrong ?

Thanks in advance.

Hi !!

In the same way, it seems a "hook_themes_uninstalled" was added since 8.9.x in core. Is it possible to implement it on the hook_event_dispatcher module to allow acting on this particular hook ?

Thanks in advance.

Thanks @VasyOK for the tip, working perfectly.

Ok, so if anyone search a quick answer to this problem, I solved it like this.

Because I have a IDXFetcherResult extending FetcherResult, I can override the "cleanUp" method.

I have a IDXFileFetcher too, with fetch() method. I used this fetch method to pass to the IDXFetcherResult constructor the $feed and the "update_non_existent" state :

return new IDXFetcherResult(
  $path,
  $feed,
  $this->feedType->getProcessor()->getConfiguration('update_non_existent')
);

Now, on my IDXFetcherResult, I implemented the cleanUp method like this :

  public function cleanUp() {

    // Get file content as string.
    $content = file_get_contents($this->filePath);

    // Check if file is empty.
    // If it's the case, and only if it's the case, we must
    // clean ALL previously imported items.
    // We must add this process because the standard feeds system
    // doesn't clean items when it encount an empty list.
    if (empty(trim($content))) {

      $storage = \Drupal::entityTypeManager()
        ->getStorage('my-entity-type');

      // Get list of entities to clean.
      $ids = $storage
        ->getQuery()
        ->accessCheck(FALSE)
        ->condition('feeds_item.target_id', $this->feed->id())
        ->condition('feeds_item.hash', $this->updateNonExistent, '<>')
        ->execute();

      if (!empty($ids)) {
        /** @var \Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher $dispatcher */
        $dispatcher = \Drupal::service('event_dispatcher');

        $entities = $storage->loadMultiple($ids);

        // Iterate over each entity and mimic the clean process.
        // We use the same process to avoid potential errors.
        foreach ($entities as $entity) {

          $dispatcher->dispatch(new InitEvent($this->feed, 'clean'), FeedsEvents::INIT_IMPORT);
          $dispatcher->dispatch(new CleanEvent($this->feed, $entity), FeedsEvents::CLEAN);
        }
      }
    }
  }

Hope this can help.

titouille → created an issue.

Hi Jaypan !

This is unfortunately not the case. If you don't declare "uuid" => "uuid" in primary keys of your custom entity, the uuid column will be not added to the database "base_table" of your entity.
And if you declare it after deployment, Drupal add this column into the "data_table" instead of "base_table" if your entity declare data_table, and this break the use of uuid...

I finally found exactly what I need with this post that explain how to add uuid property / column to a deployed entity : https://drupal.stackexchange.com/questions/302719/how-can-i-add-a-proper...

Best regards.

same problem as megadesk3000 on #5. After upgrading to 1.3.0-beta1, I can't add new modules if symfony_mailer is enabled, it cause a Circular reference detected error :

PHP Fatal error: Uncaught Symfony\Component\DependencyInjection\Exception\ServiceCircularReferenceException: Circular reference detected for service "entity_type.manager", path: "user_last_access_subscriber -> entity_type.manager -> string_translation -> string_translator.locale.lookup -> config.factory -> plugin.manager.email_builder".

downgrading to 1.2.1 resolve the problem.

titouille → created an issue.