Support

Hello Bert,

I have thought of that, about a year ago, but I decided not to implement it. The main reason is that it would make the restoration script tightly coupled with the particular Admin Tools version it is written for. Adding support for all past, present and future versions of Admin Tools Professional in the installation script would be a monumental task, if not a futile one.

That said, there is an easy workaround with minimal fuss:
- If you are using the administrator IP whitelist feature, add the IP 127.0.0.1 to the list. This IP means "the local computer". On your live site, it has no consequence, as it would imply that an attacker has already gotten hold of the server and is running shell commands. In such a case, the attacker could simply hack your site by editing the files instead of going through the trouble to use wget or curl to launch web-based attacks.
- Likewise, add 127.0.0.1 to the "Never block these IPs" field in the Configure WAF page.
These two steps allow you to use the restored site on your local machine without a hitch.

If you are also using the .htaccess Maker, you will need to do a couple of very easy steps on the restored site:
- Remove the .htaccess
- Go to .htaccess Maker, expand the System tab and set up both domains to localhost and set the directory to the local directory you've restored your site to, e.g. /joomla
- Click on Save and Create .htaccess
In fact, after the first time you do that, you can expedite the process! Simply exclude the .htaccess file from the backup. This way, every time you restore your site to your local server the (fixed to work with the local host) .htaccess file will NOT be overwritten and you can skip those steps.

If you follow these simple instructions, you will not need to do anything when restoring the live site to your local server to work around WAF and .htaccess Maker restrictions. Magic! :)

Hi Bert,

The obvious solutions are the hardest to imagine. Remember the story about Columbus and the egg? :)

The address is not added in the whitelist because not everyone wants to restore their sites locally and certainly not everyone understands the concept of 127.0.0.1 like you and me. I thought that those who need it would find the way, or ask me. You're the first to ask in 18 months :)

I am not manipulating the table directly during restoration, because that's not what you want and it's not enough. The only table with a fixed name is the Administrator IP Whitelist. In order for this to work, you have to enable that feature too. Let's say that I would enable that feature. Your local site would work perfectly, but once you copied it back to the live site, you wouldn't be able to log in. Not to mention that the restoration script would not know when it's restoring to a live site (sniffing localhost IS NOT a proper solution, my local dev site has the domain name dev.local.web, thanks to the hosts file of my Mac), so it would enforce that kind of limitation on every restoration. This is not what you want. Furthermore, the exact way to enable the IP Whitelist feature has changed twice since the last 18 months. Adding such a feature to the restoration script would make it extremely dependent on the exact implementation and wouldn't allow me to change how Admin Tools works.

There are more reasons why I am not implementing that feature, but I really don't care mentioning them. I'd better spend my time writing code than discussing the code I won't be writing :)

Suggestions are always welcome! Probably half of the features in Akeeba Backup and almost 80% of the features in Akeeba Subscriptions came to be thanks to user suggestions. If a feature request can't be worked around in any other sensible way, represents a real need (i.e. it's not specific to a user's setup) and doesn't cause a functional problem it is implemented, or at the very least added to my to-do list. It's that simple :)

Regarding the restoration, one of the features in the back of my head is enabling components on the site defining their own post-restoration "hooks" which could allow the installation script to run custom per-component code when the site restoration is over. This is something requested by other developers, wishing to have their components reconfigure themselves when the user uses Akeeba Backup to relocate the site. Sounds familiar? Architecturally, this is the exact opposite of what you suggested (the installer will call Admin Tools' code instead of including it inside it), but functionally it could work the same way, i.e. it would allow Admin Tools to reconfigure itself on-the-fly right after the site is restored. When I implement this, it will open a world of opportunities! If other developers make use of it, we'll be talking about zero-configuration site move from one server to the next.

However, is a little trickier than it sounds. How do you let components notify Akeeba Backup of those hooks? How can these hooks be called, making sure that the process doesn't time out? What happens when a hook is not present, e.g. because the user excluded the directory containing the hook or because he excluded the table referenced by it? These are the problems I'm trying to solve. Once I solve those problems, what you suggested will be possible in a much more elegant manner which won't cause any problems. That's the part I didn't mention in my previous reply ;)