sgarcia513

Unfortunately, when installing 9.0.2 as a new install, it gives me a missing header error when trying to activate.

The plugin does not have a valid header.

Same issue with 4.6.2 – downloads would never finish and eventually would fail.

Commenting out lines 674 – 679 in the /src/DownloadHandler.php file did work for me.

I had a similar situation with the publish date needing to be sorted current to oldest. I ended up updating the DataTable call after it’s been initialized using order. It’s not the cleanest solution, but it works. I had to give it a setTimeout of half a second to make sure everything was loaded otherwise got inconsistent results.

<script>
    function sortDate(){
        var table = $('table.dataTable').DataTable();
        table.order([3, 'desc']).draw();
    };
$(window).load(function(){
    // autosort publish date
    setTimeout(function(){
        sortDate();
 },500);
    
})

</script>

• This reply was modified 3 years, 6 months ago by sgarcia513.

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.

Thanks

• This reply was modified 5 years, 9 months ago by sgarcia513.
• This reply was modified 5 years, 9 months 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.

Thanks

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.

Thanks
– Steve

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

Thanks!

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