Aaron D. Campbell

Ticket opened, the ID is 24504

Unfortunately, this isn’t “personal data” – this is something we’re seeing on many customers sites across our network. I’ll open a ticket to share what I can.

Weighing in as another WordPress host that’s seeing this. Not a lot to add that wasn’t already covered, other than to raise the issue that it’s not Pagely-specific (and getting subscribed here so we can push the fix out once it’s released).

@afflannery The simplest explanation here is that the Go style for setting the font size uses !important and the only way to override an important directive with another.

The line in question in the original css: https://github.com/godaddy-wordpress/go/blob/a41f3b6ab9dfe29f533cbf653527e3204227afa6/.dev/assets/shared/css/header/header__titles.css#L47

Hey @thecozyloft,

I’m not one of the developers on the theme in question but I saw this and I don’t think it’s likely to be theme-related. It seems like it’s probably something that went a little wrong when you imported your site form WordPress.com to to a www.ads-software.com install.

WordPress doesn’t actually count the number of comments on a post each time you ask for that number. Instead, it stores the comment count for each post in the posts table in the database and only updates it under certain conditions – for example, when a new comment is approved.

I see there’s a plugin that might fix it, but it looks to me like the plugin would count ALL comments not just APPROVED comments. There’s also an article by WPBeginner that shows how to make a script (copy/paste their code) to fix it.

Depending on how many posts you have, approving a comment for each would also be a way to fix it (even if you just added a new comment and then deleted it after)

Hope that helps!

There are several reasons:
1) The information needed is available, most reliably, directly from Twitter
2) A service that scrapes another service is prone to being shutdown.
3) The additional code that would need to be maintained to allow both Twitter API (authenticated) as well as Loklak (unauthenticated) wouldn’t be worth the added benefit of skipping authentication.

Hey, thanks for the interest. Unfortunately, this isn’t something I’m going to be adding any time soon.

@slavo7 – The banned users go into the .htaccess file (or nginx.conf if you run nginx) because anything else would cause the entire WordPress stack to load before we could block a user. That’s extremely memory intensive, especially when the site is user active attack. Blocking at the server level can help a site stay up during attacks like that.

Having said that, I have never seen someone’s .htaccess get that large from this feature. I just ran some tests, and I had to ban 7,000 IPs to get my .htaccess up to 1.6m (from the 4k is was at). Those were all individual IPs, banning ranges takes up far less space in the htaccess. Even so, my site continued to function normally even with an htaccess of that size.

Since IPs are re-issued to new people all the time, banned IPs should only be banned for a while, then cleared from the list. If you’re collecting in the neighborhood of 7,000 banned IPs there might be something else going wrong.

Hey @zcambler, thanks for reporting this. Unfortunately, we’ve been unable to reproduce this issue. Can you get us any relevant error logs or any additional data that might help?

@zcambler – I can assure you that we did a lot of testing on this release before ever pushing it out. That’s not to say that there aren’t any issues. We certainly aren’t perfect.

Having said that, if you aren’t getting the same error as the original poster, please make sure you open a new thread here, as this one will be marked as resolved shortly when that fix gets pushed live.

This id the error you should see in your logs if you’re having the same problem:
WordPress database error You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'SHOW_TABLES'

@dwindon Thanks for trying to help on this one. The truth is, I saw this thread last night (about 6 hours ago), and actually worked up a fix for it, but ended up going off to bed before replying here. The original post did in fact include enough information. We’ll put it through our QA testing, but it should be included in the next bugfix release.

Hey Jeff, we’re trying very hard to help the users of our plugin, and you were making it considerably more difficult to do so. So yes, I reminded you of the forum guidelines. I wasn’t trying to be rude to you, I was trying to be helpful to the original poster and anyone suffering from the same issue.

I do hope that you have good luck with whatever plugin you end up migrating to. I will say the the Sucuri products are particularly good; especially their Website Firewall (Sucuri Website Firewall)

Awesome! Let me know if there’s anything else we can help with.

Hey @bhammondcvl,
iThemes Security uses comments in the htaccess as delimiters and only writes content inside of those (essentially remove the content from open to close delimiter and then writing new, when the situation calls for it).

# BEGIN iThemes Security - Do not modify or remove this line
...
# END iThemes Security - Do not modify or remove this line

Make sure that both those lines are there just in case, and check for duplicated (I had someone the other day that had copy/pasted some things in their file and ended up with several of the “# BEGIN” tags and only one end tag, and it was messing things up — although not rewriting the WordPress rules)

@internalerror503 – Version 5.4.3 was just released specifically to fix this issue. Thanks again for reporting it.