This search for insource:"flowlist" insource:/[^\{d\|]flowlist/ -contentmodel:css doesn't exclude css contentmodel pages. (The opposite insource:"flowlist" insource:/[^\{d\|]flowlist/ contentmodel:css also does not seem to restrict results solely to css pages.)
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T147505 [tracking] CirrusSearch: what is updated during re-indexing | |||
| Declined | None | T200516 Re-index all pages on all wikis (insource and contentmodel don't play well together) | |||
| Resolved | EBernhardson | T203622 Upgrade saneitizer to constantly re-index documents |
Event Timeline
Comment Actions
This currently returns 19 results - looks like we just need to re-index everywhere to capture the other files. This will take quite a bit of time to do (all wiki pages in all wiki's) so, we'll have to plan for this.
Comment Actions
Will a reindex actually fix the problem reported though? It's a case of "contentmodel pages of a certain kind (CSS in this case) are not being appropriately included/excluded where they should be, at least when I use insource".
For example, this page shows up in the query. Why? It has always had a css content model (well, at least since content models were rolled out, I would guess), in the 6 years the page has existed. I would have guessed a previous index would have caught that....
Comment Actions
In the six years it has existed it has never been edited. So that means our search index has the latest document as of 2012. When content model wasn't a property of the search documents.
Comment Actions
Rather than run a manual reindex i have put together T203622 and submitted a patch which will constantly reindex everything on a rolling 8 week cycle. This removes the need for anything to be done manually now, and in the future these problems will fix themselves within a known time frame.