When a view has the same path as an entity's default view path shouldn't it then trigger hook_entity_view()? This would resolve problems with other modules, e.g. Metatag, and might be the more correct way of handling it.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

DamienMcKenna’s picture

Status: Active » Needs review
FileSize
789 bytes

This adds some code to views_page() to check if the current path matches the defined path for any entities, if so it loads that entity object and then runs module_invoke_all('entity_view') on it. Food for thought.

If this is the correct direction to take I'll be happy to roll a patch for D8, but I'd appreciate some input. Thanks.

dawehner’s picture

Status: Needs review » Needs work
+++ b/views.moduleundefined
@@ -523,6 +523,15 @@ function views_page($name, $display_id) {
+      if (isset($entity_type['path']) && ($path . $entity_name) == $entity_type['path']) {

For example the == condition looks not interesting. Isn't there a slash missing?

To be honest i really don't know why you actually want to override the entity view page with a view,
this is not recommended and should be better done by panels.

maximpodorov’s picture

@dawehner, the main goal is taxonomy term pages which are acceptable only when created by views (IMHO).

DamienMcKenna’s picture

Status: Needs work » Needs review
FileSize
930 bytes

I added an extra comment that better explains how the path matching magic works.

DamienMcKenna’s picture

@dawehner: As maximpodorov mentioned, using Views to replace the normal taxonomy term pages is a very common practice, deficiencies in how those are handled are what I'm trying to resolve with this patch.

dawehner’s picture

Just for the case of having the possibility to change the behavior it might make more sense to put this into the page display, so you can override and automatically win.

DamienMcKenna’s picture

FileSize
990 bytes

Per dawehner's suggestion I moved the logic into views_plugin_display_page->execute().

gabriel.achille’s picture

Thanks!
Work fine for me: I'm using Views to replace the default display of taxonomy term and the "non-triggering" of hook_entity_view() was preventing some context condition to be checked by the module context_entity_field
Step to reproduce:

  1. install context, context_entity_field, views
  2. define a taxonomy and add a field to it: field_type_example (field type "text list" for example: 1, 2)
  3. create a term, give value 1 for field_type_example
  4. enable the view "Taxonomy term"
  5. create a context, having a condition "EntityField": tick "Taxonomy term" and choose "field_type_example" for Field name, enter 1 for field value
  6. add some reaction (a specific block to display or ...) in the context and save it
  7. visit the term page: some reaction is NOT triggered.

with the patch: some reaction IS triggered.

Chris Matthews’s picture

Issue summary: View changes

The 6 year old patch in #7 to views_plugin_display_page.inc still applied cleanly to the latest views 7.x-3.x-dev and if still applicable needs to be reviewed.

Checking patch plugins/views_plugin_display_page.inc...
Hunk #1 succeeded at 246 (offset 22 lines).
Applied patch plugins/views_plugin_display_page.inc cleanly.