Support

Hello Martin,

please look at your server paths: /home/accountname-old/public_html.
The home folder is created by your server and has specific permissions, you can't simply copy and paste it, calling it home2.
If you want to create a test environment, please create a new folder under the public_html folder.
Anyway, this is not a a Joomla or Akeeba Backup related issue, you should contact your host and ask him the proper way to setup a test environment.

First a reply according to what you are telling us is going on (I have good reasons to believe it's not likely – if you are right Joomla! or even the restoration script itself could never run!). We do not decide about the directory detection. In fact we are simply using the magic constant __DIR__ that's offered by PHP itself and contains the full filesystem patch to the current directory. Please read http://php.net/manual/en/language.constants.predefined.php Therefore it is PHP itself that reports that the directory to your site is /home/.... and not /home2/... Since we did not set up your server or have any control over it we can't really help you. You have to talk to your host because either their server setup is FUBAR or their PHP binaries are misbehaving. The fact remains that, as you can read in the official PHP documentation I linked to above, the __DIR__ constant MUST ALWAYS contain the full filesystem path to the directory where the file using it (in our case, kickstart.php) is located in.

However, I do NOT consider this to be the case. Instead I am certain that you are making a simple mistake when restoring your site.

I'd like to remind you that Kickstart only EXTRACTS the archive. The actual restoration is performed by ANGIE which is part of the backup archive itself. Next time you run Kickstart do not dismiss the popup. Spend 60 seconds to read it. This information is contained in there. The fine tuning box you are talking about is inside ANGIE. See this screenshot, I assume we're talking about this page:


As you can read in its documentation and watch in the video tutorial the default values for these two edit boxes (Temporary directory and Log directory) are the ones already present in your backed up site's configuration.php, i.e. the old directories. If you are restoring to a new server you can edit them to reflect the correct path.

The "Site root" field itself is not editable and is only there as a reference. It is not saved anywhere! It simply contains the value of

realpath(__DIR__ . '/..')

i.e. the absolute filesystem path that PHP believes is the directory where the installation folder exists. If that path is wrong contact your host immediately and paste them this reply of mine: it would indicate that something is wrong in your server setup.

However, if that path is not wrong and the two paths below it are wrong you just have to edit them per the documentation instructions. In the example image I posted above you can see that the site I am restoring to is under /Users/nicholas/Sites/restored whereas the original site was under /Users/nicholas/Sites/test31. Therefore I must change the two paths or my restored site will not work properly. Also as explained in the documentation, checking the "Override tmp and log paths" would have the same effect – and it's less typing for you!

Finally note that these two edit boxes simply correspond to the Temp-directory and the Log directory of your site. They are there as a convenient way to change site parameters while restoring your site, NOT as the only way to do it! Like all other Global Configuration options you can always change them after the restoration of your site by logging in to administrator and going to System, Global Configuration. So even if you forgot to change them during restoration you can still do that easily on your restored site.

OK. In this case I am genuinely surprised Joomla! manages to run at all. __FILE__ and __DIR__ are used throughout Joomla!'s code to set up paths used internally. Best of luck with your host!

Actually his response is asinine by stating that "This is unfortunately a major flaw in the coding used for the script, and has been seen before on anything utilising realpath, which doesn't show the absolute path correctly."

This is NOT a bug in PHP – at least not in any 5.4.x or alter version. Indeed there was a bug in old versions of PHP 5.2 and probably older concerning symlinks. However, no such bug exists anymore.

Furthermore, we are using __DIR__, not realpath(). Using __DIR__ is NOT a bad programming practice unless you consider the STANDARD programming practice of Joomla!, WordPress, Drupal, Magento, Moodle, PrestaShop and other major PHP CMS and e-commerce solution as well as the programming practices of the major PHP frameworks (Symfony, Laravel, Zend Framework) which power the sites of Fortune 500 companies "majorly flawed". The only major flaw here lies in this tech's complete lack of PHP knowledge.

Let me remind you that before PHP 5.3 developers (and all PHP products!!!) had to use the construct realpath(dirname(__FILE__)) to get the equivalent of what __DIR__ contains since PHP 5.3. Indeed, the PHP community decided that the construct is A Bad Idea™ not because of the use of realpath but because of 1. bad performance and 2. certain servers using a borked CGI setup populating __FILE__ with a relative path (there was even a php.ini switch to fix that issue). And that's why we, along with every PHP developer out there, replaced those constructs with a simple reference to the __DIR__ magic constant. That happened nearly 5 years ago when we could finally drop PHP 5.2 support.

I can tell you what is 99% likely to be going on because I've seen that again. They are mounting two different partitions (presumably on different physical disks / SANs) into /home and /home2 because their server's main hard drive maxed out. Their first mistake is that they are not using LVM to properly extend the capacity of their server. The other mistake is that they resort to hardlinks to make the /home2 directories appear as subdirectories of /home. They had to do that otherwise their OS wouldn't see the user accounts stored in /home2. Since PHP –and any process that doesn't explicitly look for hardlinks– can't see the difference between /home/yourUser and /home2/yourUser it reports a path under /home as the full filesystem path (using the __DIR__ constant). However, they are also using open_basedir to limit access to /home2/yourUser. So because your host doesn't understand how Linux or PHP work they have screwed up their server setup, big time!

I would like to remind that so-called "support tech" who replied to you that the actual code used to determine the path is the following and just the following:

define('APATH_BASE',          __DIR__);
$parts = explode(DIRECTORY_SEPARATOR, APATH_BASE);
array_pop($parts);
define('APATH_ROOT',          implode(DIRECTORY_SEPARATOR, $parts));

The APATH_ROOT constant, derived solely from __DIR__ (introduced in PHP 5.3.0), is what is being displayed. The only reason __DIR__ contains the wrong path is because your host doesn't know how Linux works and borked the server capacity extension by doing the same WRONG thing hosts were doing in the early '00s. Let me remind you that Linux LVM 2.x has been around since 2004. You'd think that in 12 years your host might have figured it out...

So apparently the "support techs" they employ a. don't know how their server work b. don't know how PHP works and c. can't read PHP code. Yet they feel entitled to comment on how we write our code. I'd like to remind everyone reading this exactly how Joomla! itself, in the administrator application, determines the path to your site's root which lets it load com_login that eventually lets you log in etc:

define('JPATH_BASE', __DIR__);
$parts = explode(DIRECTORY_SEPARATOR, JPATH_BASE);
array_pop($parts);

// Defines.
define('JPATH_ROOT',          implode(DIRECTORY_SEPARATOR, $parts));

The code is split between administrator/index.php and administrator/includes/defines.php.

Based on the fact that Joomla! runs fine on 3% of the entire freaking Internet of millions upon millions of sites and we're using the same code as Joomla! we can very safely conclude that your host has no idea how their server, Linux, PHP and Joomla! work. I would STRONGLY recommend switching to a host that knows what they're doing. In no particular order I recommend CloudAccess.net, SiteGround, Rochen and InMotion Hosting.

No, I meant that Joomla! does run on 3% of all Internet sites out there (that's its market share). That proves the popularity of the platform and the fact that it actually does run. Since Joomla!'s code runs on hundreds of thousands of servers and we're using the same code the support tech's case that our code is bad and can't run is immediately shot down ;)