WPOrg User 300300

Resolved it by my own further investigation. Turned out to be a peculiar revision management glitch in the database prefix change.

Clarification: evidently was not due to Translations update…

Resolved that one (aforementioned issue with WP install/re-install).

Still *appears* to be the port number involved in causing the connection failure for the DB Prefix rename.

Resolved it by my own further investigation. Turned out to be a peculiar revision management glitch in the database prefix change.

Shortly after renaming database prefix, the entire WP installation wants to re-install itself from scratch. The WP Installer comes up instead of admin dashboard. The other action I took was to update WP translations — maybe that other step is at fault. I’m checking into that issue, now ??

Ok, I did a little bit more investigation myself.

I can tell you with an increased amount of confidence that the port number is involved in tripping up this code: I tried an installation without port number and the same code evidenced working as expected; with port number included the feature failed.

…
Come to think of it, if those connection parameters were bad I suppose the entire WordPress would come crashing down wouldn’t it? Since users, pages, posts etc., are in the database…

This makes me wonder even more about why the failure in the rename prefix feature.

Hi and thank you for your reply.

It did not make sense to me that DB_HOST would be undefined because the error message there in my original post is Unknown MySQL server host ‘localhost:3306’.

So I went back and checked the configuration and there ***is*** a DB_HOST defined on the server and it’s what you might expect:

define('DB_HOST', 'localhost:3306');

I will try to contact the hosting provider but I can say it does look to be defined in the WP installation. And there are those issues with File Permissions too. You have so many wonderful features with lots of work into this plug-in, I wonder if a little configuration check page added into the AOIWP would help shine the light onto installation issues and lower the support burden.

If you have any more clues about this issue please let me know. I will be contacting ISP meantime. Thank you!

BTW I’m also trying Contact Form 7. That has been the very latest effort and long-time after trying Login Lockdown.
I’m using a third-party theme from a design house that sells themes, although it didn’t appear to be something that you asked about.
Out of possibly excessive sensitivity to security I’ve been reluctant to mention the commercial hosting company I use.

Incidentally I see very short-lived error 500’s very occasionally with various WordPress functions and in those cases a page-reload resolves the issue (which makes me wonder if there is a performance/response time causality to those).

In case of Login Lockdown any access to the login pages was flat-out dead in its tracks: reloading/retrying pages was of no help.

Login Lockdown was the first plug-in installed.

After removing it I switched to All In One WP Security & Firewall which works GREAT with exception of minor difficulty I have with file-permissions function. So far I put All In One WP Security & Firewall at about 98%-99% of full functioning.

I also have added Jetpack and Google Analytics.

I’m sure all of those were coming after Login Lockdown.

By the way, all the other settings I’ve tried have been responsive and seemed to work immediately.

Also since the confirmation message always names the SAME file (wp-config.php) it started me thinking there *might* be a problem with how the buttons were coded i.e. always hitting the same file (?).

Thanks for your reply.

It’s a Windows Server. There’s no caching (single-purpose) plugin installed although Jetpack is installed and does have so much “stuff” that conceivably it could include such and I would have overlooked it…

Jetpack is so common, though, that I imagine you’ve come in contact with that one plenty and I suppose you’d probably have gotten wind of compatibility issues by now.

I’ll check the post and try some process-of-elimination next time I get a chance. Thanks again.

Here’s why I have perceived that the buttons are not having the intended effect:

(1) The display of actual file permissions in the plugin does NOT change. The files still have the same permission on them after pressing “Set Recommended Permissions” (even after repeated clicks.)

(2) The security score for file permissions security does not change after pressing “Set Recommended Permissions.” I would gather if the plugin was successful to update permissions, the score would change (increase).

(3) The feedback message about successfully changing permissions always indicates the SAME filename (specifically “wp-config.php”) regardless of the fact that the “Set Recommended Permissions” button was pushed for a different file.

(4) I can leave the plugin and go back into it, and the file permissions are all the same as when I started…. the same before and after pressing “Set Recommended Permissions” buttons.

Thanks!

No, the plugin is installed into WP running a server which is commercially hosted.