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';
  }
}
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Artusamak’s picture

Status: Active » Needs review

What if we were just looking for additionnal tpl suggestions?

claudiu.cristea’s picture

@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.

claudiu.cristea’s picture

Well, 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 pattern item-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 :)

claudiu.cristea’s picture

Title: Allow themes to overwrite views-view-table.tpl.php (& patch suggestion) » Drop the module table template
claudiu.cristea’s picture

FileSize
3.87 KB

There was a problem with that patch.

slashrsm’s picture

Version: 7.x-1.3 » 7.x-1.x-dev
Category: Feature request » Bug report
Status: Needs review » Reviewed & tested by the community

Patch #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.

joelpittet’s picture

Oh much better! THanks @claudiu.cristea

Artusamak’s picture

It 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.

Artusamak’s picture

Status: Reviewed & tested by the community » Fixed

joelpittet’s picture

Thanks for fixing that @Artusamak

joelpittet’s picture

Oh but this changes looks like a bit of a minor performance regression:

-    var classes  = target.parents('tr').attr('class');
+    var classes  = $(this).parents('tr').attr('class');

because var target = $(this); is right above, super minor but avoid a function call and dom search (however fast it is for existing DOMElements)

Artusamak’s picture

Indeed, thanks.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.