| Message ID | cover.1554329992.git.crobinso@redhat.com |
|---|---|
| Headers | show |
| Series | Remove website search, just use google | expand |
On Wed, 2019-04-03 at 18:26 -0400, Cole Robinson wrote: > Andrea's ChangeLog patches reminder me that I attempted something > similarish once, and also tried to drop our custom website search: > > http://www.redhat.com/archives/libvir-list/2016-May/msg01616.html Glad to be an inspiration for you! :) > danpb recommended I just make our search bar use google instead but > I never made the attempt. 3 years later here it is. > > Patch #1 makes the switch but doesn't remove anything > > Patch #2 drops index.py, the search indexer > > Patch #3 drops search.php and all the references to it. > libvirt.org/search.php is still a valid URL so this may break some > links, even though at the moment the page prints virtually nothing > except some boilerplate text. Maybe we can redirect it to the > homepage or something, ideas welcome I like the idea, and I like the diffstat even more O:-) I would, however, suggest a slightly different implementation than what you have here, where using the search bar would still send you to https://libvirt.org/search.php?query=X, and that page would contain three links: * "Search libvirt.org" https://google.com/search?q=site:libvirt.org+X * "Search the libvirt wiki" https://wiki.libvirt.org/index.php?search=X * "Search the libvir-list mailing list archives" https://google.com/search?q=site:redhat.com/archives/libvir-list+X The advantages of this approach are that existing links pointing to search.php will keep working, people will be able to search the mailing list archives as well (this is a feature the current search implementation is supposed to have) and search the wiki without having to go through an extra hoop, and finally that extending the search interface to include more sources would become as simple as adding another generated link to the page. What do you think? -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On 4/4/19 4:25 AM, Andrea Bolognani wrote: > On Wed, 2019-04-03 at 18:26 -0400, Cole Robinson wrote: >> Andrea's ChangeLog patches reminder me that I attempted something >> similarish once, and also tried to drop our custom website search: >> >> http://www.redhat.com/archives/libvir-list/2016-May/msg01616.html > > Glad to be an inspiration for you! :) > >> danpb recommended I just make our search bar use google instead but >> I never made the attempt. 3 years later here it is. >> >> Patch #1 makes the switch but doesn't remove anything >> >> Patch #2 drops index.py, the search indexer >> >> Patch #3 drops search.php and all the references to it. >> libvirt.org/search.php is still a valid URL so this may break some >> links, even though at the moment the page prints virtually nothing >> except some boilerplate text. Maybe we can redirect it to the >> homepage or something, ideas welcome > > I like the idea, and I like the diffstat even more O:-) > > I would, however, suggest a slightly different implementation than > what you have here, where using the search bar would still send you > to https://libvirt.org/search.php?query=X, and that page would > contain three links: > > * "Search libvirt.org" > https://google.com/search?q=site:libvirt.org+X > > * "Search the libvirt wiki" > https://wiki.libvirt.org/index.php?search=X > > * "Search the libvir-list mailing list archives" > https://google.com/search?q=site:redhat.com/archives/libvir-list+X > > The advantages of this approach are that existing links pointing to > search.php will keep working, people will be able to search the > mailing list archives as well (this is a feature the current search > implementation is supposed to have) and search the wiki without > having to go through an extra hoop, and finally that extending the > search interface to include more sources would become as simple as > adding another generated link to the page. > No objections from me but considering the embarassingly long time it took me to even get this solution working, I shouldn't be the one to implement it! Unless someone volunteers in the short term I think patch #1 and #2 can still go in, and search.php can be removed/replaced with the proper fix Thanks, Cole -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Thu, Apr 04, 2019 at 10:25:52AM +0200, Andrea Bolognani wrote: > On Wed, 2019-04-03 at 18:26 -0400, Cole Robinson wrote: > > Andrea's ChangeLog patches reminder me that I attempted something > > similarish once, and also tried to drop our custom website search: > > > > http://www.redhat.com/archives/libvir-list/2016-May/msg01616.html > > Glad to be an inspiration for you! :) > > > danpb recommended I just make our search bar use google instead but > > I never made the attempt. 3 years later here it is. > > > > Patch #1 makes the switch but doesn't remove anything > > > > Patch #2 drops index.py, the search indexer > > > > Patch #3 drops search.php and all the references to it. > > libvirt.org/search.php is still a valid URL so this may break some > > links, even though at the moment the page prints virtually nothing > > except some boilerplate text. Maybe we can redirect it to the > > homepage or something, ideas welcome > > I like the idea, and I like the diffstat even more O:-) > > I would, however, suggest a slightly different implementation than > what you have here, where using the search bar would still send you > to https://libvirt.org/search.php?query=X, and that page would > contain three links: > > * "Search libvirt.org" > https://google.com/search?q=site:libvirt.org+X > > * "Search the libvirt wiki" > https://wiki.libvirt.org/index.php?search=X > > * "Search the libvir-list mailing list archives" > https://google.com/search?q=site:redhat.com/archives/libvir-list+X > > The advantages of this approach are that existing links pointing to > search.php will keep working, people will be able to search the > mailing list archives as well (this is a feature the current search > implementation is supposed to have) and search the wiki without > having to go through an extra hoop, and finally that extending the > search interface to include more sources would become as simple as > adding another generated link to the page. > > What do you think? Sounds reasonable, though I don't think it should be a search.php page. It can be done with a plain search.html page and small amount of javascript. Avoiding php has the benefit that it works for locally installed docs from the RPM. I'm not fussed about broken links because search.php is long broken and so any bookmark to it is largely useless already. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Thu, 2019-04-04 at 15:29 +0100, Daniel P. Berrangé wrote: > On Thu, Apr 04, 2019 at 10:25:52AM +0200, Andrea Bolognani wrote: > > I would, however, suggest a slightly different implementation than > > what you have here, where using the search bar would still send you > > to https://libvirt.org/search.php?query=X, and that page would > > contain three links: > > > > * "Search libvirt.org" > > https://google.com/search?q=site:libvirt.org+X > > > > * "Search the libvirt wiki" > > https://wiki.libvirt.org/index.php?search=X > > > > * "Search the libvir-list mailing list archives" > > https://google.com/search?q=site:redhat.com/archives/libvir-list+X > > > > The advantages of this approach are that existing links pointing to > > search.php will keep working, people will be able to search the > > mailing list archives as well (this is a feature the current search > > implementation is supposed to have) and search the wiki without > > having to go through an extra hoop, and finally that extending the > > search interface to include more sources would become as simple as > > adding another generated link to the page. > > > > What do you think? > > Sounds reasonable, though I don't think it should be a search.php page. > It can be done with a plain search.html page and small amount of > javascript. > > Avoiding php has the benefit that it works for locally installed docs > from the RPM. I'm not a big fan of requiring JavaScript for websites, but on the other hand it looks like the search function is the only bit of PHP code we have in the repository so I'm okay with the idea of dropping it. That said, while I'd be perfectly comfortable implementing the idea above in PHP, I wouldn't quite know where to start for a JavaScript version. Dan, would you be willing to write that code yourself?
On Thu, Apr 04, 2019 at 04:46:25PM +0200, Andrea Bolognani wrote: > On Thu, 2019-04-04 at 15:29 +0100, Daniel P. Berrangé wrote: > > On Thu, Apr 04, 2019 at 10:25:52AM +0200, Andrea Bolognani wrote: > > > I would, however, suggest a slightly different implementation than > > > what you have here, where using the search bar would still send you > > > to https://libvirt.org/search.php?query=X, and that page would > > > contain three links: > > > > > > * "Search libvirt.org" > > > https://google.com/search?q=site:libvirt.org+X > > > > > > * "Search the libvirt wiki" > > > https://wiki.libvirt.org/index.php?search=X > > > > > > * "Search the libvir-list mailing list archives" > > > https://google.com/search?q=site:redhat.com/archives/libvir-list+X > > > > > > The advantages of this approach are that existing links pointing to > > > search.php will keep working, people will be able to search the > > > mailing list archives as well (this is a feature the current search > > > implementation is supposed to have) and search the wiki without > > > having to go through an extra hoop, and finally that extending the > > > search interface to include more sources would become as simple as > > > adding another generated link to the page. > > > > > > What do you think? > > > > Sounds reasonable, though I don't think it should be a search.php page. > > It can be done with a plain search.html page and small amount of > > javascript. > > > > Avoiding php has the benefit that it works for locally installed docs > > from the RPM. > > I'm not a big fan of requiring JavaScript for websites, but on the > other hand it looks like the search function is the only bit of PHP > code we have in the repository so I'm okay with the idea of dropping > it. > > That said, while I'd be perfectly comfortable implementing the idea > above in PHP, I wouldn't quite know where to start for a JavaScript > version. Dan, would you be willing to write that code yourself? Yes, I will have a go. Regards, Daniel
Andrea's ChangeLog patches reminder me that I attempted something similarish once, and also tried to drop our custom website search: http://www.redhat.com/archives/libvir-list/2016-May/msg01616.html danpb recommended I just make our search bar use google instead but I never made the attempt. 3 years later here it is. Patch #1 makes the switch but doesn't remove anything Patch #2 drops index.py, the search indexer Patch #3 drops search.php and all the references to it. libvirt.org/search.php is still a valid URL so this may break some links, even though at the moment the page prints virtually nothing except some boilerplate text. Maybe we can redirect it to the homepage or something, ideas welcome Cole Robinson (3): docs: Use google sitesearch for website search docs: Remove index.py docs: Remove search.php and all references .gitignore | 1 - docs/Makefile.am | 22 +- docs/devhelp/html.xsl | 4 - docs/index.py | 1266 --------------------------------------- docs/page.xsl | 9 +- docs/search.php.code.in | 225 ------- docs/search.php.in | 16 - 7 files changed, 6 insertions(+), 1537 deletions(-) delete mode 100755 docs/index.py delete mode 100644 docs/search.php.code.in delete mode 100644 docs/search.php.in -- 2.21.0 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list