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

Template: nav.homepage.url on 404.html template not set #1131

Closed
squidfunk opened this Issue Jan 28, 2017 · 8 comments

Comments

Projects
None yet
2 participants
@squidfunk

squidfunk commented Jan 28, 2017

I have a 404.html defined in Material for MkDocs which does not include the nav.homepage.url in Jinja - it's just empty. On all other pages it correctly points to the home page. Is this correct? In my view this value should also be accessible from non-base templates.

Also reported in squidfunk/mkdocs-material#127

@squidfunk squidfunk changed the title from Template: nav.homepage.url on 404.html not set to Template: nav.homepage.url on 404.html template not set Jan 28, 2017

@waylan

This comment has been minimized.

Member

waylan commented Jan 29, 2017

I'm guessing this is related to the issues discussed in #77 (my comments on that issue explain how the system works and why it needs to work differently for error pages). The same relative/absolute problems would exist and pointing to the "homepage" in an error page template would be slightly different than with any other page. It may be that we don't have a reference to the "homepage" because it would be useless anyway. But I'll need to take a closer look to be sure.

@squidfunk

This comment has been minimized.

squidfunk commented Jan 29, 2017

Thanks for your first estimation. Maybe you can post a workaround, because it's really annoying that the 404 page doesn't really return to the homepage. Please keep in mind that it needs to be relative to the root, as some documentation is hosted in subdirectories (e.g. GitHub pages).

@waylan

This comment has been minimized.

Member

waylan commented Jan 29, 2017

I'm almost certain this is related to the fix for #77. I haven't tested, but if the homepage is at the server root (/), then we may have a bug which returns an empty string instead (see nav.py L100: abs_url.rstrip('/') would return an empty string if abs_url == '/'). Presumably when I added that I assumed abs_url would never equal '/', so we just need to test and confirm whether that is possible.

@waylan waylan added the Bug label Jan 30, 2017

@waylan waylan added this to the 1.0.0 milestone Jan 30, 2017

waylan added a commit to waylan/mkdocs that referenced this issue Jan 30, 2017

Ensure nav.homepage.url is not blank on error pages.
Also maintain pattern of ending urls with a slash in nav (all non-error pages
do so the error page shoudl also). A couple extra checks to ensure base_url
doesn't end in a slash though as it is expected that the string appended
to base_url will always begin with the slash.

Fixes mkdocs#1131
@waylan

This comment has been minimized.

Member

waylan commented Jan 30, 2017

Maybe you can post a workaround

You can hardcode the homepage URL in your template. Not ideal, but until the fix gets released, I'm not sure what else you can do. This is a bug that I overlooked when fixed #77.

Please keep in mind that it needs to be relative to the root, as some documentation is hosted in subdirectories

Actually, an error page can't have relative links for the reasons explained in #77, which is what makes this really tricky to get right. For a full explanation, please see #77.

@waylan waylan closed this in #1132 Jan 30, 2017

waylan added a commit that referenced this issue Jan 30, 2017

Ensure nav.homepage.url is not blank on error pages. (#1132)
Also maintain pattern of ending urls with a slash in nav (all non-error pages
do so the error page should also). A couple extra checks to ensure base_url
doesn't end in a slash though as it is expected that the string appended
to base_url will always begin with a slash.

Fixes #1131
@squidfunk

This comment has been minimized.

squidfunk commented Jan 30, 2017

Thanks for fixing this in master. Milestone is 1.0.0, so when is the release to be expected? Would be awesome if this would make it into a bugfix release, because the issue is pretty annoying.

Edit/note: just discovered the fact that an empty base_url also breaks the search in my (and probably every) theme, as it must load the search_index.json relative to base_url.

@waylan

This comment has been minimized.

Member

waylan commented Jan 30, 2017

@squidfunk we are in beta (thus version < 1.0) so every release thus far has been a feature release (with bugfixes). With the last release (0.16) we indicated that the next release we do will be 1.0. There is a lot of work we need to get done, so the timeframe is when the work is done. I suppose we could do a 0.16.1 release, but we've never done point releases before. I've always assumed we would wait until after 1.0 before moving to that model. Any thoughts @d0ugal?

just discovered the fact that an empty base_url also breaks the search in my (and probably every) theme, as it must load the search_index.json relative to base_url.

That's a valid concern. I'm going to reopen this issue to make sure we don't forget to fix this.

@waylan waylan reopened this Jan 30, 2017

@squidfunk

This comment has been minimized.

squidfunk commented Jan 30, 2017

I suppose we could do a 0.16.1 release, but we've never done point releases before.

There already is a 0.16.1 and also 0.15.x releases. You don't have to release it immediately, but a 0.16.2 bugfix release when a few more bugs where fixed would be awesome. The version semantics would be correct according to MAJOR.MINOR.PATCH, as it would be a bugfix release. However, just my point of view. Thanks for all the hard work.

@waylan

This comment has been minimized.

Member

waylan commented Oct 31, 2017

just discovered the fact that an empty base_url also breaks the search in my (and probably every) theme, as it must load the search_index.json relative to base_url.

I'm not seeing how this is a problem. For starters, it works fine in the included themes. As a reminder, base_url should never end in a slash as whatever gets appended to it should begin with one. For example: ".." + "/foo" = "../foo" (where base_url is ".."). Therefore, when at the root and base_url is "." (what base_url is set to on the homepage), we get "." + "/foo" = "./foo" which happens to equate to "/foo" (because the homepage is at the server root). On the error page, base_url is an empty string, so we get "" + "/foo" = "/foo". Yes, the dot is missing, but that's okay because we want an absolute URL on error pages for the previously referenced reasons.

Of course we don't use absolute URLs for everything because a MkDocs site may not be hosted at the server root. For example, the MkDocs root might be at http://example.com/foo/. But then the site_url should be set to http://example.com/foo/ deriving from that, the base_url will be /foo on an error page and . on the homepage. And using the same rules above, we always get the proper results when appending a path that starts with a slash.

As long as you always append a path to base_url which starts with a slash, there should be no problem. I'm not sure if this was fixed in a subsequent patch or it if worked this way when reported (I didn't dig through history), but there is no bug now, so I'm closing this.

@waylan waylan closed this Oct 31, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment