Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
The search index can become massive on large sites, making it difficult to transfer the site to another server. Examples include migrating ISPs or just creating a test site. Yes, I know it would be better to not delete my entire search index, but its sheer size sometimes forces the need.
I would like the ability to clear the search index entirely. Searching through drupal.org suggests there is no supported way to do this.
Note that the reindex button does not clear the search index but rather gradually replaces existing search data with new data as items are reindexed.
Comment | File | Size | Author |
---|---|---|---|
#3 | jsomers_326062_1.patch | 1.33 KB | j.somers |
Comments
Comment #1
Anonymous (not verified) CreditAttribution: Anonymous commentedI too would like to see this feature. In my own site the search index is heading towards the 20MB mark so a substantial portion of the database
Comment #2
Yura Filimonov CreditAttribution: Yura Filimonov commentedI support this feature request: a huge esearch index makes it hard to upgrade to a newer version, because you need to backup the database, too, and my provider's PHPMyAdmin stalls, when attempting to backup the database.
If anyone tells me how to clear the search index in D5, it'd help, thanks.
Comment #3
j.somers CreditAttribution: j.somers commentedAttached is a very small patch which adds a Clear site index button next to the Re-index site button.
Considerations are:
Comment #4
Dave ReidThis will need a usability team review as it has been shown that testers had a huge difficulty just with the reset search index button, but now we're adding another one.
Comment #5
catchPatch should use db_truncate() now that's in.
I think I'd rather see a button on the maintenance page to 'clear all caches + search index' - it's a convenience to clear out rebuildable tables, not so much a search feature. That also gets it out of the way of search settings so people don't wipe indexes built up over several weeks just by hitting a button.
Comment #6
jhodgdonThis didn't make it to D7, obviously....
Comment #7
Cyberwolf CreditAttribution: Cyberwolf commentedSubscribing.
Comment #8
GarrathE CreditAttribution: GarrathE commentedI have to support the sentiment of the thread. The size of the index tables is a real obstruction to backups and recovery, such as the mentioned change of ISP, or in my case change of Domain Name.
Having a button to 'Reset Index' that clears all indexes and caches down before making a backup would greatly aid recovery. At the moment I have to spend ages going through the backup (when its successful) and delete all the dump entries to get the file down to a manageable size and avoid the 300s timeout that the 'search_dataset' always causes.
As someone on who has worked with that well known Redmond ECM product, this is just plain basic!
Comment #9
jhodgdonI'm sorry, we don't add new features to Drupal 6.x at this point, and even Drupal 7 is feature-frozen. So this has to stay in the Drupal 8.x issue queue.
Comment #10
udvranto CreditAttribution: udvranto commentedSubscribing.
Comment #11
udvranto CreditAttribution: udvranto commentedThe D6 equivalent:
and
Comment #12
bibo CreditAttribution: bibo commentedsubscribe
Comment #13
rkodrupal CreditAttribution: rkodrupal commentedsubscribe
Comment #14
rkodrupal CreditAttribution: rkodrupal commentedfyi you can get the same effect by disabling, uninstalling, and re-enabling the search module. not pretty, but it works.
Comment #15
michaelfavia CreditAttribution: michaelfavia commented@catch i assume you mean performance page?
What do you think about a selective cache clearing checkbox based form in there where we currently have "clear all caches". Letting modules group and clear their caches logically might be a nice touch for things like "Menu, Theme, Boost, Search, etc". It would also remove some of the ambiguity about which caches do what if we let them describe them, etc. Id be happy to patch this in if we can come up with a UX we like.
Comment #16
jhodgdonThe search index is not at all like the caches, IMO. The search index on a large site takes many cron runs to build up, and shouldn't be lumped with the caches -- if the search index is cleared, you can't get any search results until it's built up again, unlike caches, which are automatically built up as they are needed.
Comment #17
michaelfavia CreditAttribution: michaelfavia commented@jhodgdon I agree with your point about breaking the search while it is being rebuilt but also still have a need to actually remove it from time to time like major version upgrades where upgrading the search tables on large sites is a frustratingly long process.
Have any other suggestions to solve the problem? Are you proposing keeping it on that search page as its own action? I'm a big fan of configure/edit in place so this makes sense for me.
OTOH: A "cache center" that lets you check which caches to clear and provided descriptions of them might be very valuable to the average user: Image Styles, Page, Menu, Views, Search, etc
Maybe this is in addition to their edit in place functionality. Much like you can edit a node by clicking on it directly or viewing it in the aggregated list of the content overview. A nice mixture of edit in place and "group like tasks together" as they have different use cases but could use everythign except the same UI implementation.
Comment #18
jhodgdonI agree, we should have a button to wipe the search index. I don't see why you would need to do it due to a version upgrade, but I do know that there are rare reasons to want to do it.
I just don't think it belongs with the "cache" type of stuff, because it's a way different thing IMO, and should never be cleared unless something has gone very wrong with your site (unlike caches, which need to be cleared during development on a regular basis). Clearing the search index is just not for the casual user.
And as I said before, it's not a cache, in the sense of temporary stuff that is stored for efficiency purposes. It's an index that you absolutely need to have fully built to run searches.
Comment #19
Bojhan CreditAttribution: Bojhan commentedno image to review
Comment #20
jhodgdonSince 8.0.x-beta1 has been released, our policy at this point is No feature requests until 8.1.x. See #2350615: [policy, no patch] What changes can be accepted during the Drupal 8 beta phase?. Sorry, it's just too late for 8.0.x at this point, so even if we had a viable patch, the core committers would not commit it. So unless we decide this is a Task or a Bug (and I don't think it is), we'll have to delay it.
Comment #21
Sagar Ramgade CreditAttribution: Sagar Ramgade commentedHi,
I had contributed it as a module called Search index wipe for D7, will come up with D8 also soon.
Comment #23
walwyn CreditAttribution: walwyn commented@udvranto thanks for #11. Preparing to upgrade from D6 to D7 and wanted to do a few test upgrades before doing it to the live site. Problem was that copying (restoring) the database failed when restoring the search tables. Clearing the search tables and the database restore complets and I have a duplicate database I can work with on the tests. Though I could have just stripped it out from the backup, this was far quicker.