-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
Search index is broken #2708
Comments
The problem is the extra |
Guessing this might be fallout from the 1.5 upgrade, but not sure. |
This is from the Sphinx search (the RTD search results work fine: http://docs.readthedocs.io/en/latest/search.html?q=testing&check_keywords=yes&area=default#). Guessing we need to upgrade some of the search JS. |
I can look into this. Mostly certain it's the search override JS |
Also, for background here: our search overrides the default sphinx search. If our search returns no results, we back down to the sphinx search. What we're noticing here is that a missing search term from our index is a hit on the sphinx index, but something has changed with the sphinx implementation there. So, our indexes aren't broken, but something is wrong with the sphinx failover. |
Any resolution? Search links have been broken for 10 days |
Any chance of rolling back to a working version? Having a broken search feature is not really viable for the majority of docs users. |
Can you give an example of a broken link? This should only happen when Sphinx's default search is triggered, which is a minority of cases. |
You can change the version of sphinx your doc builds use using a requirements.txt file, if you need to roll back to an old version of sphinx. |
All of the links have the extra |
Here's another example: http://docs.godotengine.org/en/stable/search.html?q=kinematicbody2d&check_keywords=yes&area=default |
Another example from the pytest's docs: |
Tried to use the requirements.txt file to specify an earlier sphinx version as suggested but the build is failing: https://readthedocs.org/projects/eagleio/builds/5258802/ |
Not a developer, however I just wanted to mention that to get search working properly again I had to go back to Sphinx 1.4.9 then it worked successfully. Otherwise it just hangs with 'Searching...'. |
Fixed pytest's doc also by pinning to Sphinx 1.4, see pytest-dev/pytest#2352. Worth noting that I also configured the path to the |
We're now having this issue too: |
@gravis see my comment above yours for a possible workaround. |
@nicoddemus Thanks! |
… RTD Works around readthedocs/readthedocs.org#2708 and fixes #360. Patch from @nicoddemus.
… RTD Works around readthedocs/readthedocs.org#2708 and fixes #360. Patch from @nicoddemus. (cherry picked from commit 8f29f44)
Combine both into a single template for now. This isn't ideal, but the differences were minor. Future changes here might be to instead patch the file as we're copying, stealing it from Sphinx package distribution instead. We only need to remove `Search.init()` from the file, so perhaps this isn't horribly difficult. Fixes #25 Refs readthedocs/readthedocs.org#2708
This takes the underlying `searchtools.js_t` out of the Sphinx distribution path, patches it, and then fills the context and parses it as a templated javascript file. This allows us to remove the script initialization on all versions of this file. The initialization block on `searchtools.js_t` has not changed in 10 years, so this method should be safe. If the block changes in the future, tests will grab this as we add new versions of Sphinx to our testing. This reorganizes some repetitive code and cleans up a few other pieces as well: File copying is linked to the standard `copy_static_files` that is run from the builder. Running from an event on build finished was producing files without the template context. This is because `build-finished` is always triggered, but the static files are not always copied (and therefore did not have the same template context?) Fixes #25 Refs readthedocs/readthedocs.org#2708
This takes the underlying searchtools.js_t out of the Sphinx distribution path, patches it, and then fills the context and parses it as a templated javascript file. This allows us to remove the script initialization on all versions of this file. The initialization block on searchtools.js_t has not changed in 10 years, so this method should be safe. If the block changes in the future, tests will grab this as we add new versions of Sphinx to our testing. This reorganizes some repetitive code and cleans up a few other pieces as well: File copying is linked to the standard copy_static_files that is run from the builder. Running from an event on build finished was producing files without the template context. This is because build-finished is always triggered, but the static files are not always copied (and therefore did not have the same template context?) Fixes #25 Refs readthedocs/readthedocs.org#2708
Related to this bug in Sphinx 1.5: sphinx-doc/sphinx#3696 |
Is there any workaround other than downgrading sphinx to 1.4.x? I have a (private) project that's affected by this but also relies on the graphviz directive |
Has anyone else observed that (javascript) search results work fine in Sphinx 1.5 when built locally, but exhibit the bad path problem (foo.rst.html) only when built on readthedocs.org ? |
I have the same issue. I want to use Sphinx 1.5 but I want to get rid of this search broken link error (foo.rst.html). Can someone let me know if there is any other workaround other than downgrading Sphinx version. |
Still having same problem with docs failing to build via RTD when downgrading to Sphinx 1.4.x (builds fine locally). https://readthedocs.org/projects/eagleio/builds/5258802/ |
This will be resolved with a release of our extension, readthedocs/readthedocs-sphinx-ext#26 solves the issues here around Sphinx 1.5 using an incompatible version |
@agjohnson that's great news, thanks for working on this! 👍 |
So our extension is now released and Read the Docs uses the new release by default. To test these changes, you'll likely need to wipe the version from your project's versions page to ensure you get the new static files. I'll test against our docs (and the original bug report project) later, but if anyone else gets a chance to try this, feel free to report back |
works nicely for me, thank you! 👍 actually, correction -- it works when I search for a new two word string, but when I search for the phrase that I originally reported as causing me problems ("imaging data"), I still get the .rst.html links ... but if I search for "imaging archive", then I get clean links (and I did try a "wipe" and "rebuild" after I first noticed the recurring error and even after that, I still get the error when searching for "imaging data") -- although perhaps that is because of my browser cache? |
Almost works for me. Latest points to 1.8-branch, but does not appear to be working: And its latest build: These are good: I had to wipe and rebuild twice in some cases. |
...and without doing anything except allowing time to pass, latest now works, too. Thank you! |
Given we only cache build data for ~24h, projects should slowly start magically working. Poking various projects above, it looks like the search results are now correct. I'll close this for now, but feel free to reopen if this didn't help your project and you are now using Sphinx 1.5. |
Still broken for me after a wipe/rebuild: http://docs.ev3dev.org/projects/lego-linux-drivers/en/ev3dev-jessie/search.html?q=i2c&check_keywords=yes&area=default |
Expected Result
Do not get the 404 at latest step :)
Actual Result
... and I broke the internet 😀
The text was updated successfully, but these errors were encountered: