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.
Enabled vocabularies are displayed with the custom view page correctly, yet disabled vocabularies which should be displayed by the default views taxonomy term page override are completely ignoring views altogether and are being displayed by Drupal's core taxonomy term display.
This may be a duplicate of #1107972: TVI Doesn't overtake core taxonomy/term/% path.
Comment | File | Size | Author |
---|---|---|---|
#3 | tvi-default_view-1968086-3.patch | 745 bytes | Pierco |
#1 | tvi-default_view-1968086-1.patch | 1.39 KB | cwithout |
Comments
Comment #1
cwithout CreditAttribution: cwithout commentedI've tracked this down to tvi.module line 248 where it checks the status property before setting the $display variable. The default view never has a status set. As a result, in tvi_render_view() on lines 199-202, the variable $display is empty and the default view doesn't render.
The attached patch removes the conditional check on the configuration form that excludes the status box. Since the checkbox was purposefully excluded from that form, I assumed there was probably a reason for that, but I wasn't able to find one. In addition to fixing the issue with the default view never being found, this allows admins to decide whether or not there will be a default view or default to core functionality.
To test, after installing the patch, you'll need to resave your configuration settings at admin/config/user-interface/tvi with the "Use view override" option checked.
Comment #2
elpino CreditAttribution: elpino commentedOk, great, I'll test as soon as I can.
Comment #3
Pierco CreditAttribution: Pierco commentedMaybe the checkbox is not needed on the settings page so you can simply change the submission handler like I did in this patch.
Comment #4
cwithout CreditAttribution: cwithout commentedYes, you could just set the value without also adding an option for site admins to disable the default. But I can't see a reason why we wouldn't want admins to be able to disable the default. If someone only wanted to use the module on a certain vocabulary but use Drupal's taxonomy handling for all others, including the ability to disable this module's default would allow that. Forcing it to enabled forces an admin to use the module's taxonomy handling and override each case where they don't want to use it.
Comment #5
kevinquillen CreditAttribution: kevinquillen commentedCommitted to dev