OllieJones

Hello again, Ed Krasnov.

About php 7.4, it looks to me like your command-line php is set to 7.4. That is a different setting from the php used by your web server. Try this if you are on a recent Linux release. It will prompt you to choose the php release you want your command line to use.

sudo update-alternatives --config php

Those messages from wp index-mysql announce that it took “2 MySQL statements” to perform the reindexing operation. It’s just telling you two statements.

I can’t guess from here in a forest in Maine USA what went wrong with your site. ?? If you upload your metadata I will take a look if you wish.

This plugin only touches database keys. By design and many years of debugging, database management systems allow keys to be changed without disrupting software operations. Quoting from the plugin’s readme.txt file:

Database management systems are designed to have their keys updated, adjusted, and tweaked as their tables grow. They’re designed to allow the keys to evolve without changing the content of the underlying tables. In organizations with large databases adding, dropping, or altering keys doesn’t change the underlying data. It is a routine maintenance task in many data centers. If changing keys caused databases to lose data, the MySQL and MariaDB developers would hear howling not just from you and me, but from many heavyweight users. (You should still back up your WordPress instance of course.)

https://www.ads-software.com/plugins/index-wp-mysql-for-speed/

I don’t think the plugin disrupts operations. It’s been out there for years now.

Measuring effectiveness? The monitor feature in the plugin has the purpose of doing that.

Thanks for your patience as you implement this stuff.

Thanks for following up. I do that all the time with wp-cli. I’m trying to figure out how to make the plugin less sensitive to that.

Thanks for the upload!

You have used the plugin correctly to create your high-speed keys. Looks good!

A suggestion: your MariaDB 10.4 database server has 8GiB of RAM allocated to innodb_buffer_pool_size. It is running about 98.7% full. If you can change its size to 12GiB I think you are likely to see an improvement in performance. You can edit it into /etc/mysql/mariadb.conf.d/50-server.cnf and then restart your MariaDB server to do that.

Do you have access to wp-cli, or to phpmyadmin? If so, try giving this SQL command:

ALTER TABLE wp_postmeta DROP KEY meta_id;

With wp_cli, you’ll do it with

wp db query "ALTER TABLE wp_postmeta DROP KEY meta_id;"

And please upload your metadata again from Tools > Index MySQL > About so I can see if anything has changed.

Thanks for your patience.

Thanks for your questions.

This plugin does nothing at all with the wp_litespeed_avatar table (and with almost all other plugin-created tables). That table doesn’t feature in the free version of the Litespeed optimization plugin I use, so I don’t have access to its definition. Plus, it’s outside the intended scope of this plugin. So I can’t help you there.

About wp_postmeta and your sites. Please let me know if your WordPress installation is configured for multisite operation. https://dev.mysql.com/doc/refman/8.0/en/group-by-handling.html Because the answer may be more complex in that case.

The plugin’s wp-cli command only affects one site at a time, whether you’re on multisite or not.

So, you should be able to do something like this (if you’re hosted on Linux or some such) to add the high performance keys to wp_postmeta.

cd /var/www/giport.ru
wp index-mysql enable wp_postmeta

Please folow up if I can help you further.

I haven’t heard back from you so I’m closing this support topic. Please don’t hesitate to open another one if I can help you further. Do upload your diagnostic data and let me know the upload id, if you do open another topic.

Thanks.

That error message at the top? Something is awry in the post taxonomies (tags, categories, all that) department of your plugin collection. I wish I could tell you more, but for me this one is vuja de (“never seen that before”). This isn’t related to users.

https://developer.www.ads-software.com/reference/classes/wp_post_type/register_taxonomies/

The options you showed tell me: none of this plugin’s indexing operations, which run in the background in WordPress cron, have completed. It’s possible this line 763 error, or something else, is hosing them.

Thanks for trying! I’ll leave this open for a while in hopes you find time to try again.

One more bit of troubleshooting data you could show me, if you have time: the output of

wp option list --search="*index-wp-users*"

Thanks!

Thanks for the defect report, and thanks for your patience trying to find a workaround.

Here are the changes, on GitHub. https://github.com/OllieJones/index-wp-users-for-speed/compare/1.1.6…1.1.9

If you enable WP_DEBUG and WP_DEBUG_LOG do you get anything in your …/wp-content/debug.log file? It would help me track this down if you can let me know about this.

The autocomplete menus don’t work until the indexing is complete. It’s possible the indexing got stuck somewhere.

A few things changed.

I switched from using transients to using options to keep track of partially completed indexing. (Transients were causing problems when persistent object caches were in use.) You could try deleting and reinstalling the plugin, that should clear out all the options and transients.

I changed the autocomplete code to show both the user display name and login. The way things work, that requires a REST operation (to get the login name). If you open up your browser devtools and look at the Network tab, you may see an error if that is failing.

I changed the SQL code doing the indexing to use transactions to avoid database deadlocks on busy databases. If that change is causing you problems, it should show up in your debug.log.

Version 1.1.9 contains the fix. Sorry for the trouble.

Dang! Sorry, folks. I’m on it.

This is embarrassing. Stupid typo. Forgot to test in the cron-disabled scenario. Blush.

I just released v 1.1.8 with, hopefully, some database deadlock protection in it.

I hope it works for you!

Ah, thanks for your kindness trying that. Deadlock, huh? I bet your site is quite busy!

I’m going to push out a new version of the plugin with some transaction management in it, and some restarting capability. I’ll let you know.

Weird. If you still have the patience for this, please try deactivating the plugin.

Then, if you’re willing, try editing .../wp-content/plugins/index-wp-users-for-speed/index-wp-users-for-speed.php.

Look for this line

const INDEX_WP_USERS_FOR_SPEED_BATCHSIZE = 5000;

and change 5000 to 1000.

Then reactivate it. Maybe that will help. Thanks again for working with me on this.