Details
-
Bug
-
Resolution: Fixed
-
High
-
5.3, 2015.01, 5.4.0
-
N/A
Description
some steps to reproduce:
1. get ezFind working
2. customize some class for search:
- at any class (article is good), add an attribute named "extrasolrfield" of type textline, and mark it searchable
- create a new object of that class, insert in the "extrasolrfield" some sentence with a "relavant" word for search. with the typo, to make the word unique and save work later
- search it in front end, just to assure there is a single object as result
3. customize ezsearch template:
- open the ezfind/design/ezdemo/templates/search.tpl file
- modify the fetch operator to include the field.
it becomes:{set $search=fetch( ezfind,search, hash( 'query', $search_text, 'offset', $view_parameters.offset, 'limit', $page_limit, 'sort_by', hash( 'score', 'desc' ), 'facet', $defaultSearchFacets, 'as_objects', false(), 'fields_to_return', array( 'attr_extrasolrfield_s'), 'filter', $filterParameters, 'publish_date', $dateFilter, 'spell_check', array( true() ), 'search_result_clustering', hash( 'clustering', false() ) ) )} {$search|dump('show',4)}
note: the option "asObjects" is incorrect, it needs also to be modified to "as_objects"
5. run test:
- in frontend, search for the "relavant" word that should give 1 result
- check in the dump result that the array "fields" is not present as expected.
the "fields" should be included, according to comment in eZSolr::buildResultObjects():
// check if field is not in the explicit field list, to keep explode from generating notices. // it may be a field originating from the explicit fieldlist to return, so it should be added for template consumption // note that the fieldname will be kept verbatim in a substructure 'fields'
Attachments
Issue Links
- links to