I'm raising this issue for the rules action mentioned in #1118416: Add option to index entities instantly after they are saved (in #1 & #3).

I'm not 100% if it will be a single action or two actions (one for immediately indexing an entity, one for marking it as needing indexing on the next cron run). Hence the lengthy title - feel free to adjust it to what is actually going to be added.

I'm not sure if its been forgotten or not but I wanted to keep track of it somewhere and there wasn't already an issue for it.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

drunken monkey’s picture

Ah, you're right, I thought there already was an issue …
I think, both actions will be needed. However, as I'm not familiar with Rules, fago has volunteered to take care of those things. Any help bugging him about it would be appreciated. ;)

sepgil’s picture

Status: Active » Needs review
FileSize
0 bytes

This patch adds the requested actions. It was made in collaboration with drunken monkey.

sepgil’s picture

FileSize
1.84 KB
fago’s picture

Status: Needs review » Needs work

To me it's unclear what the actions really do. I'd suggest doing it the following way:

* Do one action and add a setting (boolean) "index immediately"
* Add another optional parameter to select a certain index only, that's simple to do with type == 'search_api_index' and marking it as 'optional' => TRUE.

sepgil’s picture

Status: Needs work » Needs review
FileSize
2.27 KB

Added changes suggested by fago.

mh86’s picture

Status: Needs review » Needs work

unfortunately the 'index immediately' setting doesn't work in the Rules action in case the Search API index doesn't have this option set as well.

drunken monkey’s picture

Status: Needs work » Needs review

unfortunately the 'index immediately' setting doesn't work in the Rules action in case the Search API index doesn't have this option set as well.

Couldn't reproduce that, for me it works perfectly fine. Are you sure you configured it right? If so, maybe try the newest version?

mh86’s picture

Status: Needs review » Needs work

Did some more testing: it works when updating a node, but not when inserting a new one, although in both cases my rules action fires (events After saving new content, After updating existing content).
Does it work with new items for you?

Furthermore, concerning the "Search index identifier" setting, a select list with the possible ones would be nice and we should extend the description telling that this setting is actually optional and if left empty all possible indexes will be taken.

mh86’s picture

ok, forget what I've just said ;-) Index immediately works fine, except that there is a small delay on my local machine!

Still we can improve the search index identifier setting :)

filsterjisah’s picture

This patch works great. Used it to update (solr) indexes of node when (node)references were updated since data of this reference should be also indexed. Will this be integrated in the next release? (not in dev version atm i see)

drunken monkey’s picture

Status: Needs work » Needs review
FileSize
3.29 KB

Now with a select list to choose the index. Please test!

@ filsterjisah: Please set the issue status to “reviewed & tested by the community” if everything works fine. Then I can commit this and it will be in the next release.

mh86’s picture

Status: Needs review » Needs work

Thanks for the update, Thomas.

While testing, I encountered two problems:

  • The index setting in the action is optional ("... Leave blank to index on all indexes for this item type."), but an empty entry is missing in the options list, so I can't leave the index setting blank. An empty entry should be added in the options callback.
  • Index immediately does not really work with Solr if this option is not set on the index itself. Then Solr waits for the autocommit. In the indexItems function this behaviour is hardcoded (it always checks for the index settings), so we would need either an additional (and of course optional) parameter to this function, or any other solution ;-)
drunken monkey’s picture

Status: Needs work » Needs review
FileSize
3.33 KB

As discussed, I'd think that Rules should take care of that. It unnecessarily makes a generic function way more specific and thus reduces reusability.
However, as this probably won't be fixed in Rules soon, I worked around it in the attached patch.

Regarding the other problem: that's a Solr-specific issue, nothing that can reasonably be fixed here.
I'm, however, also rather clueless as to how to fix this in the Solr module. We'll probably have to make the current ugly fix even uglier. See #1805950: Fix “Index immediately” functionality.

mh86’s picture

Status: Needs review » Reviewed & tested by the community

Rules integration works fine now and let's tackle the Solr specific stuff in the separate issue.

mh86’s picture

Status: Reviewed & tested by the community » Needs work

Ah, one more thing: the function _search_api_rules_action_index_help() seems to be unused!

drunken monkey’s picture

Status: Needs work » Fixed

No, it's not. _search_api_rules_action_index is set as the base for callbacks, so that function is the help callback. Just look at the top of the page when adding/editing the action somewhere to see the text.

(Finally) Committed, thanks for everyone's help!

mh86’s picture

Ah, I see, thanks for pointing that out.
And great to have it finally committed!

DYdave’s picture

Hi guys,

Thanks very much for this great new feature.
Previously, I was using custom php code in an action to force the indexing, for nodes on content update/save.
I would certainly be glad to replace this code with this action.

I have started testing it and it seems to be working fine so far.
I just had a few comments below:

1 - I wanted to double check some code change to the use of this action:
Previously, I encountered a few issues with indexing of content because of cached entities for node. Perhaps because I am using i18n_sync and entitycache modules (i18n_sync, which consequently forces the indexing of translated synced content items). I don't remember exactly why, but most likely it was because of entitycache.
So I ended up adding this code:

//Watchout: This line is important for forcing the update of the cache 
//for translations synchronization on node update, see entity_load $reset function argument
entity_get_controller('node')->resetCache();

Would something like that still be required or useful? Perhaps it has been integrated in indexing functions already.

2 - This may sound like a feature request, but I wanted to know if it would be possible to potentially add some logging in watchdog, upon indexing, pretty much the same way it is being done in _search_api_indexing_queue_process in search_api.module-7.x-1.2+9-dev line 2144

if ($num) {
  watchdog('search_api', t('Indexed @num items for index @name', array('@num' => $num, '@name' => $index->name)), NULL, WATCHDOG_INFO);
}

so I went ahead and put together a quick patch for that, against search_api-7.x-1.2+9-dev, see attached.
Added a new parameter to the action form to toggle a verbose mode [defaults to FALSE].
If it is activated it will log a watchdog entry about the indexing results.
Since this release seems to be pretty fresh, I thought this could be useful and perhaps added as a quick feature in this ticket.

I would greatly appreciate your comments and feedbacks on these two items.
Thanks again for the great work.

DYdave’s picture

Status: Active » Needs review

Attempt to get some feedback on ticket by changing status to needs review.

Thanks in advance.

drunken monkey’s picture

Status: Needs review » Fixed

Please create a new issue for that.

DYdave’s picture

Thanks drunken monkey.
I've done that and it's posted at: #1889098: Rules action for indexing entities, enable verbose mode for log messages..

Hopefully, I'll get some feedback there.
Cheers!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.