Readthedocs.org: Search is not working

Created on 25 Jul 2015  ·  33Comments  ·  Source: readthedocs/readthedocs.org

hello,

If I try to search for something under my project http://fiware-orion.readthedocs.org nothing is found regardless the word I enter. Should I do anything to enable search for my project?

thanks

Bug more information

Most helpful comment

@fosskers I understand the workaround, but markdown is a supported feature: http://docs.readthedocs.io/en/latest/getting_started.html?highlight=markdown

Not being able to click search results containing any markdown documents seems like a serious bug. Any notion where the parser for md might be? The issue is actually quite simple: the results are incorrectly still containing the '.md' suffix in the URL. http://docs.readthedocs.io/en/latest/getting_started.html?highlight=markdown would be: http://docs.readthedocs.io/en/latest/getting_started.md.html?highlight=markdown if the document was originally in markdown. --Yet the file itself is simply the HTML page (above). If someone knew where I should start peeking at the code, perhaps I can fix it.

All 33 comments

I think the search should work out of the box. So it's not your fault :) We need to investigate this.

hello guys,

Any idea on how to fix this?

thanks!

2015-07-27 10:02 GMT+02:00 Gregor Müllegger [email protected]:

I think the search should work out of the box. So it's not your fault :)
We need to investigate this.


Reply to this email directly or view it on GitHub
https://github.com/rtfd/readthedocs.org/issues/1487#issuecomment-125116293
.

@ericholscher @agjohnson any ideas?

hello guys, @ericholscher @gregmuellegger @agjohnson

any idea or recommendation on how to solve the issue?

thanks!

Believe this is a bug with our mkdocs integration. It seems the json builder is breaking when using the theme option. We should have a patch for it soon.

Don't know if it's related but when I try to build an mkdocs site on my installation of rtd (commit f54d78b372845e9236377cbe38a9a401b84d34d7) I get:

[13/Aug/2015 13:20:04] DEBUG [readthedocs.search.utils:134] (Search Index) Parsing sections for /data/rtd/media/json/rtfd-tests/latest/tst/foo/index.json
[13/Aug/2015 13:20:04] ERROR [celery.worker.job:282] Task readthedocs.projects.tasks.update_search[0ab34218-5daf-4fd3-a4c7-d4b5c6bdefbf] raised unexpected: KeyError('url',)
Traceback (most recent call last):
  File "/srv/rtd_app/local/lib/python2.7/site-packages/celery/app/trace.py", line 240, in trace_task
    R = retval = fun(*args, **kwargs)
  File "/srv/rtd_app/local/lib/python2.7/site-packages/celery/app/trace.py", line 438, in __protected_call__
    return self.run(*args, **kwargs)
  File "/srv/rtd_app/checkouts/readthedocs.org/readthedocs/projects/tasks.py", line 595, in update_search
    page_list = process_mkdocs_json(version, build_dir=False)
  File "/srv/rtd_app/checkouts/readthedocs.org/readthedocs/search/utils.py", line 28, in process_mkdocs_json
    relative_path = parse_path_from_file(documentation_type='mkdocs', file_path=filename)
  File "/srv/rtd_app/checkouts/readthedocs.org/readthedocs/search/utils.py", line 62, in parse_path_from_file
    path = page_json['url']
KeyError: 'url'

Sample repo is here https://github.com/deejay1/rtfd_test

hello,

is there any news about this issue? or any way we can contribute to get it fixed?

thanks

I'm also waiting for this...

What's the current branch I could test and/or deploy from?

Any news about this? Got the same issue.

No news on this, we haven't focused on the mkdocs integration recently. Anyone willing to look into this is free to take this on.

Any updates recently? Search is extremely important for our doc.

Would love to see this fixed too

We are seeing this problem and the popup menu at the bottom left is missing when building mkdocs... perhaps related. If anyone is working on this perhaps we can assist? We do not know much about the code yet but learn quickly ;)

Possible workaround in #1088

Search is still not working :( http://solarium.readthedocs.io/en/latest/

Search "works", but it doesn't track changes in our latest branch. It always gives results with a URL structure we used a lot time ago.

See https://github.com/locationtech/geotrellis/issues/1967.

Note that search does work locally with mkdocs serve.

I'm surprised to discover how long this bug has been active. Has search on readthedocs.io truly been broken for over 18 months (and counting)? I am seeing the problem on https://projectile.readthedocs.io/.

What is preventing this from being resolved, and how can I help fix it?

The solution for us was to port all our docs to RST, the original markup that RTD supports. Luckily this was an easy process with pandoc.

Guys, I am still having this issue: http://voicebase.readthedocs.io/en/v2-beta/search.html?q=hello&check_keywords=yes&area=default Is there a solution other than converting all our documentation prior to using readthedocs?

@Daniel085 Using pandoc (linked above), the conversion process is at most an afternoon's worth of work.

@fosskers I understand the workaround, but markdown is a supported feature: http://docs.readthedocs.io/en/latest/getting_started.html?highlight=markdown

Not being able to click search results containing any markdown documents seems like a serious bug. Any notion where the parser for md might be? The issue is actually quite simple: the results are incorrectly still containing the '.md' suffix in the URL. http://docs.readthedocs.io/en/latest/getting_started.html?highlight=markdown would be: http://docs.readthedocs.io/en/latest/getting_started.md.html?highlight=markdown if the document was originally in markdown. --Yet the file itself is simply the HTML page (above). If someone knew where I should start peeking at the code, perhaps I can fix it.

Reading through the various links to other issues, so far as I can tell, this is what's going on:

  • Sphinx and mkdocs both support "client-side" searching, where and index of terms is generated at build-time, stored as JSON, and the search functionality is JS that runs inside the user's browser, downloads the JSON blob and renders the results.
  • mkdocs also supports rendering the generated index in a standard format that can be indexed server-side (at least, judging by #1088), which can be faster since the client doesn't have to download a whole index every time.
  • when RTFD builds docs in mkdocs format, it injects JavaScript that modifies the search field to submit requests to https://readthedocs.org/search/ instead of using the client-side searching.
  • Unfortunately, server-side searching doesn't seem to actually be set up or working in any way.
  • As a user of RTFD, you can work around this problem by injecting your own JavaScript that points the search field back to client-side searching.

I'm not sure why RTFD rewrites the search field for mkdocs documentation. After all, Sphinx-based documentation still uses client-side searching.

With the exception of actually hosting docs I'd say search is one of the most important aspects of a documentation site, so +100 for fixing this, but thanks so much for that workaround!

All projects listed here have a working search, is this still an issue for anyone?

This seems to be resolved fo us at least!

👍

Search is not working for https://climaf.readthedocs.io/en/latest/index.html
Do I need to hack as described above ?

@senesis It looks like you have a really old version of jQuery in your built docs. I believe this is causing the issue.

Yea, you're running your doc builds with Sphinx v1.2.3, which I'm guessing is the issue.

I'll also see if we can make our search code work with older jquery, which should hopefully fix it.

Looks like we broke our fallback in our latest search code. https://github.com/rtfd/readthedocs.org/pull/5285 will fix it.

Thanks ! I will also consider upgrading the Sphinx version I use

Was this page helpful?
0 / 5 - 0 ratings

Related issues

adamjstewart picture adamjstewart  ·  4Comments

cagataycali picture cagataycali  ·  4Comments

goerz picture goerz  ·  4Comments

davidism picture davidism  ·  4Comments

davidfischer picture davidfischer  ·  4Comments