Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
Bulk form is being added with hook_views_data_alter when it's added to the table of the entity defining it, i.e.
/**
* Implements hook_views_data_alter().
*/
function node_views_data_alter(&$data) {
$data['node']['node_bulk_form'] = array(
'title' => t('Node operations bulk form'),
'help' => t('Add a form element that lets you run operations on multiple nodes.'),
'field' => array(
'id' => 'node_bulk_form',
),
);
}
Discussed a little for the comments integration in #1986606-157: Convert the comments administration screen to a view
This belongs to the corresponding EntityViewsData.
Proposed resolution
Remove the definition from hook_views_data_alter and move it to the EntityViewsData. Only node and user are affected by this.
API changes
Comment | File | Size | Author |
---|---|---|---|
#1 | 2400153-views_data.patch | 2.61 KB | pcambra |
Comments
Comment #1
pcambraComment #3
pcambraComment #4
jibranPerfect! thanks for the patch and issue.
Comment #5
dawehner+1
this is a bit problematic now ... given that views_views_data() might run afterwards. If we move it out of the alter hook, maybe the bulk form part of views_views_data() should move into an alter hook?
Comment #6
dawehner.
Comment #7
pcambraI was reviewing this and this is what views module does on behalf of any module that defines an entity and has actions associated with it (in views.views.inc):
Couldn't we just remove the particular node/user/* integrations then try to override that without adding much, honestly (in NodeViewsData.php):
Couldn't we just get rid of the particular implementations and leave just the generic view implementation, maybe with one change, adding the entity_type to the id of the field:
'id' => 'bulk_form',
would be'id' => $entity_type . '_bulk_form',
Comment #8
dawehnerNote: This is the used plugin ID, not some arbitrary ID.
We adapt the behaviour in those subsclasses a bit already.
Comment #9
pcambraOk, got it @dawehner, thanks.
Back to the original issue, tracing this comment, if I've understood it correctly:
It is actually
views_views_data
who invokes the *ViewsData.php plugins:So whatever we've got in views_view_data will come before the
$views_data->getViewsData()
call to the plugin.If you add a test with something
module_set_weight('node', 1000);
, the order of execution is respected, views will always run first, I honestly don't see any value on adding this to the patch, setting back to needs review.Comment #10
dawehnerTotal fair argumentation. Thank you!
Comment #11
alexpottNice clean up. Moving this out of the alter hook makes perfect sense and has no disruption.
Committed 3ae4f11 and pushed to 8.0.x. Thanks!