Support

Site Restoration

#17932 Cleanup needed after site migration

Posted in ‘Site restoration’
This is a public ticket

Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.

Environment Information

PHP version
n/a
CMS Type
Other
CMS Version
n/a
Backup Tool Version
n/a
Kickstart version
n/a

Latest post by tabletguy on Wednesday, 23 October 2013 10:17 CDT

tabletguy
Mandatory information about my setup:

Have I read the related troubleshooter articles above before posting (which pages?)? Yes
Have I searched the tickets before posting? No
Have I read the documentation before posting (which pages?)? Yes, I think so.
Joomla! version: 2.5.14
PHP version: n/a
MySQL version: n/a
Host: DreamHost
Akeeba Backup version which took the backup: current Pro version
Kickstart version used to extract the backup: 3.7

Description of my issue:
I noticed these things while running a restore.

I "restored" from test.mysite.com to mysite.com (name of folder and name of URL). Dreamhost creates subdomains with the folder name matching, by default.

In Directories fine-tuning it didn't correctly switch the "Temporary directory" to the new location of \home\myname\test.mysite.com to \home\myname\mysite.com It left it at pointing to the backup location. I did read the restoration documentation steps. I'm mentioning it here because the other two directories in the "Directories fine-tuning" DID switch. I thought that was confusing.

Also, I noticed that the new log directory name ended as "log", where, in the archive, it was "logs", and the restore did create a "logs" directory. I'm not sure about why it did this. I didn't even have a "xx\log" folder in the "from" site. Maybe there was a left over misconfiguration. Quicker to mention it in case.

When doing the cleanup, it doesn't remove jquery.min.js or json2.min.js files. Now, I confess I didn't search the documentation for this one. Seems like they should be removed when other parts are cleaned up.

nicholas
Akeeba Staff
Manager
In Directories fine-tuning it didn't correctly switch the "Temporary directory" to the new location of \home\myname\test.mysite.com to \home\myname\mysite.com


Therefore it operated as designed. Our restoration scripts (ALICE and ABI) cannot possibly know if you are deliberately using a customised temporary / log directory. Therefore we do a simple test: if the temp / log directory defined in the backed up site's configuration.php is writeable at the time of the restoration we don't touch it. If it's not writeable or doesn't exist we assume that you want to change it and auto-fill the temp / log directory fields with Joomla! defaults for the new server.

Since you are moving your site inside the same server the configured temp and log directories are there and writeable. As a result we do not touch them; it's up to you to change them. Therefore what you describe is the expected and desired effect.

I'm mentioning it here because the other two directories in the "Directories fine-tuning" DID switch.


These are suggestions. We suggest you to use the default Joomla! directories. In order to make it easy for you –most of our users couldn't figure out how to determine those paths– we are showing these paths to you. You know why we do that? For cases like yours: restoring in a different location inside the same server user account.

Also, I noticed that the new log directory name ended as "log", where, in the archive, it was "logs", and the restore did create a "logs" directory.


This is, again, by design. Joomla! does default to the "logs" directory, but there's a "small" problem: all servers running on Parallels Plesk reserve the "logs" directory for system use, namely to write your account's web server access and error logs. As a result this directory is unwriteable. Trying to use it causes something as minor as an intermittent warning in several core and third party components to something as grave as inability to log in to your site (in case debugging was turned on and the debugger was trying to write to the log). In order to prevent similar mishaps we are now defaulting to "log" instead of "logs".

When doing the cleanup, it doesn't remove jquery.min.js or json2.min.js files.


This has been fixed in Kickstart 3.7.1. I suppose you're using 3.7.0 which, indeed, is affected by this issue.

I hope this information clears up the situation for you.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

tabletguy
Thanks, didn't know that about log versus logs. I suspected the other was because of a "writable" (good) location. I don't do restorations enough to automatically notice this, unfortunately.

Support Information

Working hours: We are open Monday to Friday, 9am to 7pm Cyprus timezone (EET / EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets outside of our working hours, but we cannot respond to them until we're back at the office.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!