Search and replace has been implemented.  This page is left here only for historical purposes.
The search and replace documentation can be found here

When often-used terms change in a larger set of documents, having a global SERP functionality becomes a requirement. This SERP feature should again be as user-friendly as possible. The scenario should be similar as follows:

• some feature should be present to select a (sub)set of documents. Though the query language / tool already allows this, a more user-friendly option should be present as well, allowing the user to select certain parameters from a list, like document type, collection citizenship, perhaps even certain fields. (also see: unified search - a combination with a document basket seems useful)
• after establishing the initial search scope, the user provides the to-be-replaced search term (could be a word or a phrase) and its candidate replacement
• the scope is searched for this term (keeping in mind that the phrase could span multiple lines), and a search result is presented:
• the list of document hits is shown, with the search term hit highlighted in context, and an action menu [replace|replace all|skip|skip all], perhaps also with some sort of [prev|next] navigation.
• function follows obvious form and action

Notes after review with Bruno:

• Still lots of thinking and design work to do: functionality is less trivial than one might expect.
• Calls for a grep-like search, implies that users are aware of reg-ex patterns?
• Maybe use existing full-text search as a first-step scan, however beware:
• only live versions are searched (and we want last instead, since SERP will happen while editing)
• stop words are stripped from full-text index, so cannot be found
• Correct, but the actual SERP action will be performed on documents.  The users are themselves responsible of selecting the relevant documents.  Even if the initial search scope has stop words, the targeted documents will be found (because a super-set of the intended documents is searched)
• OTOH, a grep-like search might not automatically find "content  management" with double space between words
• In openoffice, the text is not found.  This is entirely acceptable behaviour IMHO.
• What about "<i>content</i> management"?
• in openoffice, this becomes "<i>replacement text</i>" (meaning the text is matched, and the style of the first character is applied to the replacement phrase)
• Advise would be to tackle this similar as a document task: preview, start, monitor progress, review run-through.
• Overlap/conflict with tag-based search (which would require yet another index). Needs more review.

Priority: high.

Remarks:

1. Searching: Fulltext searches live and not last versions, SERP task will search last version.
2. Locked documents will be skipped (this will be noted in the task monitoring page)
3. SERP will replace all matches in selected document.  For finer granularity users need to edit the document (a button will be available)
4. Similar tasks like spell check and acrocheck need to be taken into account so refactoring effort remains limited.

Screenshots / wireframes

Click to enlarge

• Querying: also see unified search (TODO: include link to unified search document), additional features may become added there.
• Case sensitivity checkbox: should this become a property of the querying section?
• 'Replace all' => marks that all instances of the search term should be replaced
• 'Skip all' => marks that the document should be skipped
• 'Edit' => indicate that more fine-grained control is wanted over what is replaced.  Takes user to editor in a popup window, after saving the last version of the document is displayed.
• (harder to implement) alternative: open in same window and return to search screen. After editing, the document can still show up in the list, but as it is already processed the user can select 'skip'
• 'My third document' no matches => quite pointless, could happen if we do case-sensitive filtering *after* the full text, but then these should be filtered out.
• If only non-daisy-html parts matched, the 'replace' selection is pointless and should be disabled (with explanatory text).
• Not shown in screenshot: document name matches, field matches.
• What if user wants more granularity: e.g. only replace in fields? => user should use 'edit' button.  If this is too much there is always the daisy-js scripting option (even though that is not something users will do).

Fields