diff --git a/docs/en/configuration.md b/docs/en/configuration.md index 1c33820..a0b395f 100644 --- a/docs/en/configuration.md +++ b/docs/en/configuration.md @@ -18,6 +18,11 @@ SilverStripe\Forager\Service\IndexConfiguration: title: property: Title content: true + term_ids: + property: Terms.ID + options: + type: number + ``` Let's look at each relevant node: @@ -45,6 +50,14 @@ resolver within `DataObjectDocument` is smart enough to resolve inconsistencies so when it finds that the property `$content` doesn't exist on the `SiteTree` instance, it will use a case matching strategy as a fallback. +* `term_ids`: + + * `property: Terms.ID`: This shorthand only works for DataObjects. Where `Terms` is a `has_many` (or `many_many`) + relationship, using `Terms.ID` will result in your receiving an array of IDs from each related DataObject (in this + example, that would be the ID of each related `TaxonomyTerm`) + * `options.type: number`: This is how you can define the field type for your field. Note: What field types are valid + will depend on what service you are integrating with + It is important to note that the keys of `fields` can be named anything you like, so long as it is valid in your search service provider (for EnterpriseSearch, that's all lowercase and underscores). There is no reason why `title` cannot be `document_title` for instance, diff --git a/src/Service/IndexConfiguration.php b/src/Service/IndexConfiguration.php index 74d5522..e3824fa 100644 --- a/src/Service/IndexConfiguration.php +++ b/src/Service/IndexConfiguration.php @@ -7,6 +7,7 @@ use SilverStripe\Core\Extensible; use SilverStripe\Core\Injector\Injectable; use SilverStripe\Forager\DataObject\DataObjectDocument; +use SilverStripe\Forager\Exception\IndexConfigurationException; use SilverStripe\Forager\Interfaces\DocumentInterface; use SilverStripe\Forager\Schema\Field; @@ -247,11 +248,22 @@ public function getFieldsForClass(string $class): ?array continue; } - $config = (array)$data; + $fieldConfig = (array) $data; + // This is a callout to a common misconfiguration that will result in developers receiving an + // unexpected field type. The correct yaml format is for this to be part of the "options" object + $invalidTypeField = $fieldConfig['type'] ?? null; + + if ($invalidTypeField) { + throw new IndexConfigurationException( + 'Field configuration for "type" should be defined under the "options" object.' + . ' Please see configuration.md#basic-configuration for an example.' + ); + } + $fieldObjs[$searchName] = new Field( $searchName, - $config['property'] ?? null, - $config['options'] ?? [] + $fieldConfig['property'] ?? null, + $fieldConfig['options'] ?? [] ); } }