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

Versioning outdated banner and instant loading odd behaviour #3653

Closed
5 tasks done
ajstewart opened this issue Mar 1, 2022 · 7 comments
Closed
5 tasks done

Versioning outdated banner and instant loading odd behaviour #3653

ajstewart opened this issue Mar 1, 2022 · 7 comments
Labels
bug Issue reports a bug resolved Issue is resolved, yet unreleased if open

Comments

@ajstewart
Copy link

ajstewart commented Mar 1, 2022

Contribution guidelines

I've found a bug and checked that ...

  • ... the problem doesn't occur with the mkdocs or readthedocs themes
  • ... the problem persists when all overrides are removed, i.e. custom_dir, extra_javascript and extra_css
  • ... the documentation does not mention anything about my problem
  • ... there are no open or closed issues that are related to my problem

Description

I'm creating this issue after asking the previous question found here in the discussions section: #3617

On further digging, I've found that when using the combination of mike versioning, outdated banner override and instant loading, the suggested outdated banner url does not work as expected.

To be clear, the suggested outdated banner is that below which is stated in the docs on https://squidfunk.github.io/mkdocs-material/setup/setting-up-versioning/#version-warning

{% extends "base.html" %}

{% block outdated %}
  You're not viewing the latest version.
  <a href="{{ '../' ~ base_url }}"> 
    <strong>Click here to go to latest.</strong>
  </a>
{% endblock %}

This only happens when the initial load is performed on the homepage.

If you hard-refresh, or load in directly to a page, the banner link works throughout. It is only when the home page is the initial load.

I have created a simple example site (see reproducing section).

Expected behaviour

That when clicking the outdated banner the link should direct to the root address and therefore take you to the default latest version.

Actual behaviour

The current behaviour is that the outdated banner link is not resolving properly with instant loading when the homepage is the initial entry point. When visiting another page in the site after this entry point, the banner link will attempt to go to the wrong address and 404.

Steps to reproduce

I have created a simple dummy docs site hosted here: https://ajstewart.github.io/mkdocs-material-version-test/

Repository here: https://github.com/ajstewart/mkdocs-material-version-test

These were deployed with (both versions are the same):

mike deploy v1.0 --push
mike deploy v2.0 latest --push
mike set-default latest --push
  1. Navigate to the hosted site above.
  2. While on the homepage, switch to v1.0.
  3. Navigate to another page in the docs.
  4. Click the outdated banner.

Package versions

  • Python: 3.8.12
  • MkDocs: 1.2.3
  • Material: 8.2.3

Configuration

site_name: My Docs
site_url: https://ajstewart.github.io/mkdocs-material-version-test/
site_dir: site

theme:
  name: material
  features:
    - navigation.instant
    - navigation.tabs
    - navigation.sections
  custom_dir: overrides

extra:
  version:
    provider: mike

nav:
  - Home: index.md
  - Section A:
    - FOO: pages/foo.md
    - BAR: pages/bar.md
  - Section B:
    - NEW: pages/new.md


### System information

- Operating system: macOS 12.2.1
- Browser: Microsoft Edge 98.0.1108.51
@squidfunk squidfunk added the needs investigation Issue must be investigated by the maintainers label Mar 2, 2022
@squidfunk
Copy link
Owner

Thanks for reporting. Fixed in bcc2c18. Turns out the outdated version banner was not integrated with instant loading, an oversight when designing the outdated version banner in the first place. It should now work with and without instant loading.

Could I ask you to test-drive both scenarios? If it now reliably works with and without instant loading, I can issue a bugfix release straight away.

@squidfunk squidfunk added bug Issue reports a bug resolved Issue is resolved, yet unreleased if open and removed needs investigation Issue must be investigated by the maintainers labels Mar 2, 2022
@ajstewart
Copy link
Author

Thanks for reporting. Fixed in bcc2c18. Turns out the outdated version banner was not integrated with instant loading, an oversight when designing the outdated version banner in the first place. It should now work with and without instant loading.

Could I ask you to test-drive both scenarios? If it now reliably works with and without instant loading, I can issue a bugfix release straight away.

Thanks for looking into it so quickly! I will try this branch today and get back to you.

I did mean to add that everything was working with instant navigation turned off, but I will make sure to test both methods.

@ajstewart
Copy link
Author

@squidfunk I can confirm that bcc2c18 has fixed this particular problem with the outdated banner in both cases.

Though I decided to test the other issue I was having in my original discussion with the switching from a page that didn't exist in a previous version. I have deployed a version using that commit to here: https://ajstewart.github.io/mkdocs-material-version-test/.

To deploy v1.0 I removed the Section B from the nav and renamed the new.md to new_old.md so it couldn't be found.

On that deployed version, if you go to Section B "New" page on v2.0 and then use the switcher to go back to v1.0 it 404's as it's trying to go to that page when it shouldn't. Curiously I can't seem to replicate this behaviour with a local mike serve.

Should I create a separate issue for this?

@squidfunk
Copy link
Owner

Thanks for testing. Yes, please create a separate issue.

@ajstewart
Copy link
Author

Thanks for testing. Yes, please create a separate issue.

Just to say I created a clean deployment and now it seems ok. So I'll raise it if I meet it again on my actual docs website.

Thanks again.

@squidfunk
Copy link
Owner

Okay great. I've also double-checked the version navigation code and could see no apparent source of error, so the issue you were experiencing might be related to the latest fix.

@squidfunk
Copy link
Owner

Released as part of 8.2.4.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Issue reports a bug resolved Issue is resolved, yet unreleased if open
Projects
None yet
Development

No branches or pull requests

2 participants