dwinden
Forum Replies Created
-
No, I’ve tried to find out in the past (you are not the first person hitting this issue). It’s a mystery where the extra wp-login slug comes from.
Is this a manual WP download/install or was WP installed as an App from your hosting provider cPanel env ? Perhaps you should talk with your hosting provider.
dwinden
@css1
wp-login is not an official WP Dashboard login slug.
Enabling the iTSec plugin Hide Backend feature will disable all 5 standard WP Dashboard login slugs like:
- wp-admin
- admin
- login
- dashboard
- wp-login.php
Track down where the extra wp-login slug comes from and disable it there.
dwinden
@falk Wussow
Reproduces easily. Also in my case on the third 404 the following 14 warnings are displayed on the frontend page (as well as reported in the web server error_log):
Warning: Cannot modify header information – headers already sent by (output started at /www/wordpress_temp/wp-includes/class.wp-scripts.php:200) in /www/wordpress_temp/wp-includes/pluggable.php on line 977
Warning: Cannot modify header information – headers already sent by (output started at /www/wordpress_temp/wp-includes/class.wp-scripts.php:200) in /www/wordpress_temp/wp-includes/pluggable.php on line 978
Warning: Cannot modify header information – headers already sent by (output started at /www/wordpress_temp/wp-includes/class.wp-scripts.php:200) in /www/wordpress_temp/wp-includes/pluggable.php on line 979
Warning: Cannot modify header information – headers already sent by (output started at /www/wordpress_temp/wp-includes/class.wp-scripts.php:200) in /www/wordpress_temp/wp-includes/pluggable.php on line 980
Warning: Cannot modify header information – headers already sent by (output started at /www/wordpress_temp/wp-includes/class.wp-scripts.php:200) in /www/wordpress_temp/wp-includes/pluggable.php on line 981
Warning: Cannot modify header information – headers already sent by (output started at /www/wordpress_temp/wp-includes/class.wp-scripts.php:200) in /www/wordpress_temp/wp-includes/pluggable.php on line 982
Warning: Cannot modify header information – headers already sent by (output started at /www/wordpress_temp/wp-includes/class.wp-scripts.php:200) in /www/wordpress_temp/wp-includes/pluggable.php on line 985
Warning: Cannot modify header information – headers already sent by (output started at /www/wordpress_temp/wp-includes/class.wp-scripts.php:200) in /www/wordpress_temp/wp-includes/pluggable.php on line 986
Warning: Cannot modify header information – headers already sent by (output started at /www/wordpress_temp/wp-includes/class.wp-scripts.php:200) in /www/wordpress_temp/wp-includes/pluggable.php on line 987
Warning: Cannot modify header information – headers already sent by (output started at /www/wordpress_temp/wp-includes/class.wp-scripts.php:200) in /www/wordpress_temp/wp-includes/pluggable.php on line 988
Warning: Cannot modify header information – headers already sent by (output started at /www/wordpress_temp/wp-includes/class.wp-scripts.php:200) in /www/wordpress_temp/wp-includes/pluggable.php on line 991
Warning: Cannot modify header information – headers already sent by (output started at /www/wordpress_temp/wp-includes/class.wp-scripts.php:200) in /www/wordpress_temp/wp-includes/pluggable.php on line 992
Warning: Cannot modify header information – headers already sent by (output started at /www/wordpress_temp/wp-includes/class.wp-scripts.php:200) in /www/wordpress_temp/wp-includes/pluggable.php on line 993
Warning: Cannot modify header information – headers already sent by (output started at /www/wordpress_temp/wp-includes/class.wp-scripts.php:200) in /www/wordpress_temp/wp-includes/pluggable.php on line 994
errorThis is while using the Twenty Sixteen theme. You might not see the warnings as the frontend page goes black and\or WP_DEBUG is set to false …
dwinden
Ok, in that case I think it was just a side effect of an issue introduced in the previous release (5.3.1).
Probably nothing to worry about unless these notices are persistent.Do verify on the iTSec plugin Dashboard page, in the System Information metabox, all the way at the bottom, that the current Build Version is 4040. No upgrade code will be executed once you are on the latest Build Version.
Also verify there is an index.php file in both of these folders:
wp-content/uploads/ithemes-security/backups
wp-content/uploads/ithemes-security/logsdwinden
The indicated lines are upgrade lines.
It seems the log_location setting did not exist in the itsec_global option as stored in the wp_options table while upgrading.Any idea from what version you updated ? Anything recent or an old release ?
You can find a version history on this page.dwinden
Thank you for this valuable contribution to the community.
It think you should know that the premium iTSec Pro plugin is the free iTSec plugin + 10 extra features.
So if the free plugin is ‘a way to crash your site’, the paid for iTSec Pro plugin will crash it as well … but I think you get my point, it’s nonsens.
Sure it’s always possible to crash a site using this plugin. Every env is unique and a bug may roar its ugly head at any time. Note the plugin even warns you:Warning
Please read the installation instructions and FAQ before installing this plugin. iThemes Security makes significant changes to your database and other site files which can be problematic, so a backup is strongly recommended before making any changes to your site with this plugin. While problems are rare, most support requests involve the failure to make a proper backup before installation.
I understand your frustration but would a plugin that has been worked on non stop for 5 years really be that bad ?
Is this forum swamped with similar topics from other users experiencing the same issue ?Should we even attempt to help you or should we consider this topic as an attempt to let off some steam ?
Anyway a minor issue was introduced with the 5.3.1 release, but there are no similar symptoms reported as observed in your topic.
Which doesn’t mean that there are no ugly bugs out there yet to be discovered …iThemes has acknowledged the minor issue and is working hard to release an update asap.
dwinden
No problem. I do feel I need to make one correction.
iTSec 5.3.1 (without my fix) does create .htaccess files in all three (ithemes-security, backups and logs) folders.
I guess the 3 fopen/fwrite/fclose groups of commands that create the .htaccess file(s) should be removed from the activate_execute() function in the class-itsec-setup.php file…
dwinden
@WebEndev
I made a quick and dirty fix to illustrate what is wrong and to demonstrate how to fix it. However this code needs some more work.
The original piece of code never worked. The fix makes it work but also revealed a new bug …
For instance with my fix applied there is no .htaccess file created in the logs folder…I’m sure in the near future iThemes will release an update that will include a more comprehensive fix.
One other thing to consider is the content of the .htaccess file.
‘Deny from all’ is Apache 2.2.x syntax only.
Would make sense to add Apache 2.4.x syntax as well.
‘Require all denied’Another thing is why is the ITSEC_Logger class so worried about the logs subfolder ? It should only worry about it when the Log Type setting is set to File Only or Both …
Most people use the default, Database Only …
So who cares whether the logs subfolder exists or not ?dwinden
@falk Wussow & @WebEndev & @gerroald
The reason why this warning is happening is because the @mkdir() command positioned 2 lines earlier is also failing…
Unfortunately because of the @ we have never been notified of this.The @mkdir() command is failing because it tries to create a …/ithemes-security/logs subfolder while the parent ithemes-security folder does not yet exist.
Change your code to look like this and the issue will be fixed:
//Make sure the ithemes-security directory and logs subdirectory are created if ( ! is_dir( $itsec_globals['ithemes_log_dir'] ) ) { @mkdir( $itsec_globals['ithemes_dir'] ); // <- Add this new line @mkdir( $itsec_globals['ithemes_log_dir'] ); // Make sure we have an index file to block directory listing file_put_contents( path_join( $itsec_globals['ithemes_log_dir'], 'index.php' ), "<?php\n// Silence is golden." ); }dwinden
Was iThemes able to assist you in solving your issue ?
If so please take a moment to share the solution with the community.dwinden
@falk Wussow & @WebEndev
Is there also not a .htaccess file in the logs (and backups) folder(s) ?
Note all (3) commands for the .htaccess file creation are already preceeded by a @.
So if a .htaccess file does not exist in these folders its creation is also failing but you are not getting any warning because the fopen\fwrite\fclose commands are all already preceeded by a @.dwinden
Where normal = IPv4 ?
For every ip address listed in the Ban Users setting the following lines are normally added to the .htaccess file:
# Ban Hosts - Security > Settings > Banned Users SetEnvIF REMOTE_ADDR "^196\.163\.172\.21$" DenyAccess SetEnvIF X-FORWARDED-FOR "^196\.163\.172\.21$" DenyAccess SetEnvIF X-CLUSTER-CLIENT-IP "^196\.163\.172\.21$" DenyAccess <IfModule mod_authz_core.c> <RequireAll> Require all granted Require not env DenyAccess Require not ip 196.163.172.21 </RequireAll> </IfModule> <IfModule !mod_authz_core.c> Order allow,deny Allow from all Deny from env=DenyAccess Deny from 196.163.172.21 </IfModule>The above example is an IPv4 address example which I expect to work just fine. However it seems there is an issue with IPv6 support in combination with Apache 2.2.x
IPv6 support was added to the plugin in the latest 5.3.0 release. So if your issue started after updating from 5.2.1 to 5.3.0 there is a good chance the IPv6 support is causing you trouble.Unfortunately there is not much info in the other topic as iThemes decided to switch to email communication while investigating this issue …
dwinden
It would be interesting to know what Apache web server version you are using.
Do you remember whether you had IP addresses listed as banned in IPv4 and\or IPv6 format ?
IPv4 = xxx.xxx.xxx.xxx(/xx)
IPv6 = xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx(/xxx)Anything between () is optional.
If your issue is solely caused by the IP addresses listed in the Ban Hosts setting you can prevent any IP address being added automatically to this setting by disabling the Blacklist Repeat Offender setting in the Global Settings section.
This would also allow you to enable the Write to Files setting again without a chance of the issue reoccurring.There seems to be another topic where iThemes is investigating this issue.
dwinden
Please post the content of your .htaccess file while having this problem.
And also let us know what Apache web server version you are using.dwinden