dwinden
Forum Replies Created
-
Yes, removing the default value “not_found” from the Redirection Slug setting will redirect users attempting to access “wp-admin” or “wp-login.php” (while not logged in) to the homepage.
Just make sure the Enable Redirection checkbox is ticked.
However users attempting to access “admin”, “login” or “dashboard” will still receive a 404.
If the info provided above answers your question please mark this topic as ‘resolved’.
dwinden
Appreciate your input but this topic is about the iTSec plugin Hide Backend feature NOT blocking the WordPress non default wp-login slug.
Anyway I’ll repeat what I said before. This is an Apache web server configuration issue. Look for a solution there.
dwinden
This issue is caused by an error in the French translation files.
” taken” is translated as “pris” but it should be ” pris”.
Also, this was already an issue in pre 5.4.x releases.
dwinden
You may have a point there.
Currently the iTSec plugin Hide Backend code is only written to block the regular WordPress Dashboard access slugs. These include:
- wp-admin
- dashboard
- admin
- wp-login.php
- login
dwinden
If you deactivate the iTSec plugin you will find the wp-login slug still works. Which is strange because wp-login is not an official WordPress slug for accessing the WordPress Dashboard login screen.
In other words this is not an iTSec plugin issue.
It’s an Apache web server configuration issue …
dwinden
You might be able to get a more usefull (php) error when temporarily setting the WP_DEBUG constant to true in the wp-config.php file.
Or check the web server error_log for any errors.
dwinden
In the iTSec plugin release prior to 5.4.x on line 267 of the class-itsec-core.php file indeed a require of the class-itsec-global-settings.php file was executed.
However this is no longer the case since 5.4.x.
So it looks to me there are mixed version files in your current iTSec plugin install. Or there may be a caching problem.
Manually delete the better-wp-security folder and then FTP the 5.4.5 ZIP file and unzip it.
Also I don’t think this is nginx specific.
dwinden
The answer to your question is probably in this topic.
If so please mark this topic as ‘resolved’.
dwinden
@gµårÐïåñ
It wasn’t a comment. And it certainly wasn’t trollish. Perhaps it was you interpreting it as trollish… Anyway sentences that end with a question mark are commonly referred to as questions. Based on the symptoms you described in your initial post there was a very good reason for asking that question … I was only trying to help.
Too much negativity in this topic … Unsubscribed 😉
dwinden
+1 😉
I noticed Aaron’s message about a bugfix release which will deal with this issue shortly.
Just wanted to add that the SQL error is not added to the error.log as a result of clicking on any Save Settings button. It’s a Database Backup rendering bug due to a typo …
Just clicking on the Security (or Settings) menu option for instance will add the SQL error to the error.log. And once on the plugin Settings page, first clicking on the View Logs button and then clicking on the resulting Manage Settings button to return to the Settings page will also generate the SQL error in the error.log.Even though you don’t see it, all the html markup for all the Configure Settings popups is already generated when arriving on the Settings page. It is just hidden. Javascript driven, clicking on any feature’s Configure Settings button will unhide the relevant html markup that was already there (but hidden).
Note the SQL error is not generated when the Database Backup Backup Full Database setting is disabled.
Time to shut up (me) 😉
dwinden
Thank you for that summary.
I’ve got good news and bad news.
Let’s start with the good news. I was able to reproduce the error. Yihaa!The bad news is I’ve run out of time. I have some other activities on the agenda.
So will have a closer look at this later on. Probably this evening.dwinden
People often have more information than they think.
For instance, we now know it seems to be an isolated issue on 1 site.
We now know the error occurs when clicking on ANY Save Settings button.
Also we learned that you seem to be getting the error added to the error.log. Does that mean that there is no error displayed on screen ?
We also know you didn’t change anything in the settings since this new version 5.4 (Though clicking on a Save Settings button implies saving something that got changed …).
So that’s pretty usefull information.
Edit: Oops, I missed your last post. So bear with me.
dwinden