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

flexsearch ignores baseURL path leading to 404s #363

Closed
joernhees opened this issue Jul 12, 2021 · 4 comments · May be fixed by #505
Closed

flexsearch ignores baseURL path leading to 404s #363

joernhees opened this issue Jul 12, 2021 · 4 comments · May be fixed by #505

Comments

@joernhees
Copy link

joernhees commented Jul 12, 2021

Thanks for this nice theme, which we use to render some docs. In our case it ends up in some subdir of a larger page http://example.org/subdir/XYZ .

Today we noticed that search in our case works only until you actually click on one of the results... problem seems to be that the generated search result links don't include the path up to subdir (they point to http://example.org/XYZ ) leading to 404 errors.

So we started experimenting with baseURL (="" or ="http://example.org/subdir/"), relativeURLs and canonifyURLs. We actually tried all combinations, none worked. Some don't find the flexsearch json files it seems, but if they exists, opening them reveals that the links in there are absolute (but host local) links (so they just point to /XYZ), which works if you're served from the root dir and not a subdir.

maybe related #333

@joernhees
Copy link
Author

joernhees commented Jul 12, 2021

hmm, i think i tracked this down to

"href": "{{ $page.RelPermalink }}",

Weird thing is that as far as i understand from the hugo docs, this should already include baseURL if i set canonifyURLs, no?

Anyhow, after replacing this with $page.Permalink everything seems to work fine.
(I still have baseURL = "http://example.org/subdir/", realtiveURLs = false, canonifyURLs = true in our config.toml).

Not sure this is the best fix though, maybe it would be smarter to prefix the baseURL in js when showing the results?

@alex-shpak
Copy link
Owner

alex-shpak commented Jul 13, 2021

Hi!
Well, it should work as expected, I think we need to look at your configuration.

if you clone repo and run hugo on example site as

cd exampleSite
hugo serve --themesDir ... --bind=0.0.0.0 --baseURL=http://localhost:1313/example/xyz

At least ot works as expected for me.
Perhaps compare config with what is in exampleSite

@joernhees
Copy link
Author

hmm, i guess if you cannot reproduce then the problem is probably on our side somewhere...

closing this for now, fix is above if others should stumble over the same problem...

our config.toml at the moment looks like this:

baseURL = "http://example.org/subdir/XYZ"
relativeURLs = false
canonifyURLs = true
title = 'foobar'
theme = 'hugo-book-9'

@rluders
Copy link

rluders commented Dec 1, 2022

Well, sorry folks to "resurrect" this one.

I'm having the same issue. I do have a GitLab Page that is hosted on https://<user>.pages.domain.com/<repository>. In this same project I'm using the config (just the part that matters):

baseURL: https://user.pages.domain.com/docs
canonifyURLs: true

And I need/want to use canonifyURLs: true otherwise my images don't get loaded, since I'm using:

![My image][/images/my-image.png]

(Doesn't matter if I cant to images/my-image.png or make it relativeURLs: true... by doing that I do have the images being loaded, or the page assets don't get loaded, or the search doesn't work. One of the options will fail.

So, I was digging into the theme code, and I found and also came to this issue, and I found that @joernhees came to the same solution that I came up with... Just to replace the:

const searchDataURL = '{{ $searchData.RelPermalink }}';

With:

const searchDataURL = '{{ $searchData.Permalink }}';

Solves the issues for all cases (I mean, you are still now able to use:

relativeURLs: true
canonifyURLs: false

'Cause, it will break some theme assets loading, but all other combinations seem to work... So, I'm submitting a PR to change this line.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants