Class NoteContentIndexingListener
note.posted / note.updated /
note.deleted events to keep the portal Page carrying this note as
a Single Note View content block in sync with Social's generic "page"
search index, whether the note's content changed or the note itself was
deleted.
Resolving the page and the search index's document id is entirely
PageContentBlockPluginService's responsibility — Notes only
knows its own content type and the CMSSetting name (which
equals the note's own name, an invariant NotePageViewService
guarantees by always creating such a note as new Page(name, name)).
Deletion can't be handled by just re-indexing: the CMSSetting
binding the note to its page survives the note's deletion (nothing
deletes it), so a plain re-index still resolves a page/block id — it's
only the connector's create() that then finds no note content
and returns null, which the indexing framework treats as "skip
this operation", not "delete the existing document". The stale document
would linger forever unless deletion is unindexed explicitly.