issue_comments

It seems that heroku wasn't updating to 0.41 on deployment.

Had to add --branch 0.41 and that solved it! Heroku caches dependencies

and (i think) because the requirements.txt doesn't specify the datasette version, it didn't update from 0.40 to 0.41 on heroku even though it was specified on my local requirements file as datasette >= 0.41

These are the lines that gave me an idea on how to solve it: https://github.com/simonw/datasette/blob/182e5c8745c94576718315f7596ccc81e5e2417b/datasette/publish/heroku.py#L164-L186

Hi! I'm using datasette on this repository: https://github.com/chekos/RIPA-2018-datasette

and on my local machine i can see an /about page i created but when i deploy to heroku i get a 404 (http://ripa-2018-db.herokuapp.com)

I bumped datasette in my requirements file to 0.41 so I'm 100% what the issue is 🤔

Do you have any idea what could be the problem? 👀

EDIT: for context, I have a templates directory with a pages/about.html file in https://github.com/chekos/RIPA-2018-datasette/tree/master/datasette/templates

https://www.niche-museums.com/about now uses this mechanism. It used to be an empty about.db database but you can see from https://www.niche-museums.com/-/databases that it's now using the new mechanism.

Documentation: https://datasette.readthedocs.io/en/latest/custom_templates.html#custom-pages

Stretch goal: it would be neat if these pages could return custom HTTP headers (eg content-type) and maybe even status codes (eg for redirects) somehow.

I think I could do that with a custom template function - if that function is called during the render then we follow those instructions instead of returning the rendered HTML.

Idea: handle_404 can hand certain not found errors off to handle_500 so it can render them correctly;

https://github.com/simonw/datasette/blob/227bb3e91fe34811a9374150798643a5af98ed79/datasette/app.py#L748-L765

The trickiest part here is the 404 logic. It's spread out through a couple of places right now. It's in datasette.utils.asgi.AsgiRouter:

https://github.com/simonw/datasette/blob/227bb3e91fe34811a9374150798643a5af98ed79/datasette/utils/asgi.py#L98-L134

Then also in the `DatasetteRouter subclass of that:

https://github.com/simonw/datasette/blob/227bb3e91fe34811a9374150798643a5af98ed79/datasette/app.py#L736-L757

Stretch goal: it would be neat if these pages could return custom HTTP headers (eg content-type) and maybe even status codes (eg for redirects) somehow.

I think I could do that with a custom template function - if that function is called during the render then we follow those instructions instead of returning the rendered HTML.

Now that I've closed #577 this should be pretty easy to implement.

The implementation in https://github.com/simonw/datasette/commit/c5e8cd84d3ef55ed86771ac0bde0ca91d6b0e07a acts as a proof of concept. It has a big flaw though: it doesn't reuse the regular render() mechanism, which means it doesn't register custom template tags from plugins.

This is bad because it means that pages rendered in this way cannot take advantage of things like datasette-template-sql.

This means this issue is likely dependent on #577 - a documented mechanism to allow plugins to render templates.

Stretch goal: it would be neat if these pages could return custom HTTP headers (eg content-type) and maybe even status codes (eg for redirects) somehow.

Alternative idea: a new concept of "pages" which live inside templates/pages/ and where the file name minus the .html extension defines the URL.

templates/about/me.html would be served at /about/me - but only if no matching database and table were found.

This only takes effect on 404 errors from core Datasette.

Idea: do this with a simple template naming convention.

If you hit /about and there is no matching database, check for a template file called about-page.html. If it exists, render it. Otherwise return a 404 database not found.