Drupal 8

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

I'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?

Basically where to start, haha. I am facing the same issue on Custom Publishing Options, just not really knowing where to begin.

What we know:

• We need to store data for any vocabulary or taxonomy term (View, View Display, Override enabled)
• Overrides/views still need to respect any access permissions in place (this will probably 'just work' without doing anything).
• Provide module permissions for roles who can change TVI settings on vocabs/terms
• When a term is deleted, any TVI config for it should be deleted
• When a vocab is deleted, any TVI config for it or terms under it should also be deleted

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.

Configuration entities store information lists of things that users can create and delete; your code will continue to work fine whether there are 0 or 100+. Example: image styles, views, etc. Configuration entities also come with a complete set of CRUD hooks that are fired just like any other entity in Drupal making them an ideal candidate for configuration that may need to be manipulated or responded to by other modules.

I'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.

Answer: 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).

Hm. Okay, yeah, I forgot Views is doing that now. I was making those notes just from looking at the code.

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

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

I honestly didn't know that was even in the description. We will get that updated.

In alpha2, this much has been completed:

• We need to store data for any vocabulary or taxonomy term (View, View Display, Override enabled)
• Provide module permissions for roles who can change TVI settings on vocabs/terms
• When a term is deleted, any TVI config for it should be deleted
• When a vocab is deleted, any TVI config for it or terms under it should also be deleted

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.

Taking 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?

Drupal magic ;)
Have a look at a route named something.canonical or at the Term entity annotation.

Yeah, that seems to call taxonomy_term.full, which looks like 'full view mode' for a term.

entity.taxonomy_term.canonical:
  path: '/taxonomy/term/{taxonomy_term}'
  defaults:
    _entity_view: 'taxonomy_term.full'
    _title: 'Taxonomy term'
    _title_callback: '\Drupal\taxonomy\Controller\TaxonomyController::termTitle'
  requirements:
    _entity_access: 'taxonomy_term.view'
    taxonomy_term: \d+

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?

I 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 ;)

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

To alter module weight you just need to call module_set_weight() in your hook_install().
Nice job for all the rest :)

Hmm, 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?

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

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

View access permissions work, the old TVI code for checking access is no longer necessary.

please tell me whether this module to work in Drupal 8.1?

It does work.

Marking as fixed as we have a working Drupal 8 release in flight. New issues should be tracked in individual tickets.