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

bring back search.php (Origin: bugzilla #599974) #3568

doxygen opened this Issue Jul 2, 2018 · 0 comments


None yet
1 participant

doxygen commented Jul 2, 2018

status RESOLVED severity normal in component general for ---
Reported in version 1.6.1 on platform Other
Assigned to: Dimitri van Heesch

On 2009-10-28 23:58:10 +0000, Danny Götte wrote:

While the new javascript search engine is a good thing, for smaller projects or projects without a webserver running php. It has some disadvantages in big projects, the js search is slow and unusable (yes I'm using a modern browser, FF3.5.4). There are also some guys who reject to even use javascript, they can't use it.
So there should be an alternative solution, it is hopefully not that much work to revive the search.php. You may make it optional through a parameter in the doxyfile.


On 2009-11-07 11:40:34 +0000, Dimitri van Heesch wrote:

Could you give me an indication about the size of the search results files?
i.e. a listing of sizes of html/search/all*.html would help me to get an idea.

There are also alternatives already to create searchable doxygen output:

  • Qt help: a platform independent indexer and browser
  • HTML Help workshop: compiled html help including a search index.
    Compiler is windows only, chm viewers are available for multiple platforms.
  • DocSets: for XCode integration on Mac OS X.
    Did you consider using any of these alternatives?

On 2009-11-08 12:11:31 +0000, Danny Götte wrote:

No I didn't considered one of these Alternatives, as it should be usable over web. Generating the complete documentation takes a lot of time.
Feel free to test the search for yourself:

Here is the list.
1135 Nov 7 05:07 all_30.html
2371 Nov 7 05:07 all_33.html
1129 Nov 7 05:07 all_34.html
1129 Nov 7 05:07 all_35.html
1426 Nov 7 05:07 all_38.html
2850 Nov 7 05:07 all_3a.html
5813856 Nov 7 05:07 all_5f.html
5104291 Nov 7 05:07 all_61.html
3461647 Nov 7 05:07 all_62.html
10263570 Nov 7 05:07 all_63.html
13399489 Nov 7 05:08 all_64.html
4100170 Nov 7 05:08 all_65.html
5926207 Nov 7 05:08 all_66.html
8332901 Nov 7 05:08 all_67.html
5062697 Nov 7 05:08 all_68.html
9873623 Nov 7 05:08 all_69.html
500658 Nov 7 05:08 all_6a.html
2312490 Nov 7 05:08 all_6b.html
5827746 Nov 7 05:08 all_6c.html
7133636 Nov 7 05:09 all_6d.html
5495998 Nov 7 05:09 all_6e.html
3464620 Nov 7 05:09 all_6f.html
9242606 Nov 7 05:09 all_70.html
453060 Nov 7 05:09 all_71.html
6641897 Nov 7 05:09 all_72.html
11899214 Nov 7 05:09 all_73.html
6797403 Nov 7 05:10 all_74.html
7698035 Nov 7 05:10 all_75.html
2822833 Nov 7 05:10 all_76.html
4556461 Nov 7 05:10 all_77.html
4385318 Nov 7 05:10 all_78.html
340551 Nov 7 05:10 all_79.html
333096 Nov 7 05:10 all_7a.html
323133 Nov 7 05:10 all_7e.html

On 2009-11-09 20:21:19 +0000, Dimitri van Heesch wrote:

Thanks for the info.

I agree that is quite slow (but not completely unworkable). It took about 5-30 seconds before the results appear.

I did notice a couple of problems with the way the search is embedded on your site:

  • the search results window appears right aligned with the search box, making
    most of the search results appear outside of the window!
    I suggest to try to copy the behaviour shown when you enable GENERATE_TREEVIEW.
  • on pages within a sub dir, the searchBox variable cannot be found, probably
    the search.js script is searched at the wrong location
    (i.e. the custom header does not use $relpath for the search script).

Meanwhile I'll see what it takes to reintroduce the old search engine.

On 2009-12-22 15:07:05 +0000, Dimitri van Heesch wrote:

I'll reinterduce the old search engine under the SERVER_BASED_SEARCH option in the next subversion update.

On 2009-12-23 13:17:56 +0000, Raja Kajiev wrote:

Will wait for it too!

JS-based solution has one more flaw: it does not perform string search inside item's name, it performs silly strings match check starting always from the first char of item name.

If you type "SSA" it will find "SSAData", but will not "Tm_SSAData".
IMHO such approach is close to useless. :(

On 2009-12-30 13:39:07 +0000, Dimitri van Heesch wrote:

This bug was previously marked ASSIGNED, which means it should be fixed in
doxygen version 1.6.2. Please verify if this is indeed the case and reopen the
bug if you think it is not fixed (include any additional information that you
think can be relevant).

@doxygen doxygen closed this Jul 2, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment