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

Account created on 24 August 2015, about 9 years ago
#

Recent comments

πŸ‡ΊπŸ‡ΈUnited States steyep

I could not get the patch in #74 nor the diff from the MR to apply cleanly in 10.3. I've attached a re-rolled the patch for 10.3

πŸ‡ΊπŸ‡ΈUnited States steyep

Patch #24 rerolled for D10 compatibility

πŸ‡ΊπŸ‡ΈUnited States steyep

I've attached a patch that will suppress the "new term" input when the widget is not configured to allow for the creation of new terms

πŸ‡ΊπŸ‡ΈUnited States steyep

Patch attached

πŸ‡ΊπŸ‡ΈUnited States steyep

steyep β†’ created an issue.

πŸ‡ΊπŸ‡ΈUnited States steyep

I'm not sure that having a $special_types array is sufficient. It does allow for the builds to be triggered but the GatsbyEntityLogger still only marks a build as published if it has the isPublished method and that method returns true (https://git.drupalcode.org/project/gatsby/-/blob/2.0.x/src/GatsbyEntityL...). This can prevent the files from being available to Gatsby when builds are triggered.

I wonder if a more extensible approach might be to dispatch an event that allows other modules to determine if an entity is published. At the very least, I would suggest adding an isEntityPublished method to the GatsbyPreview service that is used instead of relying on a method that doesn't exist for all supported entities. Something like this:

/**
 * Determine if a given entity is considered "published".
 *
 * @param \Drupal\Core\Entity\EntityInterface $entity
 *   The entity to be tested.
 *
 * @return bool
 *   Returns TRUE if published; FALSE otherwise.
 */
public function isEntityPublished(EntityInterface $entity) {
  if ($entity->getEntityTypeId() === 'file' && $entity instanceof FileInterface) {
    return $entity->isPermanent();
  }
  if (is_callable([$entity, 'isPublished'])) {
    return call_user_func([$entity, 'isPublished']);
  }
  return FALSE;
}
πŸ‡ΊπŸ‡ΈUnited States steyep

I would be willing to co-maintain this module with galactus86 β†’ !

πŸ‡ΊπŸ‡ΈUnited States steyep

Confirming that this patch works with Drupal core 10.1. Marking this as RBTC

πŸ‡ΊπŸ‡ΈUnited States steyep

Re-rolled the patch to account for the proper field widget name

πŸ‡ΊπŸ‡ΈUnited States steyep

Based on the work done in #6 ✨ Exclude title not available as form display element on user defined nodes Needs review , I have made some slight modifications to support configuring the position of the Exclude Node Title on the Form Display UI.

Patch attached.

πŸ‡ΊπŸ‡ΈUnited States steyep

I had the issue when using Exclude Node Title with Inline Entity Form. The field was not displaying because of the module only supports NodeForm form objects.

I have attached a patch that adds support for Inline Entity Form and other form display modes. The patch adds a computed field and dynamically attaches that to the user-editable content types. The field handles the permission checks and a prepare_form hook is used to determine if the title should be suppressed for the node form. This is useful because it sidesteps the need to get the entity from the NodeForm object.

πŸ‡ΊπŸ‡ΈUnited States steyep

Using the needs_destruction tag is a good idea but I think that (and now that i'm thinking about it - the terminate event) occur too late in the lifecycle to invalidate the cache tag and write a message using the messenger service.

The deployFrontendEntityUpdateEnvironments will delete the state flag which should prevent multiple runs.

I've attached a revised patch

πŸ‡ΊπŸ‡ΈUnited States steyep

Modifies the patch to use KernelEvents::TERMINATE event so that the builds are triggered when using $entity->save();.

πŸ‡ΊπŸ‡ΈUnited States steyep

Attaching a patch of the proposed solution

πŸ‡ΊπŸ‡ΈUnited States steyep

Reviewed the patch and confirmed that it resolves the bug. It also resolves a bug that occurs as a result of the submit handlers being removed.

Production build 0.71.5 2024