Akeeba Backup for Joomla!

Monday, 16 June 2014 00:33 CDT

Maxoid

EXTREMELY IMPORTANT: Please attach a ZIP file containing your Akeeba Backup log file in order for us to help you with any backup or restoration issue. If the file is over 2Mb, please upload it on your server and post a link to it.

Description of my issue:

Previously I have used a site back up installed on a sub domain to test for upgrades and new software. Creating a new mysqi dbase and using a different prefix, I install it using the std angie interface from the subdomain url. Then completed the testing and deleted the subdomain. We have been doing this since Joomla 1.0.

Just recently this has changed. The subdomain are linking in to the orginal dbase. When removing componant, modules and plug from the subdomain site they are also being removed from the main site.

I've also moved it to an unrelated domain and installed it as discribed above and with the same effect of linking to the other dbase so that the new subdomain now show the original/prime domain not the testing area.

Monday, 16 June 2014 03:49 CDT

nicholas

You are accidentally entering the same database connection information as your main site's during the restoration to the subdomain. Please see the troubleshooter page for the entangled websites issue.

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!

Monday, 16 June 2014 08:58 CDT

Maxoid

Respectively I haven't.

I add the new mysql during the process of angie. In a different tab i have cpanel open, and use cut and paste to add the new database info into the screen prompts.

It also doesn't explain why the the zip files extracted into a new subdomain in a different domain does a similar thing

Monday, 16 June 2014 09:08 CDT

Maxoid

The only this I have kept the same is super user login details.

I'll try it again and change this... to see if it make a difference...

Monday, 16 June 2014 09:10 CDT

nicholas

Unless both sites talk to the same database what you describe is absolutely impossible. Please check your configuration.php files on both sites and you'll see that they are talking to the same database.

If you are entering different database information, are you sure that your new configuration.php file with the new database connection information was written to disk? If ANGIE couldn't write to it you should get a warning which is easy to overlook.

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!

Monday, 16 June 2014 09:59 CDT

Maxoid

I've just gone through the process again. As you can see from the screen dump, I created a new database "akeeba" with the prefix angie_ as you can see the original dbase of wbxvaxvz_2jA9oMKT3BKK6WZeqiimnz is quite different and something i would mix up.

Logging in to the new subdomain and changing the template for the subdomain also changes the template for the main domain....

Below is the config.php of the test site

<?php
class JConfig {
public $offline = '0';
public $offline_message = 'We are off camping or canoeing so check back later.';
public $sitename = 'G Scout test';
public $editor = 'jckeditor';
public $list_limit = '25';
public $access = '1';
public $debug = '0';
public $debug_lang = '0';
public $dbtype = 'mysqli';
public $host = 'localhost';
public $user = 'wbxvaxvz_akeeba';
public $password =
public $db = 'wbxvaxvz_akeeba';
public $dbprefix = 'angie_';
public $live_site = 'https://akeeba.xxxx.com.au';
public $log_path = '/home/wbxvaxvz/public_html/development/akeeba/log';
public $tmp_path = '/home/wbxvaxvz/public_html/development/akeeba/tmp';

Monday, 16 June 2014 10:41 CDT

Maxoid

Below are the dbase info for the main domain. The only thing I can think of is we have recently upgraded cPanel to 11.42 and with that php and mysql

public $host = 'localhost';
public $user = 'wbxvaxvz_pZ#####';
public $password = '';
public $db = 'wbxvaxvz_2jA9oMKT3BKK6WZeqiimnz';
public $dbprefix = 'cq##_';

Monday, 16 June 2014 10:57 CDT

nicholas

Have you customised your defines.php files to tell Joomla! to load the configuration.php from a different location than the site's root? Other than that, there is no rational explanation.

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!

Monday, 16 June 2014 19:20 CDT

Maxoid

Thanks, we haven't but I'll see if it has been amended and if so how...

Monday, 16 June 2014 19:41 CDT

Maxoid

I've looked at the two define.php and they look identical. So I'm guessing I need to find out how jpath works and where it is set...

/**
* @package Joomla.Site
* @subpackage Application
* @copyright Copyright (C) 2005 - 2014 Open Source Matters, Inc. All rights reserved.
* @license GNU General Public License version 2 or later; see LICENSE.txt
*/

// No direct access.
defined('_JEXEC') or die;

File from sub domain which is causing the problem

/**
* Joomla! Application define.
*/

//Global definitions.
//Joomla framework path definitions.
$parts = explode(DIRECTORY_SEPARATOR, JPATH_BASE);

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

define('JPATH_SITE', JPATH_ROOT);
define('JPATH_CONFIGURATION', JPATH_ROOT);
define('JPATH_ADMINISTRATOR', JPATH_ROOT . '/administrator');
define('JPATH_LIBRARIES', JPATH_ROOT . '/libraries');
define('JPATH_PLUGINS', JPATH_ROOT . '/plugins' );
define('JPATH_INSTALLATION', JPATH_ROOT . '/installation');
define('JPATH_THEMES', JPATH_BASE . '/templates');
define('JPATH_CACHE', JPATH_BASE . '/cache');
define('JPATH_MANIFESTS', JPATH_ADMINISTRATOR . '/manifests');

Tuesday, 17 June 2014 01:41 CDT

nicholas

OK, here's what we have. Two different sites. Two different configuration.php files. Two different databases. Yet, somehow, you get the same changes applied to both sites. Now that we have ruled out all the reasonable, common issues we'll have to take a bold step into the "oh crap, this can't be that" territory.

1. I see that you have a $live_site parameter in your configuration.php file, i.e.:

public $live_site = 'https://akeeba.xxxx.com.au';

Are you absolutely sure that the $live_site of each site (original and clone) is set to point to the respective site? Have you tried removing it?

2. Do you have a .htaccess file? Can you please try removing BOTH .htaccess files temporarily and see if making a change to the clone site now affects the original site?

3. Did you check the URL on your browser when making the changes? If you log in to your clone site but the URL you see in the browser's address bar is the main site's you have something that's doing a redirection upon login. Since you've checked the two items above (live_site and .htaccess) the only thing that remains is custom coding, a non-standard back-end / front-end login module or a system plugin which performs this kind of redirection. Since the problem started "suddenly" I would suggest tracking your steps back to when the problem started and think about anything you installed or changed to your site.

4. There is a very slim chance that your host is using a code cache. Code caches are completely transparent to you and the code running on your server. They read a PHP file once and they keep it in memory, in a parsed format, to speed up page load. This is terrible news if you are talking about configuration files since any changes made to them (e.g. when you finish the restoration process!) is not take into account unless the code cache expires. When that happens depends on the server configuration. The only way to know if you have such a code cache (e.g. APC, XCache, WinCache...) is asking your host.

5. Right into the "this can't really be happening" zone we can find more exotic reasons, such as having a different database user in both sites but actually using the same database. I don't buy this explanation but there's a simple way to find out. When restoring your site use a different database table prefix for the cloned site's database. Then look into both databases, the main site's and the cloned site's. You should see the tables with the new prefix in exactly one database. Which one is it? If it's the main site's database then this exotic reason is actually what happens.

6. Finally, I have seen some rare extensions with custom database drivers. It is possible that they do keep the connection information of the old database somewhere. Unfortunately I can't know which one and where it stores that information.

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!

Wednesday, 18 June 2014 18:25 CDT

Maxoid

Sorry for the delay. I've been trying a different tact. As all of this is in aid of upgrading to V3.3 so I can access the template mod for componants.

I'm going to try a fresh load of 3.31 and tranfer the articles with something like cyend transfer.. unless there is a better way to import just the articles, menus and users.???

Thank you for the suggestions... just to complete the info..

1. yes both live are set to respective sites
2. .htaccess - unfortunately no change
3. We use a password manager that automates the url. I've watched the process to ensure its not flicking/redirecting to the other site..
4 Will check. We have just upgraded to the cpanel and mysql and php version. Maybe it was slipped in as part of a routine the consultants used.
5 I'll look and see if I can find this on the next install.
6 Wow... I can see that this is really unique....

Thursday, 19 June 2014 00:18 CDT

nicholas

I'm going to try a fresh load of 3.31 and tranfer the articles with something like cyend transfer.. unless there is a better way to import just the articles, menus and users.???

Better? Yes. Easier? No. I'd go directly with importing whole database tables and running Joomla! 3.3's schema upgrade scripts. This is the best way, but its difficulty rating for the average Joomla! user is off the charts. So, no, I don't think there's an easier option than CyEnd Transfer. Plus, I trust his code.

I'll leave the ticket open.

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!

Saturday, 19 July 2014 18:00 CDT

System Task

system

This ticket has been automatically closed. All tickets which have been inactive for a long time are automatically closed. If you believe that this ticket was closed in error, please contact us.

Edited by on 2014-07-19 18:00 CDT

Support