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

Prev/Next Links not appearing on Page.vue #1010

Closed
1 task done
eunjae-lee opened this issue Nov 16, 2018 · 2 comments
Closed
1 task done

Prev/Next Links not appearing on Page.vue #1010

eunjae-lee opened this issue Nov 16, 2018 · 2 comments
Labels
type: enhancement Request to enhance an existing feature

Comments

@eunjae-lee
Copy link

  • I confirm that this is a issue rather than a question.

Bug report

Version

Reproduced in the following versions:

  • 0.14.5
  • 1.0.0-alpha.18
  • 1.0.0-alpha.22

Steps to reproduce

  1. Clone this repo: https://github.com/eunjae-lee/vuepress-bug-reproduction
  2. npm run dev
  3. Visit http://localhost:8080/Second%20Document.html

What is expected?

On every page I should see Prev/Next Links (if exists)

What is actually happening?

On a page which contains white space in its filename, I don't see any Prev/Next Links at the bottom.

Other relevant information

  • Your OS: macOS 10.12.6
  • Node.js version: 8.11.1
  • Browser version: Google Chrome 70.0.3538.102
  • Is this a global or local install? local install
  • Which package manager did you use for the install? npm

Here's what I've found so far. It seems VuePress tries to match current page from sidebarItems and get corresponding prev/next pages.

screen shot 2018-11-16 at 7 24 41 pm

Here you can see the path of current $page is /Second%20Document.html. The whitespace is encoded there, which seems okay.

screen shot 2018-11-16 at 7 24 31 pm

Here you can see the path from sidebarItems and there the whitespace is not encoded. So VuePress cannot match current page.

@ulivz ulivz closed this as completed in e8d728f Nov 17, 2018
@ulivz
Copy link
Member

ulivz commented Nov 17, 2018

Thanks for the report, fixed it at e8d728f for 1.x.


BTW, contaning space in URL is unsafe, see: Uniform Resource Locators:

Unsafe:
Characters can be unsafe for a number of reasons. The space
character is unsafe because significant spaces may disappear and
insignificant spaces may be introduced when URLs are transcribed or
typeset or subjected to the treatment of word-processing programs.
The characters "<" and ">" are unsafe because they are used as the
delimiters around URLs in free text; the quote mark (""") is used to
delimit URLs in some systems. The character "#" is unsafe and should
always be encoded because it is used in World Wide Web and in other
systems to delimit a URL from a fragment/anchor identifier that might
follow it. The character "%" is unsafe because it is used for
encodings of other characters. Other characters are unsafe because
gateways and other transport agents are known to sometimes modify
such characters. These characters are "{", "}", "|", "", "^", "~",
"[", "]", and "`".

@ulivz ulivz added the type: enhancement Request to enhance an existing feature label Nov 17, 2018
@eunjae-lee
Copy link
Author

eunjae-lee commented Nov 18, 2018

@ulivz Thanks!
After filing this issue, I realised I didn't have to put whitespace in the filename but like this:

second-document.md

# Second Document

I confirmed that still behaved as I expected.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: enhancement Request to enhance an existing feature
Projects
None yet
Development

No branches or pull requests

2 participants