Add "Export queue items" option

I think this is a nice little addition and I'm certainly in favor of it.

The patch will need a reroll because I merged the 7.x-1.x-ctools branch into 7.x-1.x, so it doesn't apply anymore :(

I was working on re-rolling this, but I'm a little unsure which is the best way to proceed. These are the things I've noticed/run into (I apologize in advance if this is incoherent, I'm still trying to process it myself):

• EntityQueue's are now exportable through ctools, the patch was based on the fact the EntityQueue's extended EntityAPIControllerExportable
• Now that we have EntitySubqueue's, I think that means we need to make EntitySubqueue's exportable before making items exportable.
• Now EntitySubqueue's are entities and the EntityQueue's are not, I started to make changes to make EntitySubqueueEntityController extend EntityAPIControllerExportable, but I have a few problems:
  • I add 'exportable' and 'admin ui' keys to hook_entity_info(), but the path contains an argument, which doesn't seem to be allowed in the Entity API module.
    

    function entityqueue_entity_info() {
      $return = array(
        'entityqueue_subqueue' => array(
          'label' => t('Subqueue'),
          'plural label' => t('Subqueues'),
          'entity class' => 'EntitySubqueue',
          'controller class' => 'EntitySubqueueEntityController',
          'module' => 'entityqueue',
          'base table' => 'entityqueue_subqueue',
          'load hook' => 'entityqueue_subqueue_load',
          'uri callback' => 'entityqueue_subqueue_uri',
          'label callback' => 'entityqueue_subqueue_label',
          'access callback' => 'entityqueue_access',
          'fieldable' => TRUE,
          'exportable' => TRUE,
          'admin ui' => array(
            'path' => 'admin/structure/entityqueue/list/%entityqueue_queue/subqueues', // <=== doesn't like %entityqueue_queue, links to edit, clone, export, etc contain "%25entityqueue_queue"
            'controller class' => 'EntitySubqueueUIController',
          ),
          'entity keys' => array(
            'id' => 'subqueue_id',
            'name' => 'name',
            'bundle' => 'queue',
            'label' => 'label',
          ),
          'bundles' => array(),
          'bundle keys' => array(
            'bundle' => 'name',
          ),
          'view modes' => array(
            'full' => array(
              'label' => t('queue'),
              'custom settings' => FALSE,
            ),
          ),
          'metadata controller class' => '',
        ),
      );

  • The above conflicts/overrides the ctools_export_ui implementation entityqueue_export_ui::subqueues_page().
• Should the EntitySubqueue's be exported with the exported EntityQueue or should they be exported separately?
• If items are exported they should be exported with the subqueue
• For simple single subqueue handlers, exporting the subqueue may not be possible/easy to find if they are exported separately, and without it there would be no way to export the items.

Right, so the patch was based on the "old" 7.x-1.x branch, where, due to the nature of our Entity API implementation, both queus and subqueues were exported together, without any good possibility to override this behavior. That's what the initial patch tried to achieve.

Now that queues are not entities anymore (conceptually, they're configuration, not content, and that was the whole point of rewriting things in the 7.x-1-x-ctools branch), we have queues exportable as standalone objects (as they should) but we don't have a built-in solution for subqueus. I would say that we don't even need one very much because people should use the standard D7 ways of exporting content: UUID, Deploy, Migrate, or whatever else is there.

In conclusion, I think this issue is actually "Closed (works as designed)" now :)

I agree that the subqueues and their items are content, so it would make sense to not re-invent the wheel and use one of those solutions.