Just installed, it's re-indexed everything fine and is working great now.
Many thanks for the fast turn around.
Overall a great product, but I've found one issue that is affecting us.
We have a process where we remove large numbers of posts and reimport them from a different system.
Since the rewrite of the indexing system, if I go to the Posts screen in the admin area, select a pages worth (i.e. 20 of them). Then from the "Bulk Actions" move them to the Bin (Trash), it will take a good 20 seconds to finish the operation. With larger posts it can be a lot longer than that.
Then going to the Bin and Emptying it, will take even longer. From what I can tell from doing some profiling with xdebug, it's calling curl to do a reindex for every save_post. Which seems fair enough.
To speed things up, I thought we could uncheck the "Auto-index" box in the WP FullText Search Options screen. But unchecking that and saving, or unchecking the "Enable FullText Search" and saving, it still does the curl request and is noticeably slow.
If I deactivate the plugin, then normal processing times return and the bulk operations resume at normal sub 1 second speeds.
This is equally true for importing new posts, or creating them with wp cli.
My work around for the moment, is to deactivate the plugin before I do any bulk delete/creation operations, then do them, then reactivate the plugin, and go to the control panel, then pause and resume indexing and it seems to catch up (usually quite fast!).
Would it be possible to put some sort of functionality in, where a save_post call doesn't block it's completion until it's been indexed, or a option put into the control panel where you could allow for it to asynchronously index posts rather than intercepting every single post save?
Also the unchecking of "Auto-index" option, still seems to leave some of the intercepting of post saving enabled!
Unsurprisingly it was asking to rebuild the index, so I clicked the rebuilt button, but it never completed.
Doing a bit of detective work, it seems to be, where it drops all the tables, then recreates them I'm getting the following:
[12-Aug-2020 13:38:08 UTC] WordPress database error Specified key was too long; max key length is 767 bytes for query CREATE TABLE
id int(10) unsigned NOT NULL auto_increment,
tid bigint(10) unsigned NOT NULL,
tsrc varchar(255) NOT NULL,
tdt datetime NOT NULL default '1970-01-01 00:00:00',
build_time int(11) NOT NULL default '0',
update_dt datetime NOT NULL default '1970-01-01 00:00:00',
force_rebuild tinyint(4) NOT NULL default '0',
locked_dt datetime NOT NULL default '1970-01-01 00:00:00',
PRIMARY KEY (
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci made by do_action('wp_ajax_wpftsi_submit_rebuild'), WP_Hook->do_action, WP_Hook->apply_filters, WPFTS_Core->ajax_submit_rebuild, WPFTS_Index->create_db_tables
Talks about making sure indexes are the less that 191 long. Is there a way out of this, other than going back to the old version?!