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

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?

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

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
-- 
|: 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