So, I added a new field to the thread table and want it to be searchable. And it is. Extending the post save datawriters make it pretty easy to add in the new content into the message field of the search index table.
The issue is, when rebuilding the search index from the adminCP the message field is emptied because of this line in the protected function _insertIntoIndex (the '' where the message field is after $title):
To get around this I over wrote that method, and now it works. However; if another add-on over-rides that method (which i doubt there is one), either my new searchable data will be removed from the search index, or the other add-on's data will be. (using parent:: returns null)
The other solution is to create a new content type for my add-on. That's straight forward to do, but I'm on the fence for it as the new content type is thread-related so rebuilding the search index would involve looping through all the threads twice (once for rebuilding the standard thread info, and once again to rebuild my new data field). IMO, that's just a waste of resources.
So, I'm not too sure which is the lesser evil of the two methods. I'm leaning towards the first method as it doesn't take any more resources to rebuild the search index than what threads would use anyways. Plus it keeps the search index smaller as a new content type isn't inserted.
Any feedback/opinions welcomed.
The issue is, when rebuilding the search index from the adminCP the message field is emptied because of this line in the protected function _insertIntoIndex (the '' where the message field is after $title):
PHP:
$indexer->insertIntoIndex(
'thread', $data['thread_id'],
$title, '',
$data['post_date'], $data['user_id'], $data['thread_id'], $metadata
);
To get around this I over wrote that method, and now it works. However; if another add-on over-rides that method (which i doubt there is one), either my new searchable data will be removed from the search index, or the other add-on's data will be. (using parent:: returns null)
The other solution is to create a new content type for my add-on. That's straight forward to do, but I'm on the fence for it as the new content type is thread-related so rebuilding the search index would involve looping through all the threads twice (once for rebuilding the standard thread info, and once again to rebuild my new data field). IMO, that's just a waste of resources.
So, I'm not too sure which is the lesser evil of the two methods. I'm leaning towards the first method as it doesn't take any more resources to rebuild the search index than what threads would use anyways. Plus it keeps the search index smaller as a new content type isn't inserted.
Any feedback/opinions welcomed.
Last edited: