frankmarion

@andrew Yes, I’m using the general blog platform, not my own standalone. @wpyogi You’re right. Thanks. Forgive the mislocated post. Feel free to close/delete this post.

It turns out that this has been mentioned in a couple of threads that weren’t so blatantly labelled. I believe that the devs are aware of this, and I seem to recall that they mentioned that they will be fixing this for the next update. We don’t have to worry, at some point, it should automagically (from our point of view) be fixed.

ABRACADABRABUGBEGONE.

First off, remove all but one of these.

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Unless you’ve done custom stuff and are very familiar with .htaccess, the only thing it should contain is one instance of the above. Once that is clean, you should be off to a fresh start.

Again, in your .htaccess file, make sure that this is wiped out

# BEGIN Hide Backend
# Rules to hide the dashboard
RewriteRule ^/wplogin/?$ /wp-login.php [QSA,L]
# END Hide Backend

To disable the plugin, find your plugins directory. You might have changed the name of the wp-content folder. Your plugins directory will be right next to your themes directory. Find the folder called better-wp-security and rename it something like XXX better-wp-security

Go to your wp-config.php file at the root of your installation and eliminate everything between

—
//Do not delete these. Doing so WILL break your site.
[Whatever you told ITSEC to put here when you were in the admin]
//The entry below were created by iThemes Security…
—

It should be at the very top of the wp-config.php page.

Or you can just comment out whatever lines are there. That should deactivate ITSEC and hopefully resolve some of your errors blarfing out.

Once that is done, you can re-install ITSEC, and choose the options carefully and knowingly, one at a time.

With familiarity, ITSEC is a joy to use, and one takes a perverse “F-U, hackers” pleasure every time one gets a report email.

You have apparently renamed your back-end login function. First thing, try /mydomain.com/wpadmin/ if that doesn’t work, look in your database.

Find the table named wp_options and the option name itsec_hide_backend. It will have a big ugly string of text. Look for the word “slug”. The next “real word” will be the word that you append after your url. It might look like anything that you’ve set or was set automatically by ITSEC. Mine often reads “wpadmin”. Some might change it to things like login, _login, _myadmin, or whatever you think you might have set it to.

To access the page go to https://yourdomain.com/whatever-the-slug-is-in-your-db

Hope this helps.

More, or less, yes. It is the simple process of elimination.

First, change to a default WP theme. Does that fix the issue? If yes, then something in your theme is messing with it. Sometimes the code we stick here and there, or in functions.php can conflict or mess with code that comes from a third-party plugin.

If changing themes doesn’t help, then turn to the plugins.

Turn all off but TWP. Does that fix it? No? Not a plugin conflict.

If it does fix it, the issue then is a plugin conflict.

Turn on the first half of all your plugins, turn off the latter 50%. Problem exists? It’s in the first 50%, otherwise, the latter 50%.

Take that 50%, wash, rinse, repeat until you find the one. Then figure out what this one plugin is doing that can affect http flow. Fix the plugin let the developer know, or find another alternative.

Hope this helps.

I’ve just re-discovered the cause of my own issue.

It is a conflict with another plugin. Specifically Better WordPress Security, and even more specifically, one of the rules that are inserted into the .htaccess file when one chooses to add the anti-hacking rules (Ban tab ? User and Bot Blocklist ? Add Host and Agent Blocklist ? [ ] Check this box to enable HackRepair.com’s blacklist feature.).

My fix was to remove the added .htaccess rules. I haven’t taken the time to figure out exactly which one it is, however. That would be a long and tedious testing process.

May I recommend to the developer, should they read these comments to include the above fact in their FAQ? I bet it would save a lot of headaches both in terms of support and for the general users.

Good luck, fine people.

I’ve experienced the same issue from the time I installed the plugin. Same user, same account. Loop backs limited to something like 10 per 60 seconds (GoDaddy). This is the third time that the plugin simply stops updating. I’ve tried clearing locks, activating and de-activating. I am updated to the latest version (2.6.0 at the time of writing).

It would be very helpful if the answer to this common problem were addressed in the FAQ. In the meantime, has anyone found a solution to this?

@mailworm

No, I’m sorry, I did not. I was in a rush to fix the issue, and simply turned it off.

Aaron D. Campbell, in point 2 of a previous comment in this thread said “2. Your server is limiting loopback calls. This basically means that your server is keeping your site from calling itself.”.

I called the hosting company, GoDaddy, to find out what their limit was. 10 hits per minute, that is, once per 6 seconds.

I then reasoned that it’s possible that BWPS might be limiting that, or, perhaps that TWP might attempting to access a file that is either (for some unknown reason) blocked or limited by BWPS.

As soon as I turned it off, her twitter feed updated. Since it solved the problem, and I have a reasonable amount of trust for the GoDaddy network, I left it off.

However, should Mr. Campbell discern a cause, based on these further observations and speculations, I’d like to know. I consider BWPS to be essential in most of my installs, and I might use TWP on another install at some point.

For those who may be searching to fix this issue in the future. I use Better WordPress Security, which is an excellent plugin, but the way that I had it configured was interfering with Twitter Widget Pro. It is neither’s fault, they are both doing what they should. Turn off, or tweak your settings with BWS, and you should find that you feeds update again.

Sorry, I was unclear: I do have c:\tmp set up in my .ini AND (just in case, because I don’t really know PHP; it’s my first time installed, and I haven’t developed using it yet) I have additionally set it up in the Windows path as my default tmp directory.

I appreciate that ftp is the way to go, but I’m a professional web-dev, and strange as it may seem, I’m tired of doing that dance. I was looking to WordPress as a solution to make my own website fun again, and ftp is a pain in the butt (comparatively speaking). I’ll do it if I must resort to it, but I’d rather take a shot at getting the issue fixed, first.

It would be nice to get it fixed for testing, but it’s possible that when I move it to my linux server that it might work as well.

I agree, that it seems like a PHP issue, not a wordpress one. c:\tmp exists indeed, and it’s part of my Windows PATH set up.

I (perhaps incorrectly) assume that Windows doesn’t really have a permissions issue if I’m the sole user. What could cause PHP to choke up on that?

Yes, they are both correct. Quintuple checked before posting ??

What this is telling you is that mysql is pointing to a folder that is non-existent, or that does not have the permissions to write to. The problem is not with WordPress, but with MySQL’s .ini pointing to the an inacessible location. See the MySQL documentation as a pointer.

https://dev.mysql.com/doc/mysql/en/temporary-files.html

Thank you for your help, time and attention. It’s a real kindness to dig in so deeply into another’s issues.

Yay! Solved. Thank Google! Please see the following post

https://www.ads-software.com/support/topic/42685

It actually wasn’t my fault. That’s good for the ego.