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.

CommentFileSizeAuthor
#3 jsomers_326062_1.patch1.33 KBj.somers
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Anonymous’s picture

I 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

Yura Filimonov’s picture

I 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.

j.somers’s picture

Status: Active » Needs review
FileSize
1.33 KB

Attached is a very small patch which adds a Clear site index button next to the Re-index site button.

Considerations are:

  • Placement of the button.
  • Creation of a hook. Since other modules are allowed to implement hooks on the search functionality it is likely they will need to clear certain tables or other data themselves when the site index is cleared.
Dave Reid’s picture

Issue tags: +Needs usability review

This 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.

catch’s picture

Status: Needs review » Needs work

Patch 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.

jhodgdon’s picture

Version: 7.x-dev » 8.x-dev

This didn't make it to D7, obviously....

Cyberwolf’s picture

Subscribing.

GarrathE’s picture

Version: 8.x-dev » 6.9

I 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!

jhodgdon’s picture

Version: 6.9 » 8.x-dev

I'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.

udvranto’s picture

Subscribing.

udvranto’s picture

The D6 equivalent:

  $form['status']['wipe'] = array('#type' => 'submit', '#value' => t('Re-index site'));
  $form['status']['clear'] = array('#type' => 'submit', '#value' => t('Clear site index'), '#submit' => array('search_admin_clear'));

and

/**
 * Submit callback; clear site index.
 *
 * @ingroup form
 */
function search_admin_clear(&$form_state, $form) {
  db_query("TRUNCATE TABLE {search_dataset}");
  db_query("TRUNCATE TABLE {search_index}");
  db_query("TRUNCATE TABLE {search_node_links}");
  db_query("TRUNCATE TABLE {search_total}");

  drupal_set_message(t('Cleared site index.'));
}
bibo’s picture

subscribe

rkodrupal’s picture

subscribe

rkodrupal’s picture

fyi you can get the same effect by disabling, uninstalling, and re-enabling the search module. not pretty, but it works.

michaelfavia’s picture

@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.

jhodgdon’s picture

The 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.

michaelfavia’s picture

@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.

jhodgdon’s picture

I 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.

Bojhan’s picture

Issue tags: -Needs usability review

no image to review

jhodgdon’s picture

Version: 8.0.x-dev » 8.1.x-dev
Issue summary: View changes

Since 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.

Sagar Ramgade’s picture

Hi,

I had contributed it as a module called Search index wipe for D7, will come up with D8 also soon.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

walwyn’s picture

@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.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.