-
-
Notifications
You must be signed in to change notification settings - Fork 78
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
Badly rewritten URLs in case of "/" in the article title #726
Comments
I reopen the ticket as this is still not done properly. Same example with Wikivoyage |
Yea, this is some code I've tried not to touch so far - it's very complicated and old :( I'd like to refactor once we have good tests for it |
Just tried again and CSS is not loaded properly in Wikivoyage "EN Paris/2nd arrondissement" article |
Seems to work now... not sure what happend here. |
No, it's not, I have created a new ZIM file with git master head of wikinews FR, and here is what
If I looks the HTML, I see this kind of link in
|
@kelson42 I was able to reproduce this with master by doing a full fr.wikinews scrape, but now I'm unable to reproduce. |
I'm afraid this issue has recurred in Issue: Hyperlinks on the landing page of this wikimed ZIM are missing a The URL of the page is
As written, this hyperlink should lead to a page Links to assets on this page are correctly written:
|
@Jaifroid I confirm :((((( |
Thanks @ISNIT0. When you say "desktop scrapes", do you mean ZIMs with "desktop style" or something else? FWIW, this ZIM appears to have a mobile style. It has the "minerva" mobile style. |
@Jaifroid sorry, I was unclear - the main page is always scraped as a desktop version, so it gets treated differently to the individual articles |
Still not working fine and obviously not automated tested properly http://library.kiwix.org/wikivoyage_en_all_maxi_2019-10/A/Osaka%2FNorth (link comes from http://library.kiwix.org/wikivoyage_en_all_maxi_2019-10/A/Osaka/Kita) :( |
@kelson42 This looks like it is still an issue
|
@artiommocrenco Did you try the same with 1.14 dev? |
@Jaifroid for some reason |
Hmm, OK, yes it's not quite stable yet from what I understand. While I'm not a dev of mwOffliner, I initially thought the errors may have to do with requesting titles that require a URI-encoded forward-slash to access them on the wiki, but using a string without a URI-encoded slash. However, on your server I can't find https://neolurk.org/wiki/My_Little_Pony%2FConfound nor https://neolurk.org/wiki/My_Little_Pony/Confound . Do these URLs actually exist? |
Second URL works for me @Jaifroid |
Indeed it does! Apologies, I did actually test it earlier, but I must have made a typo or used wrong case when testing it in the URL field of my browser. |
The forward slash in the URL is causing problems in Kiwix JS (see kiwix/kiwix-js#494). I wonder if it might be causing problems for you too. For example, the article
Singapore
references its assets like this:Whereas the article
Singapore/Riverside
references its assets like this:Note the extra
../../
, because the browser thinks it's accessing an article Riverside in the subdirectory Singapore. This would all be fine, except that the hrefs in theSingapore/Riverside
article are written like this:Note that to access the hyperlink on this page from a browser, we would need to write that link as
<a href="../Singapore" ...>
.So there seems to be some inconsistency. Are we inside a subdirectory from the browser's perspective, or not? The subroutine that writes the location of the assets seems to think so, while the one that writes the location of the hyperlinks doesn't! Do you think this is an mwoffliner issue?
The text was updated successfully, but these errors were encountered: