Support

When I access https://www.freshears.org/administrator/index.php it tells me that the URL administrator/index.php was not found on the server (error 404) even though the file is there according to FTP. This is a server configuration issue, not an Admin Tools issue.

Please contact your host. This is not something we can help with.

> The situation actually began with getting ip blocked by Admin Tools - admin tools gave me rescue URL, and this did not work. 

Your issue is completely unrelated.

When Admin Tools blocks an IP temporarily you get a message page telling you that you are temporarily blocked. When Admin Tools blocks the IP permanently you get an error page telling you that your IP is permanently blocked. These messages are configurable.

I DID NOT receive such a page. I received an HTTP 404 page. That's a server error.

As documented, there is a possibility to get this error if you enable the administrator password protection on a server which is configured to use custom HTML error pages for the HTTP errors BUT the custom error page for HTTP 401 Not Authorised does not exist. However, this is not the case here because a. Admin Tools will by default reset the custom error pages to prevent that from happening and b. I already removed the .htaccess file from your administrator directory as you can see.

Therefore you are receiving an HTTP 404 Not Found error when accessing the administrator/index.php URL of your site. The fact that I receive this error using a DIFFERENT IP address than yours, one that your server has never seen before, proves beyond any reasonable doubt that the problem is one pertaining to your server, not Admin Tools.

> The entire time my site has been in development mode, Admin Tools has left the "protect registration" field unavailable because it says "you do not have registration enabled on your site" which is not true, it is handled by community builder.

Not only this is completely unrelated to this issue, it is also completely wrong understanding on your part.

You have disabled Joomla's built-in user registration. This is non-negotiable. This is a very clear setting in Joomla. We read that setting. It's disabled.

You are instead using a third party extension which simulates user registration using its own custom code. This cannot be used for the purposes of this feature.

If we let you enable this feature here's what would happen. The user would become unverified and they would be sent an email to Joomla's user self-verification page through the com_users frontend component. Since you have disabled Joomla's user self-registration feature this link would result in a Joomla error page. The user would never be able to reactivate their user account.

The reason we added this check preventing you from selecting this option is people like you who do not understand, despite it being documented, that disabling Joomla's built-in user self-registration breaks this feature.

So, Admin Tools does the right thing here.

> However this has been a cyclical issue, where my ip is being marked as a "hacker" and then gets blocked out, and this time it cascaded into this larger issue.

Correlation does not equal causation.

Again, if you were blocked by Admin Tools you would be seeing a completely different page with a different HTTP status code. 

The error page you get comes from your web server and means that your web server cannot load the administrator/index.php file. This is NOT caused by Admin Tools.

Further to that, you have already told me that you proved this is not caused by Admin Tools. This is information you volunteered yourself. Admin Tools provides two levels of protection: its Web Application Firewall implemented entirely in the System - Admin Tools plugin (stored in plugins/system/admintools) and creating a custom .htaccess file through the .htaccess Maker feature.

You have already disabled the system plugin by renaming its folder AND by disabling it from the database. The former means that Joomla cannot find the plugin's code, therefore it cannot load it, therefore it cannot execute it. The latter means that even if you hadn't done the former, Joomla would refuse to load the plugin's code, therefore it would be unable to execute it. As a result you have ensured that the Web Application Firewall feature does not execute on your site.

You have already removed the .htaccess file generated by Admin Tools' .htaccess Maker feature in your site's root. As a result your web server no longer executes its instructions. Therefore you have already undone the .htaccess Maker's changes to your site.

However, even after disabling Admin Tools' executable code from executing AND undoing its .htaccess Maker changes to your .htaccess file you still have the same issue. Therefore you have proven that the issue is unrelated to Admin Tools. What you did is actually the troubleshooting steps I would have asked you to do to see if the problem is related to Admin Tools at all, steps I have been recommending since 2011.

Further to that, if Admin Tools was blocking either of us from accessing your site it would do that for the entire site: backend and frontend. We can both access the frontend of the site, therefore putting a tombstone to the theory that somehow, magically, Admin Tools blocks you from accessing your site.

> I run an extension called MightySites which splits one Joomla install into two websites on two domains. My intuition is that Admin Tools is not functioning well with some of these other functions and the offline state.

I am very familiar with MightySites and know exactly how it works. My wife is using it in a site she launched for a non-profit client. Admin Tools works just fine with it. The only change we had to make was in the Allowed Domains settings, making sure that both domains the site can be reached under are in there. Further to that, we had to disable the “Use HSTS” feature in the .htaccess Maker, instead using set “Use SSL” to “Entire site” in Joomla's Global Configuration, since the .htaccess Maker feature uses only one domain to perform the HTTP to HTTPS redirection.

However, these changes are irrelevant to your issue as they are changes to the Web Application Firewall and the .htaccess Maker. Since you have proven that the problem occurs even when you disable the system plugin implementing Admin Tools' Web Application Firewall and you have undone all changes effected by the .htaccess Maker you have proven that your issue is not with Admin Tools.

It would be far more productive if you asked your host for assistance as I asked you to do in my first reply. I am not trying to “get rid of you” or slow you down in any way. Your issue is likely to be caused by wrong ownership / permissions OR a misconfiguration in your .htaccess file OR a misconfiguration in your server setup. Since I am not your host I do not have access to the Apache error logs which provide the relevant details as to why the error occurs, I do not know how the server is set up (therefore which ownership and permissions are correct, or which .htaccess directives are disallowed) and I definitely do not have access to your server's configuration. As a result I cannot help you with this issue which you have already proven it has nothing to do with Admin Tools.

If you fix this issue I can and will help you with your other issue of getting blocked all the time. However, I cannot do that unless you address the server issue which prevents either of us from gaining access to your site's backend.

Considering that the issue was not caused by Admin Tools I do not have any further advice to give.

> Please put a little attention to what I am asking

This is actually very offensive. I am paying attention to what you are asking. Are you paying attention to what you are claiming? You are presenting me with an impossibility by telling me this:

> I also tried disabling admin tools through database entry alteration, file name changing, and also disabling .htaccess - there is no .htpasswd - none of these methods have resulted in me getting into the backend again yet

I assume that disabling Admin Tools in the database may have been done incorrectly. You very likely disabled the component, not the system plugin, thereby having zero effect. Or you may have disabled the System - Admin Tools plugin which is the same as renaming main.php on the plugin. I completely ignore this bit since either way it will not alter what the other two assertions mean.

By “file name changing” I understand that you have renamed the main.php file. In this case it means that the entirety of Admin Tools' Web Application Firewall and any feature associated with Admin Tools does not, in fact, execute on your site. Unless you explicitly log into your site's backend and go to Components, Admin Tools you are not running any of Admin Tools' code.

By “disabled .htaccess” I understand that you have renamed the .htaccess file in your site's root and your administrator folder, therefore any changes made by the .htaccess Maker and the Password Protect Administrator feature have been removed.

By doing those two things there is absolutely no trace of Admin Tools running on your site.

However, you assert that despite doing that you still cannot access your site. Therefore you have proved beyond any reasonable doubt that your problem is unrelated to Admin Tools.

Moreover, when you gave me access information to your site I got a 404 Not Found server error page, I did not get blocked by Admin Tools. I have also checked today, you do not have an Administrator Password Protection or Secret URL Parameter to block you.

If my assumptions about what you described you did do not line up with what you actually did please do tell me. I can not read your mind, I am not standing over your shoulder, I can only reply to the information I am being provided. The information you provide paint this picture: either your issue is not an Admin Tools one or that what you said you did is not what you actually did.

If you insist that what you said is true then I will insist that your problem is not an Admin Tools issue one, per your own words, and close this ticket.

If you accept that you may have been wrong about what you did or did not do I will accept that this may be an issue related to how you have configured Admin Tools and how you are using your site. In this case please provide me with the Reason and Target URL stated in Admin Tools, Web Application Firewall, Blocked Requests Log right after you are locked out of your site. Then I will be able to help you like I've done thousands of times the last 12 years.

> A product you have sold me is repeatedly locking me out.

Going the commercial dispute route means that I have to go by the letter of the Terms of Service to which you explicitly and unreservedly agreed to when subscribing, starting now.

> The email restore function you provide does not work in these situations, causing a complete lockout.

The Rescue Email is NOT the only way to restore access as per our documentation and I am linking the same page again: https://www.akeeba.com/documentation/admin-tools/atwafissues.html which explicitly states:

“There are two ways to regain access to your site, Rescue Mode and FTP.”

As this is an unreasonable claim no further support will be provided to you about the Rescue Mode email per our Terms of Service.

> "User registration on your site is disabled, therefore Admin Tools can't deactivate users." is displayed in WAF settings, even though this is not true. Registration is handled by Community Builder. 

You are wrong and I have already explained this to you.

You have disabled Joomla's built-in user registration. This is what you set up on your own site's backend in Users, Options, Allow User Registration. This is a very clear setting in Joomla. We read that setting. It's disabled.

You are instead using a third party extension (Community Builder) which simulates user registration using its own custom code, bypassing Joomla's user registration feature. This third party software cannot be used for the purposes of this feature. Also, as per our Terms of Service, using this kind of software which fundamentally modifies your environment (registering users without going through Joomla's user registration and despite user registration being disabled is a fundamental modification of your execution environment) gives us the right to refuse support.

Therefore you will not receive any further support about this disabled feature per our Terms of Service.

>  I do not know if this is a contributing factor, I am merely seeking to break the cycle with this so that I can use the product I paid for and not have to write you again.

It is not a contributing factor. It's a completely unrelated feature which is disabled. 

All I need from you is the Reason and Target URL. Consider this my formal request for more information for the intents and purposes of what is described in the Support Policy of our Terms of Service.