scholarslab / solrsearch Goto Github PK

diff --git a/.gitignore b/.gitignore
index 547bf86..488c6b1 100644
--- a/.gitignore
+++ b/.gitignore
@@ -3,3 +3,7 @@ Gemfile.lock
dist/
node_modules/
solr-home/data
+
+.buildpath
+.project
+.settings/

For sites that do not install Omeka as root (e.g. /omeka), links generated in the indexing are incorrect.

e.g.

Correct path:

http://localhost/omeka/exhibits/show/health

indexed location:

http://localhost/exhibits/show/health

Indexing needs to take in to account the install root in the URL

I get the following warning instead of item metadata for each of the docs returned in the search results:

Warning: Invalid argument supplied for foreach() in [...]/helpers/SolrSearch_ViewHelpers.php on line 282

This only happens when hit highlighting is turned off in the SolrSearch config. When hit highlighting is turned on, I don't get the warning/error.

We've taken out indexing stored XML files, so we shouldn't index Fedora documents, either.

This should be handled by the after_save_item hook.

Line 221 and 223 in /helpers/SolrSearchFunctions.php have $#22; for the closing quote around the facet. It should be �

For multi-node installs of Solr need to be addressed to properly pass the reload command to make the index available to the plugin.

Currently, tags, collections, and item types are the default facets. These fields should also be indexed by default:

• dc:title
• dc:description

Facets removed on the interface should only remove the element that is clicked on, not the entire built search.

On sets with a lot of elements in them, it's easy to get lost on which checkbox goes with each box. Could we do a zebra stripe on that to make it clearer? Maybe have a hover effect that highlights the line you're on?

The label on the Field Configuration is 'Save Facets;' needs a better label since this is facets + index fields

Current facet link produces something like 39_s:"Smythe,%20William%20"Bill"" (when the thing being faceted has quotes in it).

It should be encoded to something like 39_s:"Smythe,%20William%20%5C"Bill%5C"" (where the quotes are escaped by a backslash).

The first will return zero hits while the second will return the correct number of hits.

Right now the feedback a user gets from the SolrSearch on scroll are as follows:

    msgText: '<em>Loading next set of items...</em>',
    finishedMsg: '<em>You have reached the end of the results.</em>'

These are smallish text fields that display briefly, but may need some styling. Perhaps a larger text size.

Also, this is the default loading image

Is there a better loader out there?

I am running v1.0.0-alpha (fetched 23 Apr 12) on Omeka v1.5. I have Images set to display and three facets defined (Tag, Collection, and Item Type) but no Images are displayed in the results set and no facets are displayed (the facet titles are displayed). See calliope.simmons.edu/omeka I tried both Browse Items and a search for 'fabric'.

Admin uses simple-search path hook too. Since there's no admin view, omeka throws an exception.

Make the search box more like what has been implemented by project Blacklight

line 101:

        if (isset($current['facet'])) {
            $facetq = "{$current['facet']}+AND+$facet:"$label"";
        } else {
            $facetq = "$facet:"$label"";
        }

In some cases $current['facet'] is set but empty so I'm seeing URLs like;

?solrq=&solrfacet=+AND+itemtype:%22Still%20Image%22

which throws a bad request exception.

Changing (isset($current['facet'])) to (!empty($current['facet'])) solves the problem for me.

From the Omeka dev list:

Sorry, but this now worse than it was. The html entities are fixed but now I can't even get to the point of getting to the facets. If I browse for all items using the URI specified in http://omeka.org/codex/Plugins/SolrSearch, that is, http://calliope.simmons.edu/omeka/solr-search/results/?q=: (which was working before) I get fatal errors with the following in the errors.log file
2012-04-10T15:28:42-04:00 ERR (3): exception 'Apache_Solr_HttpTransportException' with message ''400' Status: Bad Request' in /gslis/omeka-1.5/plugins/SolrSearch/lib/Service.php:338
Stack trace:
#0 /gslis/omeka-1.5/plugins/SolrSearch/lib/Service.php(1170): Apache_Solr_Service->sendRawGet('http://localhos...')
#1 /gslis/omeka-1.5/plugins/SolrSearch/controllers/ResultsController.php(162): Apache_Solr_Service->search(':_ AND (image:...', 0, '20', Array)
#2 /gslis/omeka-1.5/plugins/SolrSearch/controllers/ResultsController.php(54): SolrSearch_ResultsController->search(Array, 0, '20')
#3 /gslis/omeka-1.5/plugins/SolrSearch/controllers/ResultsController.php(38): SolrSearch_ResultsController->handleHtml()
#4 /gslis/omeka-1.5/application/libraries/Zend/Controller/Action.php(516): SolrSearch_ResultsController->indexAction()
#5 /gslis/omeka-1.5/application/libraries/Zend/Controller/Dispatcher/Standard.php(295): Zend_Controller_Action->dispatch('indexAction')
#6 /gslis/omeka-1.5/application/libraries/Zend/Controller/Front.php(954): Zend_Controller_Dispatcher_Standard->dispatch(Object(Zend_Controller_Request_Http), Object(Zend_Controller_Response_Http))
#7 /gslis/omeka-1.5/application/libraries/Zend/Application/Bootstrap/Bootstrap.php(97): Zend_Controller_Front->dispatch()
#8 /gslis/omeka-1.5/application/libraries/Zend/Application.php(366): Zend_Application_Bootstrap_Bootstrap->run()
#9 /gslis/omeka-1.5/application/libraries/Omeka/Core.php(165): Zend_Application->run()
#10 /gslis/omeka-1.5/index.php(28): Omeka_Core->run()
#11 {main}

and from my catalina.out file:
Apr 10, 2012 3:44:48 PM org.apache.solr.common.SolrException log
SEVERE: org.apache.solr.common.SolrException: org.apache.lucene.queryParser.ParseException: Cannot parse ': AND (image:* OR :)': '' or '?' not allowed as first character in WildcardQuery
at org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:125)
at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:173)
at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1372)
at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:356)
at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:252)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:680)
Caused by: org.apache.lucene.queryParser.ParseException: Cannot parse ':* AND (image:* OR :)': '*' or '?' not allowed as first character in WildcardQuery

CSS from the theme isn't getting rendered in the results/index view.

There is a horribly uninformative stack trace that is displayed when the plugin cannot communicate with the Solr server.

Apache_Solr_HttpTransportException
'0' Status: Communication Error

We need to catch this particular exception and provide a bit of info on what's going on. Maybe a wiki page?

Currently, in the facet browser and other places, the fields are labeled with the *_s field names used by Solr. This should use the names of the elements.

Facets use jquery-ui accordion. By default, the CSS for jquery-ui isn't included, so we need a basic CSS for the accordion in the stylesheet.

http://jqueryui.com/demos/accordion/#theming

Right now this is marked as Solr Index; is this a clear enough label? think people will be looking for SolrSearch?

The solrQueryParser element that defined the default operator has been deprecated. Instead, we need to refactor to use q.op in the request handler to switch from default of OR.

Currently the solr config is a 1.4.x version of the Solr schema; there is quite a bit that is being deprecated and some of the field types have changed. Need to go through the new style and push these updates in to the config for deployment.

Pagination is dead! Long live infinite scroll.

Clicking on a tag generated out of SolrSearch_ViewHelpers::tagsToStrings($tags) produces a 400 error if a default search has been generated (with a blank facet).

I did a pull to the latest 'develop' version (and am using Omeka 1.5.1). I deleted my Solr data directory and did an uninstall and reinstall of the SolrSearch plugin. When I do the reinstall I try to configure the plugin on the settings/configure page (using localhost, port 8983, /solr/, 20, Occurrences, and 25 (as configuration values)). When I try to save the settings, I do not get anything in the errors.log but I get a displayed error: "Invalid Solr server host, port, or core."

When I look at the Solr logs I see an undefined "cat" field error:

21:24:14.325 [qtp2134042896-30 - /solr/admin/ping] INFO org.apache.solr.core.SolrCore - [] webapp=null path=null params={start=3&q=solr&qt=dismax&fq=id:[+TO+]&fq=cat:[+TO+]} status=400 QTime=30
21:24:14.326 [qtp2134042896-30 - /solr/admin/ping] ERROR o.a.solr.servlet.SolrDispatchFilter - org.apache.jasper.JasperException: org.apache.solr.common.SolrException: undefined field cat
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:437)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:483)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:373)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:558)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:488)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:520)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:233)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:973)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:417)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:907)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:271)
at org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:98)
at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:275)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1337)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:486)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:520)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:233)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:973)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:417)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:907)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:250)
at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:110)
at org.eclipse.jetty.server.Server.handle(Server.java:346)
at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:442)
at org.eclipse.jetty.server.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:924)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:582)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:218)
at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:51)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:586)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:44)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:598)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:533)
at java.lang.Thread.run(Thread.java:679)

Clicking on index doesn't work either. On another machine where I just installed the latest git changes but didn't wipe the index or uninstall/reinstall the index is still there and can be queried. Changes to the configure/settings page, though, also gives the same error message.

I look in the solrconfig.xml file and I see the ping query is: qt=dismax&q=solr&start=3&fq=id:[* TO ]&fq=cat:[ TO *]

So, I removed the &fq=cat:[* TO *] part of the ping query and then everything worked fine. So I'm guessing the ping just started to be used to give a better error page. Users I think though would need to delete that part of the ping query or make sure that the field is created in Solr so they don't get this error.

This doesn't actually do anything to search images, and sorting by images seems similarly ill-defined. Should the image facet just be removed, and the images can still be included in results views?

SOLR_FACET_LIMIT should be pulled from the default result count set in the admin items per page setting.

Use search highlights by default to display the content information to the user

If untitled items are returned in a search, I get an Omeka exception because a current item is not set for the view.

The defaultSearchField has been deprecated; we need to specify df in our RequestHandler and set it to fulltext for future compatibility.

Tags need to have facet search path associated with them

When the Coins plugin is enabled, an exception is thrown on the results page. Coins plugin appears to be calling item (which is not instantiated in the plugin) on the results page.

exception 'Exception' with message 'An item has not been set to be displayed on this theme page! Please see Omeka documentation for details.' in /sds.pri/projects/quandu-staging/falmouth/releases/20110718152709/application/helpers/ItemFunctions.php:74
Stack trace:
#0 /sds.pri/projects/quandu-staging/falmouth/releases/20110718152709/application/helpers/ItemFunctions.php(196): get_current_item()
#1 /sds.pri/projects/quandu-staging/falmouth/releases/20110718152709/plugins/Coins/functions.php(177): item('Dublin Core', 'Creator', Array)
#2 /sds.pri/projects/quandu-staging/falmouth/releases/20110718152709/plugins/Coins/functions.php(83): Coins->_getElementText('Creator')
#3 /sds.pri/projects/quandu-staging/falmouth/releases/20110718152709/plugins/Coins/functions.php(57): Coins->_setElements()
#4 /sds.pri/projects/quandu-staging/falmouth/releases/20110718152709/plugins/Coins/functions.php(5): Coins->__construct()
#5 [internal function]: coins()
#6 /sds.pri/projects/quandu-staging/falmouth/releases/20110718152709/application/libraries/Omeka/Plugin/Broker.php(157): call_user_func_array('coins', Array)
#7 /sds.pri/projects/quandu-staging/falmouth/releases/20110718152709/application/libraries/Omeka/Plugin/Broker.php(183): Omeka_Plugin_Broker->callHook('public_append_t...', Array)
#8 [internal function]: Omeka_Plugin_Broker->__call('public_append_t...', Array)
#9 [internal function]: Omeka_Plugin_Broker->public_append_to_items_browse_each()
#10 /sds.pri/projects/quandu-staging/falmouth/releases/20110718152709/application/libraries/globals.php(211): call_user_func_array(Array, Array)
#11 [internal function]: fire_plugin_hook('public_append_t...')
#12 /sds.pri/projects/quandu-staging/falmouth/releases/20110718152709/application/libraries/globals.php(230): call_user_func_array('fire_plugin_hoo...', Array)
#13 /sds.pri/projects/quandu-staging/falmouth/releases/20110718152709/application/helpers/PluginFunctions.php(71): get_plugin_hook_output('public_append_t...')
#14 /sds.pri/projects/quandu-staging/falmouth/releases/20110718152709/themes/falmouth/solr-search/results/index.php(167): plugin_append_to_items_browse_each()
#15 /sds.pri/projects/quandu-staging/falmouth/releases/20110718152709/application/libraries/Omeka/View.php(114): include('/sds.pri/projec...')
#16 /sds.pri/projects/quandu-staging/falmouth/releases/20110718152709/application/libraries/Zend/View/Abstract.php(888): Omeka_View->_run('/sds.pri/projec...')
#17 /sds.pri/projects/quandu-staging/falmouth/releases/20110718152709/application/libraries/Zend/Controller/Action/Helper/ViewRenderer.php(897): Zend_View_Abstract->render('results/index.p...')
#18 /sds.pri/projects/quandu-staging/falmouth/releases/20110718152709/application/libraries/Zend/Controller/Action/Helper/ViewRenderer.php(918): Zend_Controller_Action_Helper_ViewRenderer->renderScript('results/index.p...', NULL)
#19 /sds.pri/projects/quandu-staging/falmouth/releases/20110718152709/application/libraries/Zend/Controller/Action/Helper/ViewRenderer.php(957): Zend_Controller_Action_Helper_ViewRenderer->render()
#20 /sds.pri/projects/quandu-staging/falmouth/releases/20110718152709/application/libraries/Zend/Controller/Action/HelperBroker.php(277): Zend_Controller_Action_Helper_ViewRenderer->postDispatch()
#21 /sds.pri/projects/quandu-staging/falmouth/releases/20110718152709/application/libraries/Zend/Controller/Action.php(523): Zend_Controller_Action_HelperBroker->notifyPostDispatch()
#22 /sds.pri/projects/quandu-staging/falmouth/releases/20110718152709/application/libraries/Zend/Controller/Dispatcher/Standard.php(295): Zend_Controller_Action->dispatch('indexAction')
#23 /sds.pri/projects/quandu-staging/falmouth/releases/20110718152709/application/libraries/Zend/Controller/Front.php(954): Zend_Controller_Dispatcher_Standard->dispatch(Object(Zend_Controller_Request_Http), Object(Zend_Controller_Response_Http))
#24 /sds.pri/projects/quandu-staging/falmouth/releases/20110718152709/application/libraries/Zend/Application/Bootstrap/Bootstrap.php(97): Zend_Controller_Front->dispatch()
#25 /sds.pri/projects/quandu-staging/falmouth/releases/20110718152709/application/libraries/Zend/Application.php(366): Zend_Application_Bootstrap_Bootstrap->run()
#26 /sds.pri/projects/quandu-staging/falmouth/releases/20110718152709/application/libraries/Omeka/Core.php(166): Zend_Application->run()
#27 /sds.pri/projects/quandu-staging/falmouth/releases/20110718152709/index.php(30): Omeka_Core->run()
#28 {main}

The facet config form has labels for "Is Displayed" and "Is Visible," but it's not clear how those are different.

When there was pagination and a sort-order component, they were aligned on a row together. We've gotten rid of these elements and now the number of result is on a single row by itself. Need to find a better place for this information...

The data gets displayed in the search resutls instead of the image. For example:

a:7:{s:8:"FileName";s:36:"48c412cf2b1d1dc7f4902201f80174e6.jpg";s:12:"FileDateTime";i:1335375642;s:8:"FileSize";i:8378;s:8:"FileType";i:2;s:8:"MimeType";s:10:"image/jpeg";s:13:"SectionsFound";s:0:"";s:8:"COMPUTED";a:4:{s:4:"html";s:24:"width="300

The raw Solr results for this is:

<arr name="76_s">
<str>FileName:48c412cf2b1d1dc7f4902201f80174e6.jpgFileDateTime:1335375642FileSize:8378FileType:2MimeType:image/jpegSectionsFound:COMPUTED:  html:width="300" height="204"   Height:204  Width:300   IsColor:1</str>
</arr>
<arr name="77_s">
<str>a:7:{s:8:"FileName";s:36:"48c412cf2b1d1dc7f4902201f80174e6.jpg";s:12:"FileDateTime";i:1335375642;s:8:"FileSize";i:8378;s:8:"FileType";i:2;s:8:"MimeType";s:10:"image/jpeg";s:13:"SectionsFound";s:0:"";s:8:"COMPUTED";a:4:{s:4:"html";s:24:"width="300" height="204"";s:6:"Height";i:204;s:5:"Width";i:300;s:7:"IsColor";i:1;}}</str>
</arr>

The data from 77_s is also added to the fulltext field.

resulttype and itemtype need to be broken into two words with appropriate capitalization.

In the long term, this should be configurable.

It might be nice to be able to say items in collections X, Y, and Z are to be indexed, but items in collections A and B are not.

Right now, this supports TEI Plugin and Fedora Connector, but both are hard-coded. This should be replaced by a hook system to any plugin can submit data for the document when it's being indexed.

Right now, error messages in the hook methods are just echoed to the browser.

There are a few 'special' types of data that can exist in Omeka that are not just string. For example, DC.date could map more easily on to the solr.date (or tdate) type to allow date spans to be searched (e.g. _:_AND date1 BETWEEN date1.

This may be a documentation problem. We may need to explain how to include fields in the keyword search.

Right now, the pagination for paging through SolrResults is separate from the items_per_page; would be less confusing to use the same option to control this setting.

(running v1.0.0-alpha on Omeka v1.5)

I attached a TEI document to an Omeka item and get the "Omeka has encountered an error" screen. The file uploads and is attached to the item properly (I had previously made changes to the security settings to allow xml files to be uploaded) but I don't think they're indexed. I get the following errors and stack trace in my errors.log

2012-04-24T16:39:47-04:00 INFO (6): getID3: Unable to determine file format
2012-04-24T16:39:47-04:00 ERR (3): exception 'Exception' with message 'Cannot get the local path for a stored file.' in /gslis/omeka-1.5/application/models/File.php:110
Stack trace:
#0 /gslis/omeka-1.5/plugins/SolrSearch/helpers/SolrSearch_IndexHelpers.php(90): File->getPath('archive')
#1 /gslis/omeka-1.5/plugins/SolrSearch/SolrPlugin.php(103): SolrSearch_IndexHelpers::itemToDocument(Object(Omeka_Db), Object(Item))
#2 [internal function]: SolrPlugin->afterSaveItem(Object(Item))
#3 /gslis/omeka-1.5/application/libraries/Omeka/Plugin/Broker.php(156): call_user_func_array(Array, Array)
#4 /gslis/omeka-1.5/application/libraries/Omeka/Plugin/Broker.php(182): Omeka_Plugin_Broker->callHook('after_save_item', Array)
#5 [internal function]: Omeka_Plugin_Broker->__call('after_save_item', Array)
#6 [internal function]: Omeka_Plugin_Broker->after_save_item(Object(Item))
#7 /gslis/omeka-1.5/application/libraries/Omeka/Record.php(304): call_user_func_array(Array, Array)
#8 /gslis/omeka-1.5/application/libraries/Omeka/Record.php(566): Omeka_Record->runCallbacks('afterSave')
#9 /gslis/omeka-1.5/application/libraries/Omeka/Record.php(807): Omeka_Record->save()
#10 /gslis/omeka-1.5/application/libraries/Omeka/Controller/Action.php(482): Omeka_Record->saveForm(Array)
#11 /gslis/omeka-1.5/application/controllers/ItemsController.php(99): Omeka_Controller_Action->editAction()
#12 /gslis/omeka-1.5/application/libraries/Zend/Controller/Action.php(516): ItemsController->editAction()
#13 /gslis/omeka-1.5/application/libraries/Zend/Controller/Dispatcher/Standard.php(295): Zend_Controller_Action->dispatch('editAction')
#14 /gslis/omeka-1.5/application/libraries/Zend/Controller/Front.php(954): Zend_Controller_Dispatcher_Standard->dispatch(Object(Zend_Controller_Request_Http), Object(Zend_Controller_Response_Http))
#15 /gslis/omeka-1.5/application/libraries/Zend/Application/Bootstrap/Bootstrap.php(97): Zend_Controller_Front->dispatch()
#16 /gslis/omeka-1.5/application/libraries/Zend/Application.php(366): Zend_Application_Bootstrap_Bootstrap->run()
#17 /gslis/omeka-1.5/application/libraries/Omeka/Core.php(165): Zend_Application->run()

See http://calliope.simmons.edu/omeka/items/show/908 for an example of an item with a TEI document attached.

Solr doesn't allow sorting on multivalue fields, but the SolrSearch plugins index configuration allows any field to be selected as a sort field. If you select a multivalue field to be a sort field and then try it, you get an exception in Solr:

org.apache.solr.core.SolrCore - org.apache.solr.common.SolrException: can not sort on multivalued field: 40_s
at org.apache.solr.schema.SchemaField.checkSortability(SchemaField.java:161)
at org.apache.solr.schema.FieldType.getStringSort(FieldType.java:527)
at org.apache.solr.schema.StrField.getSortField(StrField.java:40)
at org.apache.solr.schema.SchemaField.getSortField(SchemaField.java:144)
at org.apache.solr.search.QueryParsing.parseSort(QueryParsing.java:385)
at org.apache.solr.search.QParser.getSort(QParser.java:251)
at org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:102)
at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:173)
at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1372)
at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:356)
at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:252)

The current implementation of SolrSearch attempts to create all objects before creating HTTP requests to Solr. This needs to be refactored to more efficiently iterate results without filling memory allocation (or requiring a very large memory allocation).

When querying from the simple search box, there's an empty facet included in the search.