Thanks to Marco Hermo and Brett Tasker for helping with this
* Bump framework/cms to ^4.0@dev
* WIP Silverstripe 4 compatibility fixes
* more replacements and patches to migrate this module to 4.0
* Update composer.json
* remove php <5.5 from travis.yml
* WIP more SS4 compatibility fixes
* WIP fix solr path to use DIR, avoid hardcoded module name
* WIP respect current include path
* WIP Namespacing and use on SearchIndex class
* Namespacing for tests
* WIP add namespaces to all classes
* Second push of Test changes + namespacing
* WIP split Solr files with multiple classes into single file / single class. Adjust namespaces
* Fix PHP errors in test
* break out search components with multiple classes into individual files and change namespaces
* Update namespacing for Search indexes and variants in tests
* Batch fixes for tests #2
* Update _config.php to use namespace
* Use root namespace in referencing Apache_Solr_Document
* Migrate task names so that the name is not fully qualified
When the database isn’t yet created, $current is set, but
$current->currentDatabase() is empty. I suspect this only applies to
PDO connections. It results in errors during startup.
This check fixes it.
Stopped indexing of classes which were unrelated to overall variants.
For example, an index with excludeVariantState(array('SearchVariantVersioned' => 'Stage'))
should only set this variant state on types where appliesTo() returns true, namely "Page".
Without the $class parameter it also returned on "File" index requests,
which then lead to all index requests being discarded later on somewhere in SearchUpdater.
Regression introduced in 625d282.
This fixes a critical bug meaning that using many_many fields in full text searching would have always failed.
the $singleton->many_many() lookup returns an array() of many-many components, however the line $class = $manyMany[0] is wrong, as the first value of the array is always the $dataClass (parentClass), not the otherClass (childClass).
Changing this to $class = $manyMany[1] fixes this bug.
Solr::configure_server now takes "version" as one of the keys in the
option array, and behaves slightly differently depending on whether
that version is 3 or 4, to provide support for both Solr versions.
The Solr extras and templates have also moved, so that different
versions can be provided for the two different Solr versions.
