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.
The module is currently providing its own version of the views-view-table.tpl.php template and is implementing it via the hook_theme_registry_alter
function, further by overwriting the value of $theme_registry['views_view_table']['path']
. This practice however seems to prevent themes from overwriting and providing their own version of the template file in question.
Here is my suggestion to patch this behavior towards a workaround that will alter the path value only if otherwise the template file of the original Views module would be used:
/**
* Implements hook_theme_registry_alter().
*
* @TODO: Change for "template path" in hook_views_api() when
* http://drupal.org/node/1267482 if fixed.
*/
function views_megarow_theme_registry_alter(&$theme_registry) {
// We only alter the path if the original views template file is being used
// and thus leave it as-is if a theme has already altered it
$views_view_table_path = &$theme_registry['views_view_table']['path'];
if ($views_view_table_path == drupal_get_path('module', 'views') . '/theme' ) {
$views_view_table_path = drupal_get_path('module', 'views_megarow') . '/theme';
}
}
Comment | File | Size | Author |
---|---|---|---|
#5 | drop_the_module_table-2274651-5.patch | 3.87 KB | claudiu.cristea |
Comments
Comment #1
ArtusamakWhat if we were just looking for additionnal tpl suggestions?
Comment #2
claudiu.cristea@Artusamak, this is beaking all the tables (non megarow) views because I have overridden the template in theme. Suggestions? Suggestions is referring to file patterns, not locations. I'm tempted to accept @Bird-Kid solution.
Comment #3
claudiu.cristeaWell, the problem can be simplified by eliminating the module template. That template was needed only to inject HTML tag attributes into the row
<tr ...>
tag. And it was only one attribute needed there<tr data-entity-id="1234" ...>
. But I noticed that we are passing the same entity id also as class having the patternitem-1234
. So, I dropped the template and instead of reading the entity id from its dedicated attribute, I'm parsing the id from the class. I dropped also a redundancy making the markup less heavy.So, no more module template. Rely on Views or theme overridden template :)
Comment #4
claudiu.cristeaComment #5
claudiu.cristeaThere was a problem with that patch.
Comment #6
slashrsm CreditAttribution: slashrsm commentedPatch #5 fixes the problem for me and looks like a viable solution. I believe this is a bug since it breaks standard template overriding functionality.
Thank you all.
Comment #7
joelpittetOh much better! THanks @claudiu.cristea
Comment #8
ArtusamakIt works but you introduced the regression of loosing the data-entity-id attribute added to the DOM to let other modules easily manipulate a row.
The good news is that we can also do it in javascript so it's a transparent change.
Thanks for the patch and reviews.
Comment #9
ArtusamakComment #11
joelpittetThanks for fixing that @Artusamak
Comment #12
joelpittetOh but this changes looks like a bit of a minor performance regression:
because
var target = $(this);
is right above, super minor but avoid a function call and dom search (however fast it is for existing DOMElements)Comment #13
ArtusamakIndeed, thanks.