Broken vocabulary-related Views after D7 upgrade

[laryn]

Description of the bug

I'm noticing a broken View after an upgrade from D7. It seems that the handler for vocabulary names changed without a backwards compatible fix (I'm not sure if there are other handlers that are in the same boat). In this case, the D7 handler's classes are views_handler_filter_vocabulary_machine_name and views_handler_filter_vocabulary_vid but in Backdrop it is views_handler_filter_vocabulary. If you know about it, it's easy to re-add the filter in the view, which is now broken without warning, but is this something we can/should silently fix during the upgrade process, knowing it won't help previously upgraded sites but could make life easier for future upgraders?

@argiepiano:

D7's Views had two separate filter handlers for vocabularies: views_handler_filter_vocabulary_machine_name and views_handler_filter_vocabulary_vid. For the first one, views_handler_filter_vocabulary_machine_name, it should be easy to create an upgrade path to Backdrop, as B's vocabularies now use machine names, and the same views instance data can be used in both D7 and Backdrop. For the second handler ... a possible approach would be to include this views update as part of the taxonomy_update_1001(). This wouldn't work for existing upgraded sites, but it would for new upgrades... The deletion of the taxonomy_vocabulary table is part of taxonomy_update_1002()

Cross-reference to Zulip.

Steps To Reproduce

To reproduce the behavior:

1. Create a View in a D7 site that uses a Vocabulary Machine Name or Vocabulary VID filter.
2. Upgrade to Backdrop.
3. Load that View on the front end -- no vocabulary filter is in place.
4. Load that View on the administrative end -- no vocabulary filter and a notice about broken relationships.

Expected behavior

Ideally this would be invisible and successfully upgrade the View to Backdrop's equivalent filter. If that is not possible, at least a warning during the upgrade process would be better than nothing.

[indigoxela]

Lets see, in D7 views there's:

• views_handler_filter_vocabulary_machine_name
• views_handler_filter_vocabulary_vid
• views_handler_argument_vocabulary_machine_name
• views_handler_argument_vocabulary_vid

Conversion from db to config and from vid to name happens in taxonomy_update_1001() and the table and term table fields get dropped in taxonomy_update_1002(). So we should have an option to process existing views before the info's gone.

[laryn]

If it's not getting too far afield or too deep into edge cases, we also might display a warning message after converting the _vid handlers in certain cases (e.g. if the filter was exposed, the values for the filter will be different so URLs/bookmarks may not work with the same values in the query).

[argiepiano]

A quick note: during upgrade, the taxonomy update hooks are run before the views one. This means that any processing of existing views that make use of vocabulary handlers has to be done during or before taxonomy_update_1002(), when the tables containing the vocabularies (and their vids) are removed. This process can't be done during the views update hooks - it's too late by then, all vids are lost.

[indigoxela]

the taxonomy update hooks are run before the views one

Maybe. There aren't defined hook_update_dependencies() for that specific case, yet. Views db to config conversion happens in views_update_1001().