Michael

Caching was disabled. I don’t think it is a setting. It is most likely a bug in your plugin.

Did you try it with nested comments?

Yes, Preview in the settings works. As mentioned in my first post here, it also works for replies to the blog post. It just does not work for replies to comments. Did you test that?

The speed depends on the user’s connection speed. To test this, you have to simulate a slow connection.

The messaging you can test here: https://4sysops.com/archives/assign-an-ipv6-address-to-an-ec2-instance-and-configure-components-with-a-bash-script/

You’ll need to click the red Reply link of the test comment first.

Thanks for the reply. Before we proceed with this conversation, please measure Wordfence’s execution time with the Code Profiler plugin. Wordfence takes about 0.6 seconds to execute, which is equivalent to the execution time of all 50 of our other plugins combined.

Thanks for the reply.

The issue is that the wpmlemails table grows significantly over time. I have observed a table with 6,000,000 entries and a size of 2GB. This puts a substantial burden on the database system and slows down the entire system. It doesn’t make sense to retain information on individual newsletter emails that were sent many years ago if this leads to performance problems.

What about the Email Archiving feature? Isn’t it supposed to clear old entries from wpmlemails? I enabled this feature and set Archive Older Than to 365 days, but much older emails are still in the system and it had no effect on wpmlemails. wp-content/uploads/newsletters-lite/emailarchive.txt wasn’t created. I waited several hours.

Could you please clarify the purpose of the email archiving feature? Also, when does the archiving process take place?

Update: We cleaned our database by removing revisions, spam comments, orphaned records, and expired transients. Enabling database cache now only increases execution time by 10%. So, it seems the database size matters.

We are using a RAM disk for caching, hence slow storage is unlikely to be the cause of the issue. It appears that the code in Cache_File.php is responsible for the long execution time, with a duration of approximately 1 second. If we disable the database cache, the total execution time of all 50 plugins, including W3TC, is just 0.8 seconds.

After some investigation, we discovered that the database cache feature was causing the issue. Once we disabled it, the W3TC execution time became reasonable. While the database cache feature may reduce strain on the database system slightly, its negative impact on PHP execution is much greater. With the database cache disabled, the total execution time for a page load decreased by 30-40%.

Marko thanks for the reply!

Cache preload, statistics, and debuging are off.

According to Code Profiler the wp_hash function in w3-total-cache/Cache_File.php causes most of the CPU locad.

You might want to try this yourself.

It turned out to be a firewall issue. Sorry for bothering you with this.

Thanks for the reply. I posted here because we tested in a standard environment, which means that it is likely that many others will have the same problem and then come to the conclusion that the plugin does not work at all.

Sorry, my fault. We disabled check_is_protected before because WordPress admin was loading very slowly when it was enabled. It seems this problem no longer exists.

All good now.

Of course, I know it is a constant. What I am saying is that the bpges_log function is never executed. It’s weird that not even this works without any other plugins enabled. The only thing that really works is changing the settings.

The plugin never gets beyond autload_real.php when I post and activity update.

We have about 50 plugins that work fine, which means that your plugin must be doing something unusual.

Did you test with the latest WordPress and BuddyPress versions with PHP 8.x?

Turns out that not even BPGES_DEBUG is working. I tested without plugins with a WordPress theme. The corresponding function is never executed.

With Xdebug I see that bpges_send_queue is executed when I post in a group, but then the plugin does all kinds of things that are not related to sending emails. The emails are never sent.

I am curious what’s the purpose of ass_generate_notification. I don’t see any calls for this function.