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.
Will this module be ported to drupal 8 and is there any status on it?
Will this module be ported to drupal 8 and is there any status on it?
Comments
Comment #2
kevinquillen CreditAttribution: kevinquillen at Velir commentedGiven the volumes of information I am digesting on Drupal 8, I would need assistance in a port.
At a glance this looks like another case of config entities (additions on taxonomy terms) and then route altering to a view URL when that route is requested.. very basic overview.
Comment #3
DuaelFrI'd love to make that port as it'd be the best opportunity to entirely rewrite the module (and it needs that rewrite).
The thing is that I have no personal nor profesional contrib time remaining for now :/
@kevinquillen how could I help you?
Comment #4
kevinquillen CreditAttribution: kevinquillen at Velir commentedBasically where to start, haha. I am facing the same issue on Custom Publishing Options, just not really knowing where to begin.
What we know:
And yes, I am all for not porting any D7 code, because a large part of it was ported from D6 and not truly written for D7. Most of it wouldn't work anyway.
Comment #5
kevinquillen CreditAttribution: kevinquillen at Velir commentedI've started an 8.x branch to get this rolling.
Basically I am stuck on understanding if TVI settings are config entities or just arbitrary database data. It seems like there was a big push for config entities, so if that is the way it should be done, thats how I would like to do it.
Comment #6
DuaelFrAnswer: nothing is arbitrary database data anymore. It could be simple configuration or config entities. The second option seems better but we absolutely need to avoid creating these entities when they are not needed as it could overcharge websites having a lot of terms.
Keep in mind that overriding the route could be harder than we think because it's now handled by either the common routing system or Views (when it's enabled).
Comment #7
kevinquillen CreditAttribution: kevinquillen at Velir commentedHm. Okay, yeah, I forgot Views is doing that now. I was making those notes just from looking at the code.
Comment #8
kevinquillen CreditAttribution: kevinquillen at Velir commentedSo if it is Simple Configuration, how would that work in this context?
https://www.drupal.org/node/1809490
My understanding was you wouldn't really be creating tables to store config anymore because Drupal would now do it via Config, but I am not quite connecting the dots.
Comment #9
bloomt CreditAttribution: bloomt commentedI am a little bit curious why you recommend using taxonomy display in the development status? Is that module better suited for an upgrade to drupal 8?
Comment #10
DuaelFr@kevinquillen I'm not suggesting that we should use Simple Configuration except maybe for module-wide settings. Config entities are going to be perfect. Their tables are generated according to their base fields definition.
@bloomt TVI 7.x is not actively maintained, has some bugs and some performances issues. That's why it's suggested to use Taxonomy Display. With a complete rewrite for D8, things may change.
Comment #11
kevinquillen CreditAttribution: kevinquillen at Velir commentedI honestly didn't know that was even in the description. We will get that updated.
Comment #12
kevinquillen CreditAttribution: kevinquillen at Velir commentedComment #13
kevinquillen CreditAttribution: kevinquillen at Velir commentedIn alpha2, this much has been completed:
Overriding of the presentation and breadcrumb is the next thing to tackle.
Settings for terms and vocab are stored in config, as tvi.(term|vocab).(entity_id) which should make look up very easy.
Comment #14
kevinquillen CreditAttribution: kevinquillen at Velir commentedTaking a look at the taxonomy module, I can't see what is rendering taxonomy/term/{term} routes. I disabled the taxonomy view, yet the page persists even after a cache clear. Where is the callback handled for this? Whats the best course to taking control of what renders the content for this page?
Comment #15
DuaelFrDrupal magic ;)
Have a look at a route named something.canonical or at the Term entity annotation.
Comment #16
kevinquillen CreditAttribution: kevinquillen at Velir commentedYeah, that seems to call taxonomy_term.full, which looks like 'full view mode' for a term.
I guess what I am seeing is that the term page shows up whether or not the default term View is enabled. In order to handle a Page or Block display, what would be the point of injection when taxonomy_term/term/{term} is hit in the request URL?
Comment #17
DuaelFrI think you should alter the route definition to make it route to a custom controller.
As it's already what Views do, be sure to change the module weight during installation.
When the module is fully ported, I think the next step is to create a migration path from 6.x and 7.x to 8.x. Good luck ;)
Comment #18
kevinquillen CreditAttribution: kevinquillen at Velir commentedThe dev branch now has very rough functionality for using TVI on a term page.
I believe this is the proper route to take to do this. So far, I've been able to set a term view, display the default (if TVI not enabled) and create multiple views with the same path without conflict. The controller is handling the request for taxonomy/term/%. This is similar to how the D7 version is doing it with hook_menu_alter().
I didn't see a way to alter the module weight outright, so I gave the alter hook a higher weight than Views route subscriber alter - that seemed to do the trick.
It seems like a lot of functions can be removed or do not need re-implementing, like overriding the title, desc, breadcrumb, etc... as that seems to all come from Views now unlike D7.
Comment #19
DuaelFrTo alter module weight you just need to call module_set_weight() in your hook_install().
Nice job for all the rest :)
Comment #20
kevinquillen CreditAttribution: kevinquillen at Velir commentedHmm, yeah, I see now. Feels a bit dirty though, doesn't it? Plus, if modules are doing alterRoutes and setting precedent weight there, does module weight really factor in like it used to?
Comment #21
DuaelFrWeight is still used to order classic hooks but, as you only rely on an EventSubscriber, I suppose you don't need to alter the module's weight finally.
Comment #22
kevinquillen CreditAttribution: kevinquillen at Velir commentedI see. I've been following along with some videos.
One thing I can't figure out, and I don't know if this is the purview of TVI or not, is if you set a block to display on a term page - no View title or other overrides affect the page. I think that has been an issue in all versions though. Even though views is set to override, nothing happens.
Block displays do work, but so do Page displays. Page displays will show the title and or the override specified in the contextual argument. Is there a reason one was suggested over the other? Usage in a panel? I can't remember (I keep setups fairly pure), but it looks like a lot of work to go through and try and strongarm the page title out when using a block display.
Comment #23
kevinquillen CreditAttribution: kevinquillen at Velir commentedView access permissions work, the old TVI code for checking access is no longer necessary.
Comment #24
fomenkoandrey CreditAttribution: fomenkoandrey commentedplease tell me whether this module to work in Drupal 8.1?
Comment #25
kevinquillen CreditAttribution: kevinquillen at Velir commentedIt does work.
Comment #26
kevinquillen CreditAttribution: kevinquillen at Velir commentedMarking as fixed as we have a working Drupal 8 release in flight. New issues should be tracked in individual tickets.
Comment #27
kevinquillen CreditAttribution: kevinquillen at Velir commented