ruperte

ruperte

Hi,

Just installed, it's re-indexed everything fine and is working great now.

Many thanks for the fast turn around.

Rupert

ruperte

Hi,

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!

Many thanks.

Rupert

ruperte

Hi,

Just installed, it's re-indexed everything fine and is working great now.

Many thanks for the fast turn around.

Rupert

ruperte

Hi,

A fantastic plugin. I've just updated from (I think) a version 1.1 of the plugin, to the latest 1.32.90 - along with updating to WP 5.5

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 wpftsi_index (
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 (id),
UNIQUE KEY tid_tsrc_unique (tid,tsrc),
KEY tid (tid),
KEY build_time (build_time),
KEY force_rebuild (force_rebuild),
KEY locked_dt (locked_dt),
KEY tsrc (tsrc)
) 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

select VERSION();
returns:
10.1.45-MariaDB-0+deb9u1

So for now I'm stuck. I think the problem, is utf8mb4 doesn't seem to allow an index longer than 191 characters when using utf8mb4

https://make.wordpress.org/core/2015/04/02/the-utf8mb4-upgrade/

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

Many thanks.

Rupert

ruperte

@ruperte

Best posts made by ruperte

Latest posts made by ruperte