silverstripe / cwp-recipe-search Goto Github PK

This module depends on silverstripe/fulltextsearch 3.2@stable which depends on cwp-search which itself depends on silverstripe/fulltetxsearch ^3. If cwp-recupe-search module is including cwp-search, then the fulltextsearch dependency should be omitted, otherwise the usual Composer conflict applies (and you guys need to maintain at least 2 refs to the same package).

composer.json snippet

  7     "require": {
  8         "php": ">=5.6",
  9         "cwp/cwp-recipe-search": "2.0.0-rc2",
 10         "silverstripe/recipe-form-building": "1.x-dev",
 11         "silverstripe/recipe-authoring-tools": "1.x-dev",

Composer Error

  Problem 1
    - cwp/cwp-search 1.0.0-rc1 requires silverstripe/fulltextsearch 3.0.0-rc1 -> satisfiable by silverstripe/fulltextsearch[3.0.0-rc1].
    - Can only install one of: silverstripe/fulltextsearch[3.2.0, 3.0.0-rc1].
    - cwp/cwp-recipe-search 2.0.0-rc2 requires cwp/cwp-search 1.0.0-rc1 -> satisfiable by cwp/cwp-search[1.0.0-rc1].
    - cwp/cwp-recipe-search 2.0.0-rc2 requires silverstripe/fulltextsearch 3.2.0@stable -> satisfiable by silverstripe/fulltextsearch[3.2.0].
    - Installation request for cwp/cwp-recipe-search 2.0.0-rc2 -> satisfiable by cwp/cwp-recipe-search[2.0.0-rc2].

With the release of 2.3.0 an 2.3.1, a move was made to use the built-in POST index store of fulltextsearch.

However CWP does not work with this version of the POST store due silverstripe/silverstripe-fulltextsearch#260

remotepath is not set or used in CWP so is breaking Solr_Configure on CWP environments.

This previously wasn't a problem in 2.2.x as we were using the CWP defined POST index store instead which validates if this is actually set before trying to assign.

https://github.com/silverstripe/cwp-search/blob/master/src/Solr/CwpSolrConfigStore.php

At current the recipe does not use the public folder by default, nor does it render a search bar in the starter theme, if one installs it. This latter point is probably in the wrong place, but it would be nice to take a moment to figure out where it actually belongs (i.e. more of a note to self).
Should this recipe even have a public dir? I cannot remember how the system works on knowing when to and when not to install/use a public dir.

We see deprecated notices on a number of methods (search(), addTerm()). Looks like, with the upcoming 2.1.1-rc2, the deprecated method calls still exist.