conventions for custom error pages

[Paraplegic Racehorse]

Are people creating their custom error pages (404, etc) with 'nikola new_page' or are you all mostly creating them by hand and dropping them in [base]/files/ ?

--

I'm Paraplegic Racehorse.
"Grand Curmudgeon" :: International Discordance of Kilted Apiarists, Local #994.
http://www.paraplegicracehorse.net/ (offline due to server issues, alas)

[Chris Warrick]

On 2 July 2016 at 20:09, Paraplegic Racehorse

You can do `nikola new_page`, but you will need to create a special
template for those, or at least change URL_TYPE to root-relative or
absolute URLs. Example:

https://github.com/Kwpolska/chriswarrick.com/blob/master/err/404.html
https://github.com/Kwpolska/chriswarrick.com/blob/master/themes/kw/templates/err.tmpl
https://chriswarrick.com/404

--
Chris Warrick <https://chriswarrick.com/>
PGP: 5EAAEA16

[Charles Reynolds]

So maybe I'm just being obtuse about this. I'm having similar difficulty with the projects plugin. So, if create a new template - or using a template from a plugin or custom theme - how does Nikola know to use it? Is it simply dependant on its raw location relative to the stories/ or pages/ root? The documentation is not clear on this.

I wonder if PRETTY_URLS could not prettify a post/page if the slug contains .html or something along those lines.

[Chris Warrick]

On 4 July 2016 at 20:10, Charles Reynolds

<paraplegic...@gmail.com> wrote:
> So maybe I'm just being obtuse about this. I'm having similar difficulty with the projects plugin. So, if create a new template - or using a template from a plugin or custom theme - how does Nikola know to use it? Is it simply dependant on its raw location relative to the stories/ or pages/ root? The documentation is not clear on this.

It depends on the location and your POSTS/PAGES settings. From conf.py:

# POSTS and PAGES contains (wildcard, destination, template) tuples.
#
# The wildcard is used to generate a list of reSt source files
# (whatever/thing.txt).
#
# That fragment could have an associated metadata file (whatever/thing.meta),
# and optionally translated files (example for Spanish, with code "es"):
# whatever/thing.es.txt and whatever/thing.es.meta
#
# This assumes you use the default TRANSLATIONS_PATTERN.
#
# From those files, a set of HTML fragment files will be generated:
# cache/whatever/thing.html (and maybe cache/whatever/thing.html.es)
#
# These files are combined with the template to produce rendered
# pages, which will be placed at
# output / TRANSLATIONS[lang] / destination / pagename.html
#
# where "pagename" is the "slug" specified in the metadata file.
#
# The difference between POSTS and PAGES is that POSTS are added
# to feeds and are considered part of a blog, while PAGES are
# just independent HTML pages.

This basically explains the way Nikola works for most contents. The
template is assigned by the last element of a POSTS/PAGES tuple. From
the projectpages documentation:

PAGES = [
…
("projects/*.rst", "projects", "project.tmpl"),
…
]

This takes all files that match the pattern "projects/*.rst" (0) and
render them in output/projects (1) using project.tmpl (2) as the
template.

Templates can be overridden on a per-page basis by using the ..
template: meta tag.

> I wonder if PRETTY_URLS could not prettify a post/page if the slug contains .html or something along those lines.

Apparently, this got left out of the docs (will be fixed in next
release) — you can use this meta tag:

.. pretty_url: False

[Paraplegic Racehorse]

On Mon, Jul 4, 2016 at 10:23 AM, Chris Warrick <kwpo...@gmail.com> wrote:

PAGES = [
…
("projects/*.rst", "projects", "project.tmpl"),
…
]

This takes all files that match the pattern "projects/*.rst" (0) and
render them in output/projects (1) using project.tmpl (2) as the
template.

Okay. Now that makes sense. Oof. While it's nice to have documentation in conf.py, that's not the first place I go looking. The Handbook is. Maybe I need to fork the website repo and see what I can do about that...

Anyway, earlier you said:

> You can do `nikola new_page`, but you will need to create a special 

> template for those, or at least change URL_TYPE to root-relative or 

> absolute URLs. Example:  

and I looked at your examples and still couldn't figure it out until I went back and saw 'URL_TYPE', so I looked at your conf.py on github and now it makes sense. BUT, if I set .. pretty_url: false in my 404 page created with new_page and set the slug to 404 I still don't get my 404 when I type in a page known not to exist. Is this expected behavior when URL_TYPE remains rel_path, rather than absolute? I guess what's really bugging me is how you're getting /output/err/[errorpage]/index.html to show up at the web root? I don't see it anywhere in the files or template or conf. Do you have a 301 redirect set up? Do 301 redirects even work with error pages?

[Chris Warrick]

On 5 July 2016 at 17:27, Paraplegic Racehorse

<paraplegic...@gmail.com> wrote:
>
>
> On Mon, Jul 4, 2016 at 10:23 AM, Chris Warrick <kwpo...@gmail.com> wrote:
>>
>>
>> PAGES = [
>> …
>> ("projects/*.rst", "projects", "project.tmpl"),
>> …
>> ]
>>
>> This takes all files that match the pattern "projects/*.rst" (0) and
>> render them in output/projects (1) using project.tmpl (2) as the
>> template.
>
>
> Okay. Now that makes sense. Oof. While it's nice to have documentation in
> conf.py, that's not the first place I go looking. The Handbook is. Maybe I
> need to fork the website repo and see what I can do about that...
>

The handbook lives in the main Nikola repo. It actually contains this
quote, but maybe we should have some description of how Nikola works
attached to that?

> Anyway, earlier you said:
>> You can do `nikola new_page`, but you will need to create a special
>> template for those, or at least change URL_TYPE to root-relative or
>> absolute URLs. Example:
>
> and I looked at your examples and still couldn't figure it out until I went
> back and saw 'URL_TYPE', so I looked at your conf.py on github and now it
> makes sense.

URL_TYPE = 'full_path' is necessary only if you want to access pages
and resources from your 404 page (which you usually do, unless you
inline CSS and images*)

Consider this directory tree:
|- logo.png
|- err
|- 404.html

With URL_TYPE = 'rel_path': (default)
<img src="../logo.png">

This will break if the URL will be further than one directory — that
is, /foo and /foo/bar will display it correctly, but /foo/bar/baz will
NOT display your logo. The <base> tag might actually fix it if enabled
— you could try leaving it that way…

With URL_TYPE = 'full_path':
<img src="/logo.png">
WITH URL_TYPE = 'absolute':
<img src="https://example.com/logo.png">

No issues with either.

> BUT, if I set .. pretty_url: false in my 404 page created with
> new_page and set the slug to 404 I still don't get my 404 when I type in a
> page known not to exist. Is this expected behavior when URL_TYPE remains
> rel_path, rather than absolute? I guess what's really bugging me is how
> you're getting /output/err/[errorpage]/index.html to show up at the web
> root? I don't see it anywhere in the files or template or conf. Do you have
> a 301 redirect set up? Do 301 redirects even work with error pages?

Nikola does NOT handle your error pages. This depends solely on your
web server. I’m using nginx and so this is my server config:

error_page 403 /err/403/index.html;
error_page 404 /err/404/index.html;
error_page 500 /err/500/index.html;
error_page 503 /err/503/index.html;

If you’re using Apache: https://httpd.apache.org/docs/2.4/custom-error.html
If you’re using GitHub Pages: make sure it becomes /404.html (no
pretty URL and middle thing in PAGES is an empty string) — cf.
https://help.github.com/articles/creating-a-custom-404-page-for-your-github-pages-site/
If you’re using some other web server/hosting provider: check the docs

* I actually have self-contained error pages (with the logo as base64
and CSS inlined), but I’m not a fan of relative paths.

[Paraplegic Racehorse]

On Tue, Jul 5, 2016 at 8:13 AM, Chris Warrick <kwpo...@gmail.com> wrote:

On 5 July 2016 at 17:27, Paraplegic Racehorse
<paraplegic...@gmail.com> wrote:
>
>
> While it's nice to have documentation in
> conf.py, that's not the first place I go looking. The Handbook is. Maybe I
> need to fork the website repo and see what I can do about that...
>

The handbook lives in the main Nikola repo. It actually contains this
quote, but maybe we should have some description of how Nikola works
attached to that?

That would be ideal. I actually didn't find any of this in the handbook; at least not in a way which was easily searchable via my browser's ctrl-f search.

 

Nikola does NOT handle your error pages.

I never suggested it did, but it's useful to see that reiterated.

 

This depends solely on your web server.

Ugh. Server configs. I was really hoping there was another way to handle it.

Thanks, Chris. This has all been tremendously helpful.

New topic, I suppose: Has anyone devised a clever way to:

nikola new_post --with-skel /path/to/skel.rst

which would allow us to keep a variety of skeletons for differing page/post types with metadata and content skeletons already in place (like meta from projects or book plugins). Being a Nautilus user, I can set these up in my ~/Templates folder and create new items from the context menu, but that's somehow less intuitive when I work with nikola from the command line. Alternatively, I suppose they could be set up as snippets in my text editor...

Nevermind.

[Chris Warrick]

On 5 July 2016 at 22:49, Paraplegic Racehorse

<paraplegic...@gmail.com> wrote:
> Ugh. Server configs. I was really hoping there was another way to handle it.

It’s just a couple lines, should be easy.

> Thanks, Chris. This has all been tremendously helpful.
>
> New topic, I suppose: Has anyone devised a clever way to:
> nikola new_post --with-skel /path/to/skel.rst
>
> which would allow us to keep a variety of skeletons for differing page/post
> types with metadata and content skeletons already in place (like meta from
> projects or book plugins). Being a Nautilus user, I can set these up in my
> ~/Templates folder and create new items from the context menu, but that's
> somehow less intuitive when I work with nikola from the command line.
> Alternatively, I suppose they could be set up as snippets in my text
> editor...
>
> Nevermind.

You could try nikola new_post -i, but you would need to remember to
remove the empty line it puts between default meta and the imported
file if you want to put meta information there. You could also use
`cp` and change title/slug/date by hand.