Last modified: 2012-07-24 08:34:36 UTC
To move content from an old wiki to a new one, I performed an XML export from the old wiki and imported it into the new one. Attempting to search for the pages I had imported turned up nothing, even though they were accessible normally. Diving into the database I determined that the XML import had put the content into the page table, but not the searchindex table which the wiki uses for searches. Going to each page and making a minor edit would put the page into the index and make it searchable.
Use the maintenance script updateSearchIndex.php . Something like: php maintenance/updateSearchIndex.php -s 200701091800000000
For the import script, users need to run the search index rebuild scripts after importing. For regular Special:Import, the issue should be fixed in a newer release.
I ran the script a few different ways, even trying -s 20060101000000, but the pages still aren't being indexed. Is there anywhere I can RTFM on this? The searchindex table only has three rows in it, Current Events, Main Page, and the page I touched to make the wiki index it. Looking in the maintenance dir I found rebuildtextindex.php. THe source looks like it would do the trick, but it doesn't include the variables containing the db connection info. Time to do some PHP hacking I guess.
(In reply to comment #2) > For the import script, users need to run the search index rebuild scripts after > importing. For regular Special:Import, the issue should be fixed in a newer release. Which revision that it is fixed?
(In reply to comment #4) > (In reply to comment #2) > > For the import script, users need to run the search index rebuild scripts after > > importing. For regular Special:Import, the issue should be fixed in a newer release. > > Which revision that it is fixed? > http://svn.wikimedia.org/viewvc/mediawiki/trunk/?view=log&log_pagestart=37700 <-- as I found no revision mention about this bug, I then reopen the bug.
http://svn.wikimedia.org/viewvc/mediawiki/trunk/?view=log&pathrev=19034 <-- as I found no revision mention about this bug, I then reopen the bug.
Tested on my MW installation (1.19) works just fine.
