This is a pre-production deployment of Warehouse, however changes made here WILL affect the production instance of PyPI.
Latest Version Dependencies status unknown Test status unknown Test coverage unknown
Project Description

In brief

A plug-and-play Django application for viewing, browsing and debugging data discovered in your Haystack Search Indexes.

Why I wrote it

I love Haystack but I’m sometimes not sure what data I have in it. When a query isn’t producing the result I’d expect, debugging it traditionally involves using the Python REPL to inspect the SearchQuerySet, and while I’m not allergic to doing that, it can be inconvenient, and doesn’t scale well when you need to make multiple changes.

This application, a minor abuse of the Django administration, aims to solve that by providing a familiar interface in which to query and browse the data, in a developer-friendly way.

What it does

Any staff user with the correct permission (currently, request.user.is_superuser must be True) has a new application available in the standard admin index.

There are two views, an overview for browsing and searching, and another for inspecting the data found for an individual object.

List view

The default landing page, the list view, shows the following fields:

  • model verbose name;
  • the Django app name, with a link to that admin page;
  • the Django model name, linking to the admin changelist for that model, if it has been registered via;
  • the database primary key for that object, linking to the admin change view for that specific object, if the app and model are both registered via;
  • The score for the current query, as returned by Haystack - when no query is given, the default score of 1.0 is used;
  • The primary content field for each result;
  • The first few words of that primary content field, or a relevant snippet with highlights, if searching by keywords.

It also allows you to perform searches against the index, optionally filtering by specific models or faceted fields. That’s functionality Haystack provides out of the box, so should be familiar.

If your Haystack configuration includes multiple connections, you can pick and choose which one to use on a per-query basis.

Stored data view

From the list view, clicking on View stored data for any result will bring up the stored data view, which is the most useful part of it.

  • Shows all stored fields defined in the SearchIndex, and their values;
  • Highlights which of the stored fields is the primary content field (usually, text);
  • Shows all additional fields;
  • Strips any HTML tags present in the raw data when displaying, with an option to display raw data on hover.
  • Shows any Haystack specific settings in the settings module.
  • Shows up to 5 similar objects, if the backend supports it.

The stored data view, like the list view, provides links to the relevant admin pages for the app/model/instance if appropriate.

Requirements and dependencies

django-haystackbrowser should hopefully run on:

  • Django 1.3.1 or higher;
  • Haystack 1.2 or higher (including 2.x!)

It additionally depends on django-classy-tags, though only to use the provided template tags, which are entirely optional.


It’s taken many years of my laziness to get around to it, but it is now possible to get the package from PyPI.

Using pip

The best way to grab the package is using pip to grab latest release from PyPI:

pip install django-haystackbrowser==0.6.1

The alternative is to use pip to install the master branch in git:

pip install git+

Any missing dependencies will be resolved by pip automatically.

If you want the last release (0.6.1), such as it is, you can do:

pip install git+

You can find all previous releases tagged on GitHub

Using git directly

If you’re not using pip, you can get the latest version:

git clone

and then make sure the haystackbrowser package is on your python path.


Once it’s on your Python path, add it to your settings module:


It’s assumed that both Haystack and the Django administration are already in your INSTALLED_APPS, but if they’re not, they need to be, so go ahead and add them:


With the requirements met and the installation complete, the only thing that’s left to do is sign in to the AdminSite, and verify the new Search results app works.

Extending admin changeforms

Assuming it works, you can augment your existing ModelAdmins by using (or copy-pasting from) the templates available:

  • admin/haystackbrowser/change_form_with_link.html adds a link (alongside the history and view on site links) to the corresponding stored data view for the current object.
  • admin/haystackbrowser/change_form_with_data.html displays all the stored data for the current object, on the same screen, beneath the standard ModelAdmin submit row.

Both templates play nicely with the standard admin pages, and both ensure they call their {% block %}’s super context.

Their simplest usage would be:

class MyModelAdmin(admin.ModelAdmin):
    change_form_template = 'admin/haystackbrowser/change_form_with_data.html'

Though if you’ve already changed your template, either via the aforementioned attribute or via admin template discovery, you can easily take the minor changes from these listed templates and adapt them for your own needs.


Both the provided templates check that the given context has change=True and access to the original object being edited, so nothing will appear on the add screens.


Please do!

The project is hosted on GitHub in the kezabelle/django-haystackbrowser repository. The main/stable branch is master.

Bug reports and feature requests can be filed on the repository’s issue tracker.

If something can be discussed in 140 character chunks, there’s also my Twitter account.


The following people have been of help, in some capacity.

  • Ben Hastings, for testing it under Django 1.4 and subsequently forcing me to stop it blowing up uncontrollably.
  • David Novakovic, for getting it to at least work under Grappelli, and fixing an omission in the setup script.
  • Francois Lebel, for various fixes.
  • Jussi Räsänen, for various fixes.
  • Vadim Markovtsev, for minor fix related to Django 1.8+.


  • Ensure the new faceting features work as intended (the test database I have doesn’t really cover enough, yet)

Known issues

  • Prior to Django 1.7, the links to the app admin may not actually work, because the linked app may not be mounted onto the AdminSite, but passing pretty much anything to the AdminSite app_list urlpattern will result in a valid URL. The other URLs should only ever work if they’re mounted, though. See ticket 21056 for the change.

The license

It’s FreeBSD. There’s a LICENSE file in the root of the repository, and any downloads.

Release History

Release History


This version

History Node

TODO: Figure out how to actually get changelog content.

Changelog content for this version goes here.

Donec et mollis dolor. Praesent et diam eget libero egestas mattis sit amet vitae augue. Nam tincidunt congue enim, ut porta lorem lacinia consectetur. Donec ut libero sed arcu vehicula ultricies a non tortor. Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Show More

Download Files

Download Files

TODO: Brief introduction on what you do with files - including link to relevant help section.

File Name & Checksum SHA256 Checksum Help Version File Type Upload Date
django_haystackbrowser-0.6.1-py2.py3-none-any.whl (37.3 kB) Copy SHA256 Checksum SHA256 py2.py3 Wheel Apr 25, 2016
django-haystackbrowser-0.6.1.tar.gz (38.1 kB) Copy SHA256 Checksum SHA256 Source Apr 25, 2016

Supported By

WebFaction WebFaction Technical Writing Elastic Elastic Search Pingdom Pingdom Monitoring Dyn Dyn DNS Sentry Sentry Error Logging CloudAMQP CloudAMQP RabbitMQ Heroku Heroku PaaS Kabu Creative Kabu Creative UX & Design Fastly Fastly CDN DigiCert DigiCert EV Certificate Rackspace Rackspace Cloud Servers DreamHost DreamHost Log Hosting