Ckan: Removing pylons routes breaks extensions

[metaodi]

CKAN Version if known (or site URL)

2.8

Please describe the expected behaviour

The old named routes (e.g. 'home' or 'about') should be kept to improve the backwards compatibility of CKAN core. For extensions that want to support a range of CKAN versions this is important as they otherwise have to define these routes themselves, implement version-specific code or break one version.

Please describe the actual behaviour

The routes were removed frim master and therefore e.g. code that build the main navigation is doomed to fail in extensions. E.g https://github.com/ckan/ckanext-showcase/blob/92c9b2b7d4cc07b68eeb77587a832cb3c7607daa/ckanext/showcase/templates/header.html

What steps can be taken to reproduce the issue?

Try to build a navigation to the homepage or the about page on both CKAN 2.7 and the latest master branch.
I would propose to either keep the old named routes or provide a way the old name to the new route.

[amercader]

Named routes that followed the controller_action convention should be supported. For cases like about, search etc we can definitely provide an alias, mapping, etc

@smotornyuk @tino097 what do you think it's the best approach? Is it just a matter of defining a new URL rule with a custom endpoint? or do we need an actual mapping in h.url_for()?

[tino097]

as documentation states, when using blueprints, we should use blueprint name when defining the endpoint, so i think we should keep using 'home.about' and 'dataset.search' and see if we could provide an alias

[smotornyuk]

We discussed it last Tuesday, i just had no time to write comment:(
Yep, most of c_a routes are supported, unless there are no naming changes(which is a case for package controller - now it separated into dataset and resource controllers). But we have quite a bin of one-word routes, like home and about.

I suggest adding dictionary with mapping of route names, which will be checked at the beginning of url_for. This dict can be created even in helpers file and should contain old names of routes as keys and flask-styled names as values. And, sure, we need to raise either warning or log deprecation message, when we find out that this dict is successfully used.
I would suggest adding also function, that allows appending new keys into this dict(it potentially will be mutable global variable, what I don't like, but it's the fix for one|two minor releases, so i can go with it) or even some config directive, that can fill gaps in mapping(if we missed something, or there are some problems in extension itself)

[amercader]

We need this before 2.8 is released, as some of the breaking routes are already in it.

[amercader]

@tino097 can work on this this week

[amercader]

@metaodi this is now fixed on master and dev-v2.8 in case you want to test it against the extension that was not working