Add bulk restore and purge operations

Working on it.

I agree that having this feature would be super useful. I'd like to see it implemented in a very specific way if possible, by creating "on-demand" custom views for each trashable entity type. The reason for them being custom is that we need to display different fields than /admin/content for example.

Hey @amateescu,

I’ve attached a screenshot showcasing the functionality I’ve implemented so far. Please have a look and let me know your feedback.

I also need some clarification regarding the "on-demand custom view" you mentioned. Are you suggesting:

• Should each trashable entity type have its own predefined View, or should we generate Views dynamically based on the selected entity type?
• When you say "on-demand," do you mean the Views should be created programmatically when accessed, or should they be predefined and stored permanently?
• Are there specific fields you'd like displayed for different entity types, or should the View dynamically adjust based on available fields?
• Or did you have something else in mind?

Let me know your thoughts! Thanks.

Re #6:

Should each trashable entity type have its own predefined View, or should we generate Views dynamically based on the selected entity type?

Generate Views dynamically based on the selected entity type.

When you say "on-demand," do you mean the Views should be created programmatically when accessed, or should they be predefined and stored permanently?

Views should be created programmatically when accessed.

Are there specific fields you'd like displayed for different entity types, or should the View dynamically adjust based on available fields?

The View dynamically adjust based on available fields, using the list of fields we currently display in the trash controller.

As anish.ir has not worked on this issue for quite some time, unassigning the issue from him.

I don't understand the desire for on-demand views created for this. We already have a view for displaying all entities in the trash. Why can't we just add bulk operations to it?

We already have a view for displaying all entities in the trash.

We don't have a view, the listing pages at /admin/content/trash are generated "manually" in \Drupal\trash\Controller\TrashController::listing :)

Views should be created programmatically when accessed.

I think it should be easy enough to create a simple default view and a contextual filter for each entity type, with a reasonable default for each one (keeping the current fields: Title, Id, Bundle, Author, Status, Language, Deleted by, Deleted) - If the entity doesn't support the field, then it'll just be empty or "N/A".

Then if the site requires a specific behaviour, then they're free to add a new page display and override it for their content type as necessary, the automated generation of view display part is doable but might be a bit too adventurous and cause more headaches than necessary when the site builder could just manually customize it to their needs instead.

I think it should be easy enough to create a simple default view and a contextual filter for each entity type

Do you mean a view per entity type?

If so, that could potentially blow up the Views UI listing. See the screenshots from #3507244: UX issues in trash, when many entity types are trashable for an example of how many entity types could be trash-enabled.

If not, we have the age-old problem: what's the base table for a single view?

Started working on this.

This is pretty awesome, I didn't even know you could create and use a view executable on the fly like that!

I already had similar sandboxed code which dynamically created the view executable, but my approach was different, I'd plan to export and save it as a single generic "trash.listing" type view (but have custom views plugins that's able to dynamically change the base view as necessary based on the current views argument), then the idea being, site builders could create new displays on that view for their overrides as they deemed fit, but the default view would be capable of working with any trashed entity.

But I like this approach too. One thing that'd be nice in terms of flexibility is to add a hook that allows site builders to alter the generated view as they deem fit. That way, they may add or remove certain handlers on the view.

Also, a nice to have would be maybe a drush command to export the dynamically generated view for an entity, so that users may edit the views directly themselves if they're unable to use the API hook.

Just added a bit of potential suggestions and some code from my implementation. Feel free to shoot some of them down if you feel it doesn't mesh well with your goals.

I didn't want to make changes to the MR without getting your thoughts on it first.

Merged into 3.1.x and 3.x, thanks for helping out @codebymikey!

Pushed a followup commit for clearing views data when a new entity type is enabled for trash.

Another followup was needed to provide a fallback operations views field for entity types without a list builder.

Where exactly are these bulk restore/purge options? Fresh install of dev-3.x and I don't see this in the /admin/content/trash view.

Can you post a screenshot of that view? They're just regular views bulk operations.

@amateescu, weird - I uninstalled and reinstalled and the VBO operations are now there. All good!