An entity queue for each term?

Is that like the "Smartqueue" submodule in Nodequeue?

I think this could be implemented as a new class that implements EntityQueueHandlerInterface (or extends EntityQueueHandlerBase), which would create a Subqueue for every term in a vocabulary.

I've been meaning to write a blog post on writing a custom EntityQueueHandler, but the only other module I know of that does so far is Entityqueue Scheduler.

Moving this to a Feature request since I don't think a submodule like that exists yet.

We do something similar. You need to change some_module_get_all_markets to fetch the terms you want to create queues for + some other stuff...

/**
 * Implements hook_entityqueue_default_queues().
 */
function some_module_entityqueue_default_queues() {

  $markets = some_module_get_all_markets();
  $queues = array();

  foreach ($markets['some_module_provider'] as $market) {
    $term = taxonomy_term_load($market['tid']);
    foreach ($market['langs'] as $lang) {
      $machine_name = str_replace(' ', '_', strtolower($market['id'])) . '_' . $lang;
      $queue = new EntityQueue();
      $queue->disabled = FALSE;
      $queue->is_new = TRUE;
      $queue->api_version = 1;
      $queue->name = $machine_name;
      $queue->label = $market['id'] . ' (' . $lang . ')';
      $queue->language = $lang;
      $queue->handler = 'simple';
      $queue->target_type = 'node';
      $queue->settings = array(
        'target_bundles' => array(
          'article' => 'article',
        ),
        'min_size' => 23,
        'max_size' => 50,
        'act_as_queue' => 1,

      );
      $queues[$machine_name] = $queue;
      return $queues;
}

@jojonaloha how would you do something similar with EntityQueueHandlerInterface?

@muschpusch that's a good way of doing it for a custom module.

An EntityQueueHandler couldn't do it all on its own, but I was thinking one that had a Subqueue for every term in a given vocabulary.

I imagine that the EntityQueueHandler would add a setting on the Entityqueue configuration page (by implementing EntityQueueHandlerInterface::settingsForm) to select a vocabulary. It could create the subqueues initially (by implementing EntityQueueHandlerInterface::insert), but then would also need to implement hook_taxonomy_term_insert and hook_taxonomy_term_delete to create new subqueues as new terms are added and delete subqueues as terms are deleted. It would probably also need to implement EntityQueueHandlerInterface::getSubqueueLabel to display the term name as the subqueue label, EntityQueueHandlerInterface::canDeleteSubqueue to prevent deleting the subqueues directly, EntityQueueHandlerInterface::loadFromCode to ensure subqueues exist for the terms in the vocabulary when it is imported from a code export, and EntityQueueHandlerInterface::subqueueForm to remove the queue label field, since it should be the term name.

You can see the EntityQueueHandlerInterface for the methods I mentioned.

Related D8 issue - https://www.drupal.org/node/2722477

Attached is a patch that creates a rudimentary version of a Smartqueue-like feature. You will need to apply the patch in #2145631-1: settingsForm() in EntityQueueHandlerInterface is not used anywhere first, since this feature is dependent on that (and this issue is a test implementation of that change). It is all in a submodule I called smartqueue_entities (as opposed to Nodequeue's smartqueue_users).

I made it generic so it doesn't just work with Taxonomy terms. It allows you to create a new Entityqueue, select the "Smartqueue entities" handler, and then you can select the entity type and bundle(s) to use as your "source" for subqueues. If you wanted to use Taxonomy terms in a given bundle, then you would select Taxonomy terms for the "Subqueues entity type" and I enforced picking at least 1 bundle. It will automatically create, update, and delete the subqueues as entities are created, updated, or deleted from the "Source entity type" and bundle(s).

There are a couple things that the patch does not do yet, which I imagine will be desired in many circumstances.

Performance considerations

• It currently creates a subqueue when the queue is created for every existing entity. This could be too much for a single request if there are already a ton of entities in the source bundle already.
• It does not check or suggest that this handler only be used with a limited set of entities. I'm fairly certain the Subqueues list page does not use pagination, so there is a practical limit to the number of Subqueues that should exist, but there is no indication to the user of that during setup

Filtering/validating items in subqueue

Currently the autocomplete widget allows any entity to the subqueue; I think in most situations it would be desirable to limit what items can be in the subqueue based on the source entity of the subqueue itself. For example, if the source of the Subqueue is a Taxonomy term and the items added to the subqueues are nodes, it would likely be desirable to limit the nodes to the ones related to that taxonomy term.

I think that may be something we make configurable, as I can see the potential for use-cases where that is not always true. Also, in thinking about how to make that generic, I think it would have to know which field to use for filtering the relationship. For the common case, you would select the Taxonomy reference field attached to the node. I also think this would need to support both Entity reference and Taxonomy reference fields, as well as reverse relationships.

Prepopulating items in subqueue

I also can imagine when there is the validation for subqueues and that relationship, we could pre-populate the subqueues with the items in them, to make it easy for content managers to reorder the items instead of having to add them all first. New entities could be also be added to the subqueue as they are created.

I found a bug in the last patch. I also wanted to support creating a Views relationship between the source entity and the subqueue. The attached patch adds that. I also included a change to the Entityqueue Position sort handler to handle null values, which could be a separate issue but the common workaround wasn't working when testing out this new relationship, and this seemed like the best way to correct that.

Found another bug, reminded me of #2149129: Integrity constraint violation since I encountered this after starting with a fresh database and enabled this feature. It seems like the cause was that during the entity_get_controller('entityqueue_subqueue')->save(); at some point entityqueue_queue_load_multiple(); is called which triggers our loadFromCode(); callback again.

Attached patch resolves that issue.

When loading up the settings form for the smartqueue on /admin/structure/entityqueue/add I always see this at the top

<EM>BROKEN/MISSING HANDLER</EM> SETTINGS
The selected handler is broken.

EDIT: Never mind. I needed to rebuild the registry for the new class to be recognized.

I did some testing and found the following oddity:
If I forget to enable the smartqueue_entities module, the handler is still available to me in the UI, but gives errors when trying to configure "Subqueues entity type".
It seems to me that the handler should not be available unless the module is enabled.

An additional observation: when you DON'T use the smartqueue handler, you are still prompted for required fields.

Subqueues entity type field is required.
Bundles field is required.

Thanks for this new feature. Its extremely useful. I've found a bug for which I'm attaching a proposed fix. See attached interdiff.

When smartqueue entities are exported into a feature module and that module is enabled then there is a fatal SQL constraint error when a new (dependent) entity is added. Let me be more specific with an example: Lets us say we create a new subqueue called test_queue which depends on a vocabulary called "Category". We export this subqueue into a feature module and enable the module. If we add a term to Category we will see a fatal SQL error. Note that error does *not* occur if the feature module is disabled.

The error happens because hook_entity_insert tries to save the new subqueue for a second time. Actually the subqueue has already been created by SmartQueueEntitiesQueueHandler::loadFromCode() !

There are some other minor changes to the hook_entities_insert / update / delete.

Thanks for this module!
But, when I try to add a queue, I get a white screen and this error:

PHP Fatal error: Declaration of EntityQueueTaxonomyEntityQueueHandler::settingsForm() must be compatible with EntityQueueHandlerInterface::settingsForm(&$form_state) in [...]/EntityQueueTaxonomyEntityQueueHandler.class.php

Maybe I did something wrong. I applied patch #7 and interdiff #11
Any suggestion?

Attached is a patch that creates a rudimentary version of a Smartqueue-like feature. You will need to apply the patch in #2145631-1: settingsForm() in EntityQueueHandlerInterface is not used anywhere first, since this feature is dependent on that (and this issue is a test implementation of that change). It is all in a submodule I called smartqueue_entities (as opposed to Nodequeue's smartqueue_users).

Closing issues for the 7.x version, which is not supported anymore. Note that the 8.x version of Entityqueue does have a Smartqueue submodule, as mentioned in #4.