Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Undocumented changes breaking error_document_template #4303

Closed
torfsen opened this issue Jun 25, 2018 · 6 comments

Comments

Projects
None yet
5 participants
@torfsen
Copy link
Contributor

commented Jun 25, 2018

It seems that #4225 changed how the HTTP error code is passed to error_document_template.html.

In CKAN 2.7.3, error_document_template.html says:

{% block subtitle %}{{ gettext('Error %(error_code)s', error_code=c.code[0]) }}{% endblock %}

In CKAN 2.8.0, however, the (BS2-) template says:

{% block subtitle %}{{ gettext('Error %(error_code)s', error_code=code[0]) }}{% endblock %}

Note c.code[0] vs. code[0].

Hence, custom variants of error_document_template.html need to be updated to work under CKAN 2.8.0. However, that change is not mentioned in the change log.

@amercader

This comment has been minimized.

Copy link
Member

commented Jun 25, 2018

You are right @torfsen, we should have kept the c.code version deprecated for a version before removing it. We are gradually removing stuff from c in favour of passing vars explicitly to templates, but we should keep the values in c for at least a version.

@tino097 can you set c.code in the Flask error handler (or g.code rather) but don't use it anywhere.

@wardi

This comment has been minimized.

Copy link
Contributor

commented Jun 25, 2018

I like @torfsen 's suggestion of adding the change to the changelog.

For this issue we could support old copied and modified templates as @amercader says, and try to remember to remove the dead code later. For general template changes I don't want to be held to the same deprecation process that we have for things like plugin interfaces. When we get around to reducing the template extends and snippet nesting we can't sensibly support every customized theme at the same time.

@amercader

This comment has been minimized.

Copy link
Member

commented Jun 25, 2018

@wardi Just to be clear, are you happy to keep support for all c.* vars for a version and remove them later or just this particular one on the error template? We've followed this approach so far for the admin, user and home controllers (merged) and for the group and package ones (almost merged) (example. My plan was to list all of the deprecated c vars in the changelog or dedicated docs page, we just missed the one mentioned on this issue. The fix in the extension templates is quite straight-forward (c.var -> var) but on templates like the package ones there is a ton of them.

So in general, leaving this particular var on the error template aside when dropping support for c vars do you want to:

  1. Keep them in c in master/2.9 + Announce on 2.9 Changelog + Drop them from c in 2.10
  2. Drop them from c in master/2.9 + Announce on 2.9 Changelog that they have been removed

I think 1 at least will give a bit more time to people to update their extensions, and tackle the unsolved issue of how to support different CKAN versions with the same templates. But maybe I'm being too conservative and given our release schedule we can go for 2.

(Some previous discussion on #3203 and more recently in #4062)

@wardi

This comment has been minimized.

Copy link
Contributor

commented Jun 25, 2018

Should have kept my mouth shut, I'm thinking about not tying our hands for larger unrelated template changes. @amercader's suggested fix is good for this issue, and I'm happy with either approach 1 or 2 above.

@torfsen

This comment has been minimized.

Copy link
Contributor Author

commented Jun 26, 2018

For what it's worth, as a user of and developer of custom templates I'm perfectly fine with having to update my templates when upgrading to a new CKAN minor version (as long as the changes are small, as in this case -- the switch to Bootstrap 3 is a bigger task, so the provision of the legacy BS2-templates is much appreciated). Hence, mentioning the change in the change log would have been enough for me.

@amercader

This comment has been minimized.

Copy link
Member

commented Jun 26, 2018

Should have kept my mouth shut

Please don't! Yours and @torfsen is really valuable feedback! We'll stick to 1 for now but we can revisit and go for 2 when we finish the migration of the controllers.

@tino097 tino097 referenced this issue Jul 18, 2018

Merged

[#4303] Update error handler #4349

0 of 5 tasks complete

amercader added a commit that referenced this issue Jul 19, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.