Drupal 8 Version of Entityqueue

Yes this is something I discussed with amateescu awhile back. Good to have an issue for it now though :)

I want try to migrate this module to D8, i will create a sandbox project and start to porting the most common and straightforward things to D8. And if all going well, continue working on it until leave a usable version of the project.

I will assign this issue to myself for now.

EDIT: The project: https://www.drupal.org/sandbox/gnuget/2291539

Just curious how this is going. We use nodequeue/entityqueue all the time and would love to see this ported for D8 when it comes out. We have a couple clients that want to live on the edge and go ahead and be one of the first to D8 and this module would be a majorly important component. Thanks for any update! If nothing else, I'll just try out the sandbox project at some point and see what we can do to help out if we get to that point soon.

I haven't had free time the last months and this has been stopped since then.

I still have in my plans continue working on this and I hope at least have a usable version when the first version of D8 be released it but this will be still on pause a couple weeks more.

If you want to check my work so far (which is not too much either) you can check it here:

https://github.com/gnuget/entityqueue-drupal8

I talked with amateescu a few weeks ago and the current plan is:

1. Fix remaining Major bugs
2. Release 7.x-1.0
3. Make the 8.x-1.x branch, all bugs and feature requests will then be fixed there first

Here's my thoughts on what we should aim to accomplish in the 8.x version of Entityqueue.

The main problem with the 7.x version is that it relies too much on the entity reference field and doesn't provide a nice/fluent API to work with a (sub)queue, like Nodequeue did. Also, if we just rely on the ER (entity reference) field provided by core, we'll have a huge performance problem on large queues (e.g. > 100 items), because accessing the ER field of the subqueue will cause all the referenced entities to be loaded, even if we just want to work with the first 10 items, for example.

In bullet points, this big picture would be something like this:

• we keep the current semantics for queues and subqueues: queues will be config entities that act as bundles for subqueues and subqueues willl be content entities
• we keep using an entity reference field for referencing entities from a subqueue, but with a twist: we define it as a computed field, which means we will provide a special item list class that extends Drupal\Core\Field\EntityReferenceFieldItemList and which will allow us to take over the loading of referenced entities (e.g. we can have a dedicated method on our custom list class that provides the "give me the first 10 items in the queue" functionality)
• we also need to write a pluggable a storage API, since the current field storage tables are not really the optimal solution for our use case. Sure, they work in the sense that we can abuse deltas for "position in the queue", but we should aim to have an extremely optimized storage, possibly even one per database driver (e.g. special storage classes for MySQL, PostgreSQL, MongoDB, etc.)
• we should aim to move the dragtable widget into Drupal core, maybe in 8.1, as a replacement for the 'entity_reference_autocomplete' widget (Drupal\Core\Field\Plugin\Field\FieldWidget\EntityReferenceAutocompleteWidget), which lacks *a lot* in usability compared to the nodequeue/entityqueue widget

Note that the second and third bullet points are based on a discussion with @yched, author of CKK and maintainer of Field API in core, and are mostly his ideas that I happen to fully agree with :)

Any reason to limit it to ER field - have you considered DER? Multiple entity-types in the one queue?

That would be a very simple change to make at any time and doesn't affect the "big picture" above, but yes, I agree that we should consider it after we have some initial prototype code written.

Just adding to @amateescu's notes from what I recollect from our discussion :

we can have a dedicated method on our custom list class that provides the "give me the first 10 items in the queue" functionality

Basically the idea was that you get queue items by manually loading "slices" of the (sub)queue in a runtime structure (a computed field) that you can then use with all the tools available for a regular ER field (loading of entities, rendering, formatters, widgets...). Something like (names made up) :

$subQueueContentEntity->populateSlice($length, $offset, $reversed = true/false)
$subQueueContentEntity->populateNextSlice() // maybe ?

The subqueue entity could probably come with a default slice pre-populated (e.g 10 items, offset 0, from the end), with default $length, $offset, $reversed params configured in the queue config entity.

Then you can use $subQueueContentEntity->items as a regular ER field item list : load entities, display with ER formatters, edit with ER widgets, add/remove entities and save data back to the queue table...

foreach ($subQueueContentEntity->items as $delta => $item) {
  // do stuff on $item->entity
}

I just downloaded entityqueue for our drupal 8 project. I have been playing with it, and find it provides a lot of features we need. Thanks for the great work!

Just wondering if there is a plan to make subqueue behave similar to the parent entityqueue? We are looking for some subqueue level features, including sorting/reordering subqueue list, displaying subqueue attributes like size, allowing setting min and max on size, and also allowing users to extend subqueue by adding fields as needed.

I can see how some of those features could be useful in the main module, but not all of them :)

- sorting/reordering subqueue list

This can easily accomplished on a per-project basis either with something like Draggable Views or, why not, a subqueue of subqueues :)

- displaying subqueue attributes like size

This would be a nice thing to provide by default. For your use case, is it needed as an entity field (it can be either a computed field or an "extra field" on the subqueue entity)? Or maybe just as a views field?

- allowing setting min and max on size

I think we can facilitate this by allowing queue handler plugins to act on subqueue entity events (e.g. onSubqueuePreSave(), etc.), because they can only act on queue events at the moment. This will allow a custom queue handler to enforce a min/max size on individual subqueues, but I'm not sure if such a handler would be very useful in the main module. Also, I can't really see how we could put this setting the UI, since subqueues do not have a "configuration" form, but we can definitely discuss this in a dedicated issue.

- allowing users to extend subqueue by adding fields as needed

This one is not really possible because it means that subqueues would be bundles themselves, but bundles of what exactly? :)

Just checked the module - it works fine!
Suppose #7 and #8 is a separate issue and this one could be closed.

PS: looks there's no way to filter/sort by subqueue in views

Hi amateescu, Thanks a lot for your great response. Among the features I mentioned, sorting subqueue list is very important for us. Looks like the list is currently sorted by their title in alphabet order, isn't it? As you suggested, It would be great if the subqueue list view is draggable or it allows to change order index for each subqueue.

Regarding subqueue's size, I think it would be nice to have it as an entity field (computed makes sense to me).

One observation: I tried to use inline_entity_form for the items field, and it works well, except that the Reverse and Shuffle buttons don't work without manually changing the order index.

As you suggested, It would be great if the subqueue list view is draggable or it allows to change order index for each subqueue.

What I suggested was that you could use Draggable Views and replace the current subqueue listing page with a view in your project, sorry if that wasn't clear enough :)

One observation: I tried to use inline_entity_form for the items field, and it works well, except that the Reverse and Shuffle buttons don't work without manually changing the order index.

Can you please open a separate issue for this? Sounds like something that should be easy to fix.

There is now an 8.x-1.0-alpha8 version available for Drupal 8. Can we close this ticket now, or wait until a full 8.0 version is out?

Let's wait until we have a beta at least :)

Entityqueue 8.x-1.0-rc1 is out, so we can close this issue :)