Proposal [from github]: Add Haystack support

[Divio Developers]

https://github.com/divio/django-cms/issues/labels/feature%20request#issue/431

[Jonas Obrist]

+1

[Tribaal]

The link 404's :)

But generally, yeah, I think adding Haystack support would be a
sensible thing to do.
So +1

On Thu, Feb 3, 2011 at 10:26 PM, Jonas Obrist <ojii...@gmail.com> wrote:
> +1

[benzkji]

+1

..don't like the google cse search results from the old website ;)

[Benjamin Wohlwend]

IMHO, there are two types of Haystack support that django CMS
currently lacks (the second one may be interpreted as a Haystack
issue).

The first ist indexing of pages. The gist that floats around on github
solves this problem pretty well[1].
The second part is indexing of models that are part of an apphook.
Currently, there are several problems with this:
* haystack indexing, like every other managment command, runs with
the locale 'en-us'[2]. This means that if a model's get_absolute_url
is not reversable over an apphook on an english page, you can't get
the object's URL during indexing. Trying to do so results in an
unhandlet NoReverseMatch.
* If haystack is able to get an URL for the object, it will be the
one from the english URL namespace. People using the search function
will find themselves more often on the english subsite than they'd
like.

The first problem could be solved by implementing a language fallback
in new_reverse, similar to the language fallback in the resolver
code[3]. That would be a nice thing anyway, without even taking
haystack into consideration (if we don't find a good replacement for
the new_reverse monkeypatching shenanigans in the first place).

The second problem is harder to solve. The only possibility that I see
is to store the URLs for all available languages in the index. We
could provide a SearchIndex class that does this automatically, so
that people can inherit from it. Also, a template tag that gets the
correct URL (depending on the current locale) from the SearchResult
instance and puts in into the context could be useful. Then you could
do something like this in your search.html (locale_url being the
imaginary template tag mentioned above):

{% for result in results %}
{% locale_url result as url %}
<a href="{% firstof url result.object.get_absolute_url %}">{{
result.title }}</a>
{% endfor %}

Whatya think?

[1]: https://gist.github.com/784195
[2]: http://code.djangoproject.com/browser/django/trunk/django/core/management/base.py#L208
[3]: https://github.com/divio/django-cms/blob/develop/cms/views.py#L39

[Benjamin Wohlwend]

Hi,

On Fri, Feb 4, 2011 at 4:54 PM, Benjamin Wohlwend <piqu...@gmail.com> wrote:
> IMHO, there are two types of Haystack support that django CMS
> currently lacks (the second one may be interpreted as a Haystack
> issue).
>

[...]

>  * haystack indexing, like every other managment command, runs with
> the locale 'en-us'[2]. This means that if a model's get_absolute_url
> is not reversable over an apphook on an english page, you can't get
> the object's URL during indexing. Trying to do so results in an
> unhandlet NoReverseMatch.
>  * If haystack is able to get an URL for the object, it will be the
> one from the english URL namespace. People using the search function
> will find themselves more often on the english subsite than they'd
> like.
>

This is a little hairier than I first thought. There's a little
problem with app loading. For reasons that are not quite clear to me
yet, haystack's autodiscovery of search indexes kicks in earlier than
django CMS's monkeypatch_reverse business, at least for the haystack
commands 'rebuild_index' and 'update_index' (putting 'cms' at the top
of INSTALLED_APPS doesn't help). The practical consequence of this is
that all the models used in any haystack index are evaluated before we
get a chance to monkeypatch `reverse` and reversal of apphooked models
fails at index build time.

I found only one way around this: explicitly calling
`monkeypatch_reverse` in the projects' `search_sites.py` *before*
`haystack.autodiscover()` is invoked. (which only works if/after [1]
is pulled in). Any better ideas?

Regards,
Benjamin

[1] https://github.com/divio/django-cms/pull/704/

[Benjamin Wohlwend]

Hi,
I implemented haystack support as outlined below und put the code on
github[1]. It won't make it into django CMS 2.2, though, for a couple
of reasons:

* as it is now, the code can live perfectly fine outside of core, it
doesn't need any changes in core
* the current lack of tests (this will change in the near future, I promise)
* I'm not really that happy with some of the code (e.g. manipulating
`globals`). Patches welcome :)

I'll put a package on pypi as soon as there is some test coverage
(hopefully this weekend).

Regards,
Benjamin

[1]: https://github.com/piquadrat/django-cms-search

On Fri, Feb 4, 2011 at 4:54 PM, Benjamin Wohlwend <piqu...@gmail.com> wrote:

[Jonas Obrist]

I agree that this should be outside the core. (Also besides the
mentioned lack of tests, equally worrying is the lack of docs)

Jonas

[Benjamin Wohlwend]

On Thu, Mar 31, 2011 at 5:40 PM, Jonas Obrist <Ojii...@gmail.com> wrote:
> equally worrying is the lack of docs

http://django-cms-search.rtfd.org

Happy now (at least with respect to docs)? :)

[Jonas Obrist]

Erm... 404?

[Benjamin Wohlwend]

Hi,

Not quite sure what's going on (the link's from
http://readthedocs.org/projects/django-cms-search/), but this one
works in any case:

http://django-cms-search.readthedocs.org/en/latest/

[Jonas Obrist]

Awesome!

Now all that's missing is http://ci.django-cms.org/job/django-cms-search/ :D