Support

Site Restoration

#14153 Restored site looks different to live site

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

PeterAnthony

Mandatory information about my setup:

Have I read the related troubleshooter articles above before posting (which pages?)? No
Have I searched the tickets before posting? No
Have I read the documentation before posting (which pages?)? No
Joomla! version: (unknown)
PHP version: (unknown)
MySQL version: (unknown)
Host: (optional, but it helps us help you)
Akeeba Backup version which took the backup: (unknown)
Kickstart version used to extract the backup: (unknown)

Description of my issue:  All of the data on my restored site is correct, but the background image is not present and some other CSS changes that were made are not showing up e.g. module header colours are not the same.

Can you suggest why this would be the case?  I tried deleting all of the files on my destination folder so that only the backup file and kickstart.php were there when I restored it but sill the restored site looks different.

This is the restored site: http://morevida.com/goodtalktnt

and this is the original http://goodtalktnt.com

Would appreciate understanding why this is happening.  Thanks for your time.

nicholas
Akeeba Staff
Manager

Hello Peter,

I believe you have to do some .htaccess adjustements as per our troubleshooting documentation (see "REWRITEBASE IN .HTACCESS", "THE $LIVE_SITE VARIABLE IN CONFIGURATION.PHP" and "THIRD PARTY COMPONENTS WITH ABSOLUTE PATHS / URLS").

Looking at your site it seems that the missing image URL is a hardcoded path relative to the domain (not the site's!) root in some Javascript or CSS file. Since your site is in a subdirectory, not the domian root, this relative path is no longer valid. It will be a little tough debugging it unless you know which extension (component, module, plugin or template) is supposed to load the background image. It could be something as simple as changing, say, a template parameter or something as complicated as talking to the developer of the culprit extension.

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!

PeterAnthony

Hey Nicholas,

You manage expectations very well.  Glad to see that you're still quick on the draw.  The only thing that has happened that could account for this is that I had a designer work on the production site to change the design.  He said he made changes to template.css, expose.css and one other file that he can't remember.  He's promised to find out which one and let me know.   So I'm guessing that this is all related to customisation of my current theme TX_Mainstream.

Any ideas on how to proceed?  I'm curious why the backup process would capture everything else but this?  Thanks again for your speedy response.

nicholas
Akeeba Staff
Manager

Hello Peter,

He he, too many years of experience and this kind of issues look dead simple. Everything you said is correct except this:

I'm curious why the backup process would capture everything else but this?

The backup is a one to one copy of all of your site files and database contents. The only thing which will be changed on restoration is your configuration.php file, giving it the new db connection information and the new site's URL (if necessary). Your .htaccess file, CSS files, JS files, cross-article links, 3rd party extension configuration and everything else is copied verbatim. That's what a backup is all about.

Normally this is not a problem if the developer knows what he's doing. Joomla! offers JURI::base() to get the (dynamically computed) base URL to the current site. This allows all links to be portable across domains, subdomains and subdirectories. However, nothing stops a developer or designer to be a complete noob and create a huge mess.

For example, let's consider a CSS file in templates/foobar/css/template.css. Let's say that we want to set the background-image of the .baz class to an image file stored in images/baz.png. There are two ways to do that. The correct one:

.baz { background-image:url(../../../images/baz.png) }

and the wrong one

.baz { background-image:url(/images/baz.png) }

The correct way tells the browser "look where I am loaded from, go up three directories, then go inside the images directory and load baz.png". In other words if your site is loaded from http://www.example.com the image will be loaded from http://www.example.com/images/baz.png. If, however, your site is loaded from http://www.example.com/such/a/silly/place then the image is loaded from http://www.example.com/such/a/silly/place/images/baz.png.

On the contrary, the wrong way tells the browser "go to the domain's root, then go inside the images directory and load baz.png". In other words if your site is loaded from http://www.example.com the image will be loaded from http://www.example.com/images/baz.png. If, however, your site is loaded from http://www.example.com/such/a/silly/place then the image is STILL being loaded from http://www.example.com/images/baz.png. In the latter case the directory doesn't exist and you get a missing image. Bazinga!

Can you guess whose designer did a mistake? ;)

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!

PeterAnthony

Makes sense to me.  I guess something similar applies to all of the other css changes he made to site.  Unfortunately I don't feel comfortable messing about with this to correct it, even though I understand it conceptually.

I'm working with a new designer and will ask him if he can correct this.  Thanks much.  Good to know there's nothing wrong with the backup/restore process.

I thought maybe I shouldn't have deleted a file on the backup site.

nicholas
Akeeba Staff
Manager

The beauty of writing proper code is that it works on both the main and the backup site. This means that you can end up with one implementation to rule them all, a.k.a. proper portable code ;)

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!

PeterAnthony

Nicholas,

Help!  My live site has reverted to an older version and I did not do it.  Is there a way to tell if someone restored the site.  it's definitely an older version.

nicholas
Akeeba Staff
Manager

Hello Peter,

You can't tell if someone restored the site, but you can narrow it down using nothing but logic. Except you and your host, who has access to your site? Start by asking them if they had to restore an older backup of your site. If nobody did that, then your host may have restored your site from a backup due to, for example, a hardware failure.

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!

PeterAnthony

Nicholas,

Is it possible that a restore to one folder could affect the original site?  The host provider did not do a restore but I do remember that in one of my attempts to get the backup site to look like the live site, that I had selected the wrong backup archive file.  But I'm pretty sure (90%) that I was on the development site when I initiated the backup.

It looks like I may need to restore to the live site and I'm deathly afraid to delete all of the files on that folder before I do the restore.  

nicholas
Akeeba Staff
Manager

Is it possible that a restore to one folder could affect the original site?

No, at least not unless you botched it. If you accidentally restored the archive on the main site (i.e. put kickstart.php on the main site, not the subdirectory) or used Kickstart's FTP mode but accidentally pointed it to the main site instead of the subdirectory then yes, this could be possible. It's also possible that you tried restoring using the integrated restoration but you didn't realise you were logged in the main site, not the site in the subdirectory. That's all of the cases where this could happen.

But I'm pretty sure (90%) that I was on the development site when I initiated the backup.

Initiating a backup doesn't affect your site. It's a read only operation. I assume you mean restoration, not backup.

It looks like I may need to restore to the live site and I'm deathly afraid to delete all of the files on that folder before I do the restore.

Well, first take a backup of it and store it locally. If all else fails, you can revert to the existing situation. Then try restoring a backup without deleting files. Usually it works. I tell you to remove all existing files/folders as a precaution, so that you don't have to do the restore twice in case of a problem.

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!

PeterAnthony

"It's also possible that you tried restoring using the integrated restoration but you didn't realise you were logged in the main site, not the site in the subdirectory."  Don't fully understand what this means, but it seems this is the only one that could have happened.   Seems I should make sure I'm logged out from the live site from the front end and backend before I do a restore?

And yes I did mean restore not backup.

I already have the backup (it's the one I used for the dev site which restored properly except for the CSS changes) so I'll just give it a go.

 

nicholas
Akeeba Staff
Manager

Don't fully understand what this means, but it seems this is the only one that could have happened.   Seems I should make sure I'm logged out from the live site from the front end and backend before I do a restore?

No, no, no... I'm meaning something completely different. Instead of using Kickstart you can use Akeeba Backup's integrated restoration feature. You log in to the site's back-end, go to Components, Akeeba Backup, Administer Backup Files, check the backup you want to restore and then click on the Restore button in the toolbar. This feature will restore the backup, replacing the site you initiated the restore from. Obviously you are unaware of this feature so you can't have used it ;)

I already have the backup (it's the one I used for the dev site which restored properly except for the CSS changes) so I'll just give it a go.

Sounds like a plan. Remember that restoring that backup on the domain's root (main site) will also "fix" the CSS issue, for the reasons I explained in my previous replies.

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!

PeterAnthony

Nicholas,

Thanks much man.  You've been great.  Can't imagine the patience it must take to deal with these queries all day.  

I clearly have something very strange going on as the home page of my live site just changed again

http://goodtalktnt.com

and

I can't access the backend

http://goodtalktnt.com/administrator

All I get is a white blank page

Am chatting with the guys at Hostgator now to find out what's going on.  Very freaky

nicholas
Akeeba Staff
Manager

The truth is that my patience sometimes runs out, but not today so don't worry :D

Regarding the blank page, please note that a white page or a page with a 500 Internal Server Error is, in fact, either a .htaccess issue to a PHP fatal error in disguise.

First, let's see if it is a .htaccess issue. Try renaming the .htaccess file in your site's root to htaccess.bak If there is a .htaccess file in the site's administrator directory, try renaming it as well. If that solves the problem, the issue was with a directive in your .htaccess file. We'd like to recommend you to try removing directives from your .htaccess until you find the one which causes the problem.

If that doesn't help, the error you are receiving is in fact a PHP error in disguise. First, check your server's error logs (not the access logs) immediately after visiting the page which throws the error. There should be an exact description of the PHP fatal error which occurred. Sometimes you can find the error messages in files called error_log or error.log inside the site's root and/or administrator directories. If unsure about the error log location, please consult your host. Most likely the error logs are available in your site's cPanel, Plesk control panel or similar hosting account management facility.

If your host does not give you access to the error logs and you have access to the Joomla! administrator area, please log in to your site's back-end, go to Global Configuration, click on the Server tab and set the Error Reporting to Maximum (Joomla! 1.5) or Development (Joomla! 2.x and later). Try visiting the problem page again.

If you still get a blank page, edit your configuration.php file and put the following code right after the final closing curly brace ( this is what a curly brace looks like --> } ) but before the closing PHP tag (it looks like ?> that is a question mark and a greater-than sign):

ini_set( 'display_errors', true );
error_reporting( E_ALL ); 

Try visiting the problem page again.

If you still get a white page, please remote the two lines from your configuration.php file. Edit the .htaccess file in your site's root. If you don't have a file named .htaccess create a new one. Beware that htaccess.txt is a DIFFERENT FILE and will NOT work! Add the following to the end of the file:

php_flag display_errors On
php_value error_reporting 32767

and retry loading the problem page.

If you still get a white page, remove the two lines from your .htaccess file. Now, create a file called php.ini with the following content:

display_errors=on
error_reporting=E_ALL

and upload it into your site's root and your site's administrator directory. Retry loading the problem page.

If you still get a white page, delete the php.ini files your created and choose a different host. If your host doesn't allow you to debug any PHP-related issues there is no point paying them.

Please note that if you can not understand what the PHP error message means, just copy and paste it here verbatim so that we can take a look and point you to the right direction.

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!

PeterAnthony

Wow!  I'm really impressed with that answer.  I hope you have it stored away somewhere so that you don't have to type it again.

I fear it's way above my pay grade though.  One simple question: Wouldn't it just be easier to just restore the site using kickstart?

nicholas
Akeeba Staff
Manager

Well, that reply is stored away because I used to have to type it over and over again. Not really very fun. I beleive that anyone can follow these instructions but you're also probably right: it's easier scraping the lot and restoring from a backup.

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!

PeterAnthony

Thanks again Nicholas for your generosity of time and attention.  I just restored the site and (whew) it worked.  Will take care to upgrade my other sites from now on.

nicholas
Akeeba Staff
Manager

You're welcome, Peter!

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!

Support Information

Working hours: Typically we work Monday to Friday, 9am to 7pm Cyprus timezone (EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets, but we cannot respond to them, outside of our working hours.

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!

Summer vacations: Our support will be closed for replies and new tickets from August 6th to August 21st, 2022 due to summer vacations.