pete3
Forum Replies Created
-
Hi Jeremy,
Thanks for replying. It looks like it’s solved for me by disabling Link Genius. If I need more help I’ll contact support.
I think your developers should test this on a large site, e.g. 50k+ posts, and make sure the process runs slowly and does not drain server resources.
I had a similar issue with Link Genius. It took the CPU of my beefy server to 100% occupied, and I could not even access the WordPress backend anymore. Had to delete records from the wp_options table to stop the whole process and access the backend again. Then I disabled the Link Genius module to hopefully prevent this forever.
This feature is way too heavy for large websites! Please make these things safer. It does not need to be fast, it just needs to be smooth.
For anyone else reading this: I found that the InnoDB database engine keeps a lot of allocated free space by default, for the best performance. The SQL OPTIMIZE command will not work. If executed manually it will perform an alternative optimization which does make the table smaller. There’s also a WordPress optimization tool that needs to be executed manually and should work for InnoDB: https://wp-mix.com/wordpress-repair-optimize-innodb/. I did not try that.
However, the hosting support says that the allocated “free space” is only a problem if we need the disk space, but it’s not a performance issue. For now, I will install the CleanTalk fix, but take no further action to shrink the tables. Apparently, it’s normal behavior for InnoDB to allocate space for millions of records!
Thanks for the assistance.
Forum: Fixing WordPress
In reply to: WordPress Block Editor freezes if page contains patternThanks a lot James. I found this bug https://github.com/WordPress/gutenberg/pull/66945 that was fixed in 6.7.1. So, on a staging site I tried adding a category to one of my patterns, because none of them have a category. That solved it for 6.6.2. Next, I updated to 6.7.1 and that solved it for other patterns too.
So, I’ll go ahead and add a category to all patterns on the live site. That prevents me from updating, although the risk in this case is minimal probably.
We have update cycles on purpose. We update WordPress along with the theme and all plugins on staging, test thoroughly, and only then update the live site. There’s no other way unfortunately, because of new bugs/features/incompatibilities introduced with new versions. So, no auto-updates for us. I’m glad this could be solved without updating.
Thanks again!
- This reply was modified 1 year, 6 months ago by pete3.
I don’t want to put the domain here but the service # is 549735. The staging subdomain is “stg”.
Hi @katereji,
I checked again:
Data length: 175,112,192 > 162,971,648 > 139,755,520
Index length: 0 > 0 > 0
Data free: 4,194,304 > 19,922,944 > 42,991,616
Auto-increment: 0 > 0 > 0
Rows: ~1,261,431 > ~1,115,578 > ~ 944,954Note that this is on the staging site with almost no traffic. It looks like the number of rows decreased but it’s still a lot, and the “free space” increased so the table size is still big on disk, I guess.
Kind regards,
Arno
Thanks @eugenecleantalk. I installed it on the staging just now. I’ll check back in 24+ hours and let you know.
By the way, what do you think about all that “free space” that is left in tables after deleting data? Is that a problem or common practice? Is saw some tables from other plugins with the same issue. It seems like a waste of disk space.
It’s about 38 hours later now. I checked the table values in the Database Manager before and after installing the update:
Data length: 175,112,192 > 162,971,648
Index length: 0 > 0
Data free: 4,194,304 > 19,922,944
Auto-increment: 0 > 0
Rows: ~1,261,431 > ~1,115,578This is on the staging site that gets almost no visitors. It seems like a bit of data was deleted from the table, but I would expect it to remove much more. It looks like it didn’t release disk space (“data free” increased a lot), so the table is still big.
What do you think?
Wow, that was fast, thanks a lot! I installed it on our staging site. I will check tomorrow if the table will shrink.
Set Cookies is at “Off” in our case, and I didn’t change it.
Thanks. So far so good.
Hi @serge00,
Thanks, I added the exclusion like this: https://www.example.com/?fluentcrm=1&route=unsubscribe
I will keep an eye on it.
I can indeed see all blocked attempts in the log but I won’t whitelist them because these people will very likely not come back anyway. But I was able to click the URLs in the log and unsubscribe them myself that way.
Thank you @eugenecleantalk,
Yes, version 6.20 is installed. I now changed the Cookies setting and tried again to create an account with the test e-mail address. But again the same console error and no frontend message.
By the way, if I am not on the page to create an account, but on any other page, I get this in the browser console: “Uncaught ReferenceError: ctPublicFunctions is not defined” at /wp-content/plugins/cleantalk-spam-protect/js/apbct-public-bundle.min.js?ver=6.20
Would it be useful to send you the URL so you can see it yourself? (not here in the public forum though).
Can I set the frontend message and customize it? If account and forum posts are blocked completely, I’d like the legit users to understand that they can contact us in case if false positives.
I’m using both the Free and Premium licenses on various websites. Both work fine. The free version works without paying anything.
Forum: Plugins
In reply to: [Temporary Login Without Password] jQuery not defined if plugin is activatedUpdate for anyone else who has this issue: the problem has been identified and will be fixed in a next release.
Thanks Asmi!
Forum: Plugins
In reply to: [Temporary Login Without Password] jQuery not defined if plugin is activatedHi Asmi,
Thanks for looking into this. I have a test site with the default 2022 theme and all plugins deactivated. When I activate your plugin, I get the jQuery error on the plugins page of WordPress.
On further testing, I found that MonsterInsights has the same problem.
If I activate both plugins, I get the error twice:
plugins.php:214 Uncaught ReferenceError: jQuery is not defined at plugins.php:214:5 (anonymous) @ plugins.php:214 plugins.php:358 Uncaught ReferenceError: jQuery is not defined at plugins.php:358:4You can log into my test site if you’re interested.