Forum Replies Created

Viewing 15 replies - 1 through 15 (of 21 total)
  • Understood and it makes sense. We ended up figuring out the memory issues found elsewhere but was looking at all avenues. Thanks for the quick response!



    Got it. There’s some strange caching going on in the site so it took a while for it to change even in Chrome Incognito mode but it looks like it’s showing “This has been disabled”

    That should be enough, we don’t need it redirecting as long as it keeps attacks, the error page will work.

    Thanks for your help!



    This was my same issue and glad I found this post.

    Was doing troubleshooting and was pulling my hair out when I realized that GA’s default for reporting is 7 days up to yesterday. Changed to today and voila, they all showed up…

    Plugin works like a charm (other than my absentmindedness), thanks for the great work!



    Thanks for the info!

    I added a simple print_r($request_path) on line 88 and visited the page and it came back with wp-login.php.

    That tells me two things, the conditional is being met and that it’s returning with a single matched value.

    I looked further down at the handle_canonical_login_page() function to see if I get any value for $action and it doesn’t return anything.

    Took a look at the block_access function to see if I get any kind of data within it. Tried to echo out $this->settings[‘theme_compat’] and $this->settings[‘theme_compat_slug’] to see if those exist. I’m not getting anything returning in that function. Just trying to echo out ‘test’ brought nothing.

    **Edit: spoke too soon. I put the echo line on line 195, but it had returned out one if statement earlier at 191. Here’s what gets echo’d out:

    echo $this->settings[‘theme_compat’].” : “.$this->settings[‘theme_compat_slug’];
    1 : not_found

    Not sure if that’s a proper test or not, but just trying to find where the hang-up is.


    • This reply was modified 1 year ago by sgarcia513.
    • This reply was modified 1 year ago by sgarcia513.


    Yes, I’ve already diasabled xmlrpc a few months ago, all logs are showing wp-login.php.

    I didn’t originally change the back-end URL at that time as we have quite a few editors on the site and I was already having them change the way they were writing they’re posts so adding a new URL probably would have spurred a revolt.

    Is there a debug I can enable to see where it may be failing or getting overridden?



    Hi nlpro,
    Going to /wp-login (withoug .php) redirects to the not_found page so it looks to be specific to only wp-login.php.

    Server info:
    PHP 7.0.33
    Litespeed 7.2
    MySQL 5.0.12

    This is one of about 25 WordPress sites on the server all running iThemes with backend hidden. Only this site is having issues with it. Unfortunately, this is site that’s being marketing worldwide so it gets a lot of brute force attacks which is why I’m trying to limit it to save our server.



    I’m using 7.2.0 on one of my client’s sites and it’s letting me access the login page with wp-login.php. I was able to in incognito mode in Chrome, private mode in Firefox and I’m still seeing bots access the page in the logs.

    It seems to work fine on all other sites, but not this one for some reason. I’ve deactivated all plugins that have anything to do with member, access and redirects. Just basic plugins like CF7, Yoast, Custom Post Type UI, ACF, etc.

    What’s interesting is going to /admin and /wp-admin.php do redirect to the “not found” page but wp-login.php still works for everyone.

    Thanks, this is all great information

    I did look at a random sample size and it looks like they’re all using XML-RPC connection so I’ve disabled them, and plan to for all of our sites since no one uses the mobile version or pingbacks.

    One of the sites already had the Hide Backend plugin being used and was one of the most attacked. Ran through a handful and they were also all using XML-RDC.

    I think this will help tremendously. Also, I’m in the process of setting up LiteSpeed’s Brute Force Protection as well. Hoping to set up multiple obstacles and free up our server resources.

    Thanks again for your help!

    Thanks for the insight nlpro.

    We don’t have 404 detection enabled. I wasn’t necessarily believing it was HackRepair, specifically, but that the rewrite wasn’t being completed causing the 404 errors. Because of false positives our client asked that User Banning be turned off so I enabled the HackRepair banning to give some sort of protection. My biggest concern was the duplication of those same 4 lines inflating the file.

    I did look at the security logs and, of course, the sites were getting pounded within a minute of each other from various IP addresses but didn’t see anything out of the ordinary.

    I went ahead turned User Banning back on and looked at the htaccess file and it’s much cleaner in regards to those duplicated lines are no longer there.

    My guess is with the constant rewriting of htaccess without adding any IP addresses and the constant duplication of the first four lines there was bound to be a breaking point where the htaccess file wasn’t being fully rewritten properly. Unfortunately, the WP lines are at the very end which instantly breaks a site and requires a manual reset.

    Turning off user banning isn’t typical so it’s a small bug in regards to the htaccess file inflating so quickly. I let the client know that we had to turn User Banning back on and there could be the occasional false positive which we’ll have to deal with on a case-by-case basis.


    What I’m noticing is a list of backup htaccess files on the server. The three sites that were having troubles have at least 7 backups:

    .htaccess_lscachebak_01 through .htaccess_lscachebak_07 and a .htaccess_lscachebak_orig

    So unless something else is called “lscache” then it’s telling me the plugin is doing something with the htaccess files. I looked at the file dates and they’re usually grouped over a day or so, then nothing for a few months, then a few more.

    The sites that haven’t had any problem just have lscachebak_01 and _orig, but the sites that I’ve had to disable them have 7, 8 and 9 backups.

    For the sake of keeping my client happy, I’ve had to disable them on those sites.

    The 404 would happen on all subpages, not just a particular one. Resaving the permalinks page is the only way to fix it as it’s refreshing the WP portion of htaccess file.

    I am using iThemes security which does write to the htaccess file as well but we use both of these plugins in tandem on almost all of our sites. It is odd that the three sites with the most traffic are having this problem. The sites aren’t linked nor are they on the same account on our server; they’re three completely separate businesses but get a lot more traffic than every other site hosted by us.

    Hope this helps. I can send you a sample of the htaccess backup files if that would help as well.

    – Steve

    Any chance adding shortcodes to email templates is on the EBD roadmap at any point?




    Thanks! I can confirm it’s working on my install.



    Thanks of the info regarding your extensions. If you have an extension that will enable us to send an email with the file link downloaded with a fully custom email template that allows shortcodes within it, then I’d definitely be interested. We don’t need the file “locked” per se; we need an email to be sent with the file link.

    The emails we send out have a list of additional downloads they may find interest in so we wouldn’t want them locked down requiring an email for each one.

    The Email Before Download plugin does just what we need (except for allowing shortcodes in an email template) however having three plugins working in tandem; Download Monitor, Email Before Download, and Contact Form 7, anytime a major change happens to one of them there’s often a ripple effect.

    Generally I wait to let things settle down before updating to make sure bugs are figured out but at some point I do have to update.

    Thanks again for your help with this. We’re working with the EBD plugin developer for a fix.



    Thanks for the update. I’m now getting a “Invalid UID Please fill out a new form to generate a new link.” when trying to go directly to a DM link without it having the UID parameter on the end which is present in the email.

    You’ll see the error if you use the link I submitted in my original post:

    This link works:

    • This reply was modified 2 years ago by sgarcia513.


    I’ve noticed this as well, the ?uid parameter on the links still allow the download to work, but any links I have hard coded in my emails as additional download options do not work.

    Hopefully this will be fixed soon. My client is not very happy links aren’t working as requiring emails before they download reports and tracking the downloads are the main functionality for their three sites. It also makes me cautious updating to newer versions in the future.

Viewing 15 replies - 1 through 15 (of 21 total)