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.
Its impossible for SearchUpdater#handle_manipulation to figure out the difference
between writing to a table-less class (like Page if theres no $db set) and the
table-having parent (like SiteTree) because it only examines the DB manipulation
This meant if you tried to index Page without setting $db fields, only subclasses
that did have $db fields would be indexed
We cant fix, but we can throw an error if you try to do that
process_dirty_indexes wasnt saving variant state or restoring or exit, because
I thought it was only called at the end of a request and so didnt need to
But tests call it regularly throughout a request. So now its clean
and safe to call when-ever
