🇬🇧United Kingdom @khaled.zaidan

That's possible.

My think is it would be nice if it's not specific to one entity type. I think this can apply to any entity type that there would be dependencies to an entity being trashed.

So rather than implementing hook_pre_trash_delete for a specific entity type, I was thinking that it's a separate thing (hook or plugin) that allows these dependencies to built, and then we trash those. Maybe that can be done in a hook_pre_trash_delete(), but I think it's safer to do it separately before that hook has been invoked, to ensure our trash chain is always handled first (this might be important if the a child entity being deleted needs information from its parent).

And maybe `trash_chain` isn't the best name xD I'm thinking maybe `trash_dependent_entities`?

Here's some suggested pseudo-code to the `TrashStorageTrait`:

$field_name = 'deleted';
$revisionable = $this->getEntityType()->isRevisionable();

foreach ($to_trash as $entity) {
  // Get all entity dependent entities.
  $dependent_entities = $this->invokeHook('trash_entity_dependencies', $entity);

  // First trash the dependencies. They might require an active parent to be successfully trashed.
  foreach ($dependent_entities as $dependent_entity) {
    $dependent_entity->delete();
  }

  // Allow code to run before soft-deleting.
  $this->invokeHook('pre_trash_delete', $entity);

  $entity->set($field_name, \Drupal::time()->getRequestTime());

And we would something similar for restoring (just the other opposite order: restore parent first and then the dependencies).

We might be interested in contributing time and effort to get this metadata bit added.

I'm thinking an additional serialised column `deleted_metadata`. It gets added/removed together with the `deleted` column.

And in there we store this `trash_chain` list of entities (entity type + id for each).

The trash chain could be hard-coded for now just to get these few entity types sorted and to see how well the approach works. We can later transition to using plugins (ideally) or just hooks.

Maybe we can also allow enabling these entity types as "Experimental" so there's a caveat that they might not work perfectly, yet.

What do you think @amateescu?

Joining this thread as we're also interested in trash for taxonomy terms.

I like the idea of the storing this additional metadata. Maybe part of the metadata we have a list of any additional entities trashed as a result of trashing this current entity. Let's call it `trash_chain` or something. We only add direct children in that chain. Any grandchildren would only appear in their direct parents, so handling this trash chain is a recursive bit.

This way, when we trash an entity (taxonomy term or anything else), any pre-trashed children simply wouldn't be added to the trash chain. And it would also work for any other entity type with hierarchy (e.g. menu items) or any dependency at all. At one point, this might become more flexible to allow custom dependencies.

Uploaded patch with the fix.

Adding the error message in the issue description.

khaled.zaidan → created an issue.

Patch is simple enough and fixes the issue (actually, tested it, too).

Third time is the charm!

Oops, faulty patch in #2.

Here's a fresh one.

Attached is a patch, against 2.x with the solution described above.

khaled.zaidan → created an issue.

khaled.zaidan → created an issue.

khaled.zaidan → created an issue.

khaled.zaidan → created an issue.

Hmm, that last patch in #7 seems to have the lines out of place.

Anyway, I've just written something more generic to actually load the info, rather than just skip. Patch attached.

The code could be simpler if only sort() is replaced with asort() in function template_preprocess_update_project_status() in core.

sort($project['includes']);
// Change to:
asort($project['includes']);

If i have the time later today I might create a patch for that.

Here's a modified patch that also links processes to their source if it's from another process.

Here's a patch with the fix proposed in the description.

Also before and after screenshots of a test migration.

khaled.zaidan → created an issue.

I would say the order should/could still matter, just without any migration being run multiple times.

This could be useful if we have a migration X that depends on several other migrations A, B and C. If we know that A and B take particularly long, then we might want to run influence the order and run C first.

There could be other reasons we'd want a migration to run before others aside from explicitly being a "dependency".

Attached is a patch to implement the pagination.

khaled.zaidan → created an issue.

It would be very helpful if someone could review this patch.

Here's a simple patch to do the alternative approach I mentioned. This might be enough on its own!

I'm thinking something along the lines of:
1. User manually sets a derivatives static directory in the files folder. E.g. staticDirs: ['../web/sites/default/files/storybook-derivatives']
2. When rendering the story (in storybook's route), we make the code check for any image derivatives.
3. Any image derivatives found, we first make ensure the derivative is generated and make a copy to the storybook derivatives dir.
4. Then modify the markup to the image derivatives point their paths to the new copies we've created
5. This could all be configured/enabled/disabled through the module configs, so it can accommodate different builds as needed.

Setting staticDirs to your web root still isn't ideal, as this means if you try to push storybook to Chromatic, it will attempt to push your entire website (which Chromatic won't allow).

I would be nice to have something to dynamically push image derivatives and/or change image paths before the render to story book. That way you can target the exact asset files you need.

I've only just run into this now, so I'm not sure what the best solution is or whether someone has already figured it out. I'll update here if I come across a better approach.

Here's a patch that does the proposed solution above.

khaled.zaidan → created an issue.

Here's a patch to make this functionality available.

It adds weights to profile types and makes them draggable, similar to vocabularies and taxonomy terms in core.

Patch for the suggested feature.

khaled.zaidan → created an issue.

I've found that there's no actual need for the conditional in the patch in #8?

We always want to retain the publish on date for the other translations. We also need the same logic for unpublishing.

However, we should add a check on whether the fields are translatable.

Here's a patch that makes those changes.

lussoluca → credited khaled.zaidan → .

Patch attached.

khaled.zaidan → created an issue.

Attaching a fresh patch that applies against 8.x-3.6.

And another patch for v2.3.x

Updated patch!

I'm realising that I forgot to update the config in the module. I'll amend that shortly.

Here's an initial patch of the feature suggested above.

Adds both options mentioned. If "Restrict transitions that can be scheduled" is ticked, then the user is able to select from all transitions for all entity-types/bundles which ones to allow.

khaled.zaidan → created an issue.

@mageshbcet1 and @gilmar.lima, is the label bit still an issue?

I was looking to get this patch over the line, but I just tested now and the latest (draft) label seems to get loaded correctly.

Could you please confirm whether it's still happening? If so, could you please provide some details how to replicate?

I've tried with the referenced entity being a regular node and a paragraph library item (regular paragraph fields don't have an editable label... do they?), in both cases, the draft title was used as label in the edit form.

Patch for the fix suggested.

khaled.zaidan → created an issue.

Worked for me.

Just found that the patch in #2 didn't handle empty values properly, as the service would convert them to an empty string rather than a NULL or an empty array.

Fixed now in the attached patch.

Attached is a patch to the proposed solution.

khaled.zaidan → created an issue.

Attaching patch for fix.

khaled.zaidan → created an issue.

Sorry, patch had a bunch of unrelated gibberish in it.

Re-uploading.

Not a complete implementation by any means, but a small patch to get things rolling maybe?

It adds a plugin for the Geopoint field type in Typesense. It works with the geofield module (at least just for indexing the data).

Attaching patch for propose fix.

khaled.zaidan → created an issue.

Attaching patch for suggested fix.

khaled.zaidan → created an issue.

Yeah, I just spotted this issue now, as well.

I think it's worth implementing hook_update_N() to remove the permission with the next release.

Code is simple (I just haven't yet gotten the hang of GitLab :( ).

/**
 * Remove the non-existent 'access pwa' permission from the anonymous user role.
 */
function pwa_update_8002() {
  user_role_revoke_permissions(RoleInterface::ANONYMOUS_ID, ['access pwa']);
}