Phpdocumentor: False routing search on index template, problem with relative paths in search links

[WebDevLan4You]

Expected behavior

Use Search, click on the link and move to correct page or section

Actual behavior

Using search on index page, clicking on a link generates a 404 not found
(problem with relative paths)

Steps to reproduce the problem

1.https://demo.phpdoc.org/3.0/default/

1. Use search on index page
2. click on a link in the search result

[sirbrillig]

Same here. All search results are 404 on https://phpcsutils.com/

Eg: search for "tab" and then click a result. You'll be directed to a page like this: https://phpcsutils.com/classes/PHPCSUtils-TestUtils-UtilityMethodTestCase.html#property_tabWidth which does not exist.

[jrfnl]

@jaapio I can confirm this issue. Just got reported to me as well for the PHPCSUtils website, though it seems to be context related.

What fails:

1. Go to Docs website homepage: https://phpcsutils.com/phpdoc/
2. Type in "tab" in the search box
3. Click on any of the results and see a 404.
   Example: https://phpcsutils.com/classes/PHPCSUtils-Utils-GetTokensAsString.html#method_tabReplaced

What works:

1. Go to a subpage of the Docs website: https://phpcsutils.com/phpdoc/namespaces/phpcsutils-backcompat.html
2. Type in "tab" in the search box
3. Click on any of the results and see the resulting page load correctly.

Done some more testing and looks like it's only when on the homepage that the search result links don't display resolve correctly, though no guarantees.

[mvriel]

It would seem that the generated URLs always assume you are in a subdirectory; while this is not the case on the homepage. Let's see why that is :)

[mvriel]

The problem is that the URLs for the search are generated on compile time; but URLs should be relative to the current folder. Because the search index is generated into a subfolder; the URLs will always assume they are 1 nesting level deep.

I am now doing an experiment with using the <base> tag and changing the way we render URLs as this is a common problem and I hope that by using the <base> tag I can prevent future issues in other parts of the codebase too

[mvriel]

A fix is ready in the attached PR; when the build is green I can merge it

[jrfnl]

Sparkly! :sparkles: