Use hook_search_api_index_enabled() (resp. hook_search_api_index_disabled()) to determine when a new index is "created" or an old one "deleted", and insert / remove the corresponding entries in {search_api_item}.

Comments

drunken monkey’s picture

@ fago: Are hook_search_api_index_enabled() and hook_search_api_index_disabled() called for newly created entities in the database, too? The documentation says no, but the code says (or seems to me to say) yes …
If the latter is the case, you should make that clear in .api.php — otherwise, sorry.

drunken monkey’s picture

Title: Clean up the way new entities in code are handled » Incorporate newly available entity hooks

Let's use this issue also for documenting the changes permitted by #651240: Allow modules to react to changes to an entity: i.e., use the newly available $entity->original property in hook_entity_update() (and, therefore, hook_ENTITY_update()) to recognize what changed in a modified index or server, instead of the less accurate, ugly (and hack-inducing) $op parameter.

Therefore, marked #964816: Provide own EntityController for fixing hook invocations as a duplicate of this issue.

fago’s picture

ad #1, hm, the docs say yes too:

 * This hook is invoked for exportable entities regardless of their export
 * status as soon as new enabled entities are available to the system - either
 * as a new entity has been saved to the database or modules with entities in
 * code have been enabled.

ad #2:
ok. What is a bit strange for exportable entities though, is that you can use hook insert to react on changes too, because an entity might exist even before it is inserted in the db, as default in code.

fago’s picture

@status: see #978832-7: enable modules to apply configuration (exportable entities): Currently the feature requires the core patch + is not able to deal with an "activation" status flag yet.

drunken monkey’s picture

ad #1, hm, the docs say yes too:

Sorry, my bad — it seems I mixed up "exportable entities" and "entities in code".

@status: see #978832-7: enable modules to apply configuration (exportable entities): Currently the feature requires the core patch + is not able to deal with an "activation" status flag yet.

Oh, so this isn't actually working yet? Good to know. Hope the core patch will still make it in …

drunken monkey’s picture

OK, since there are a number of bugs solved by this and fago will have to fix the hook invocation without core patch anyways, I'm gonna go ahead and commit this. Please be aware that until #978832: enable modules to apply configuration (exportable entities) is fixed there will be problems when disabling modules that define default indexes (especially when they are later re-enabled).

There are quite a few API changes in this patch, here is a (hopefully complete) summary:

  • hook_ENTITY_update(): $op is gone, use $entity->original instead.
    Likewise, $op is also gone from the entity objects' save() methods.
  • New hook_search_api_index_reindex for recognizing when an index was scheduled for reindexing or cleared (because hook_search_api_index_update() won't be called anymore).
  • SearchApiServiceInterface::postUpdate() doesn't take $fields parameter anymore (see above).
  • SearchApiServiceInterface's postEnable() and postDisable() methods are gone, use postUpdate() instead. (Which should have been possible anyways — what was I thinking adding those other two methods?)
  • SearchApiServer's and SearchApiIndex's update($fields) methods can now also be used for changing the "enabled" field. Also, they are now just helper methods, the normal save() method can be used just as well.
  • SearchApiServer's and SearchApiIndex's enable($enabled) methods are gone.

Now finally easily possible, I've also added "Enabled" checkboxes to the server and index edit forms.

drunken monkey’s picture

Status: Active » Fixed
fago’s picture

Great work!

Status: Fixed » Closed (fixed)

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