Support

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.

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? ;)

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 ;)

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.

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.

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.

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.

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.

You're welcome, Peter!