WhitG

Okay, thanks for that last suggestion, what I had meant by “Disabling all plugins” in the first post was that I had disabled all but MMM, but I have now tried disabling *only* MMM and the problem is still there, so that turns out not to be the culprit after all (apparently no plugin is, it’s still there with none of them active, I guess it must be a theme issue). Thanks for the assistance!

Thanks Tom, but I’m afraid that assessment can’t be right — maybe you missed me mentioning that I turned ALL plugins off except for MMM and the issue was still present. :/

Ah, interesting, and also very strange – it’s only the sites that happen to have your plugin (of several dozen that I manage) that have this problem. But it’s also true that those particular sites have several other plugins in common, so perhaps one of those is conflicting with the WP core and causing the constant emails. I’ll just turn off email notifications, I guess.

Ah, now I can get the token, and the feed is working again! Thanks!

Ugh, I’m having some trouble here, I’m afraid. Like the others I’m getting the “(#4) Application request limit reached” error:
https://www.pavefinejewelry.com

…but I can’t seem to get a token working. Whenever I click the “login” button, I grant it access to the FB account and then I get a white screen with “You’re not allowed to do that.” Help!

Allow me! ??

I appreciate the idea, but in this case we can do without the EAE plugin, there’s only one email address on the site and I’ve manually encoded it. ?? I was mainly wanting to let you/everyone know that this is a potential issue, in case someone else runs into the problem. I’ll certainly continue to use your plugin elsewhere, though!

Yes, sorry, I should have clarified that. If I have EAE turned on but comment out the form (no need to disabled the actual plugin), the site loads just fine.

I was in the middle of writing such a message when I decided to start toggling plugins and found EAE to be the culprit.

Thanks for the response. I also have further updates, and they’re a mixed bag, but mostly point to the fault landing on me. I’ll outline some of it here for posterity…

I’m not totally clear on what the above .htaccess code does, but A) I did find another thread that involved that specific code but didn’t make clear if it’s helping or hurting; and B) it now seems evident, based on the specific WP installs that were causing the autoSSL problem (not current, for a reason), that an older version of the iTS was the culprit. Sooooo… it’s kind of hard for me to blame iThemes for the fact that I have to shovel out ~$300 in web-dev fixes for an issue that they already solved but can’t be implemented on old WP installs.

Again, for posterity: the specific issue, as outlined by the developer who fixed the issue, is that Comodo was being added to the blacklist within .htaccess, like so…

	# BEGIN Ban Users
		# Begin HackRepair.com Blacklist
		RewriteEngine on
...
		RewriteCond %{HTTP_USER_AGENT} ^comodo [NC,OR]

I’m omitting the lengthy list of other blacklisted servers. iThemes already knows about this issue, obviously, and have (fingers crossed!) fixed it in current versions of the iTS plugin, and we have removed the offending lines from the .htaccess files of the older WP installs (those sites are currently being redeveloped, so there was no reason to risk breaking them by updating their WP bases, and iTS can’t update to the current version because of that situation).

So mystery solved on my end, and no need to disable the blacklist feature in our case (since this issue isn’t likely to cause problems before the offending sites are rebuilt).

Hey @mywebmaestro, do you have any further info on this issue? One of my contractors had to deal with it while I was on vacation. We’re seeing this block in some of our hosted WP sites’ .htaccess files…

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_URI} !^/[0-9]+\..+\.cpaneldcv$
RewriteCond %{REQUEST_URI} !^/[A-F0-9]{32}\.txt(?:\ Comodo\ DCV)?$
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !^/[0-9]+\..+\.cpaneldcv$
RewriteCond %{REQUEST_URI} !^/[A-F0-9]{32}\.txt(?:\ Comodo\ DCV)?$
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

I don’t yet know if that specifically came from iThemes Security and not some other plugin, but it seems like the most likely culprit, and we do use it on all of our sites.

Oh, that’s interesting – I’ll give that a try! But yeah, a more explicit option in the settings would be great, thanks.

Sorry, another self follow-up, since my above answer wasn’t fully complete and didn’t include the solution: the wp-config file still had references to the old domain and username, I just had to update those to fix the issues.

Self follow-up: My particular problem was that I was using a custom WP content directory setup, and that wasn’t getting updated by Duplicator. It was therefore trying to reach back to the original server that it was previously installed on, and failing because the FTP credentials didn’t match.

I hate to resurrect this thread, but I have a similar problem wherein wpodeskstar’s solution isn’t applicable. I just duped a site and am being asked for FTP credentials when I try to update the theme or plugins, and even when I input those credentials, it still doesn’t update them. The permissions appear to be correct (755 for the plugins folder and each plugin; 644 for individual files) and the user/group also appear to be correct. Any idea what could be happening here?