You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My DocumentObject class also just has it's won canIndexInAlgolia function eg.
public function canIndexInAlgolia(): bool
{
return true ;
}
The issue is that this class also for some unrelated reason (legacy) has the same "ShowInSearch" field.
My legacy ShowInSearch is flagged here as false.
if (!$instance || min($instance->invokeWithExtensions('canIndexInAlgolia')) == false) {
Hopefully this makes sense.
Before I make any kind of pull request, I would be interest to know If there is a work around or something I'm missing?
I imagine changin the indexing logic drastically will be a major version change, so maybe an approach is to also include an extension hook before resolving, albiet this seems slightly against the normal way?
As a possible work around you could try define a public function getShowInSearch() on your DataObject which returns true.
I've never fully understood the best practices for Silverstripe's use of invokeWithExtensions / extend.
An alternative change could be to make the ShowInSearch field name configurable on AlgoliaObjectExtension, and update canIndexInAlgolia to something like:
Hi, Not sure if this is a bug or a feature!
But I am running into the issues where I have a data object that is NOT indexing.
Here's the scenario:
I have
DocumentObject
And is configured to use the extension
My DocumentObject class also just has it's won canIndexInAlgolia function eg.
The issue is that this class also for some unrelated reason (legacy) has the same "ShowInSearch" field.
My legacy ShowInSearch is flagged here as false.
silverstripe-algolia/src/Extensions/AlgoliaObjectExtension.php
Line 96 in 3addea3
This basically means that due to the way the indexing is done and the "canIndexInAlgolia" is merged, this item can't be indexed
silverstripe-algolia/src/Tasks/AlgoliaReindex.php
Line 220 in 3addea3
Hopefully this makes sense.
Before I make any kind of pull request, I would be interest to know If there is a work around or something I'm missing?
I imagine changin the indexing logic drastically will be a major version change, so maybe an approach is to also include an extension hook before resolving, albiet this seems slightly against the normal way?
The text was updated successfully, but these errors were encountered: