eitanc

5.3.29

Strange, I appologize for this but as far as I recall – I posted only one time, I have not idea how the dups were created. sorry, anyway.

But you marked all of them as resolved, as far as I see, which one is the non-resolved?

Now I it also happen even if the admin account is named “admin”

Hi, Yorman, why do mark this as resolved?

Never mind, solved it – too agressive caching in my CDN.

+1! A direct link to the changelog of the upgraded plugin will be even better, possibly even attach to the mail the changelog block text of the relevant latest version! :))

Thanks!

Eitan

Awesomely cool! Looks just like what I wanted… you think ahead… very good!
I will give it a try.

Thank you very very much!

Eitan

I had the same issue, using the latest version of this plugin.

I simply renamed the .htaccess file at the root folder of the relevant site to something else and strangely the “hide backend” feature is working fine now… although it should NOT work since there is no rewrite operation at the .htaccess file level.

The content of the file looks like the following:
# BEGIN iThemes Security
# BEGIN Hide Backend
# Rules to hide the dashboard
RewriteRule ^/<my-secret-text>/?$ /wp-login.php [QSA,L]

# END Hide Backend
# END iThemes Security

I think this is one of the worst upgrade moves I’ve seen for a long time.

I noticed that the site’s .htaccess file was changed and it currently hold no more the redirect to the special wp-login.php URL, so it was either replaced or modified by the upgrade.

So I worked around the issue by reverting things back:
1. I renamed the “better-wp-security” folder (instead of delete, just in case…)
2. I renamed the current .htaccess file at the root of the site
3. I uploaded the latest backup of the “better-wp-security” folder to the “plugins” folder
4. I uploaded the latest backup of the .htaccess file to the root of the site

Now all looks back in order.

I have a similar issue, but I’m coming from a point were my login page is already hidden and accessed from a unique URL for already some time, and the upgrade to version 4.0.2, the latest, caused that when I use this specific URL I am directed to the default wp-login.php page with the following error:
Warning: in_array() expects parameter 2 to be array, string given in /home4/<my-user-name>/public_html/<my-site-folder>/wp-content/plugins/better-wp-security/modules/free/four-oh-four/class-itsec-four-oh-four.php on line 32

Thanks for looking into this.

The option you mentioned is good for when creating or editing a job, but as the idea of WP backup is mostly “set and forget”, this option won’t help when a file has grown over time or added later.

BTW, you can combine both things by, say, painting with red font the files in the job settings when they are equal or over the user set site for “large file”.

Thanks,

Eitan

I had the same issue and it was found that I had a huge “error_log” file at the site’s root’s folder. Once it was delete – all run smooth.

Daniel, if you can somehow add a process to first scan all of the files for ones with size larger then X (which will be user customizable) and let the user customize if just to add a warning at the log, before packing it all into one file, or also to abort the job and let the user fix it.

Thanks,
Eitan

Very interesting.
I have made deeper tests, also comparing with another SMTP plugin, and I found that this plugin has a real bizarre security corner case, that is very persistent.

I’m checking it now with my hosting company as this issue is on the border line between the plugin and the hosting server.

I will update here when I have more solid conclusions.

How can you say it is working as expected if several users, with what looks to be the same configuration – tells you it doesn’t and you don’t even try to repro this configuration?

I will not role-back to older version as I KNOW it worked well in the previous version of WP.

If you wish to seriously check claimed issues about this plugin – than please test it as described and if not – just tell us and we will move on.

Yes it was.