I tried to find the answer to this problem - but had no luck finding it yet.

I moved a site to my localhost for further development. All is working fine - just the images are not showing up.

I know it is a (relative) path problem- but how to solve it??

I am using WAmp Server & Drupal 6.10.

The path on the web is http://www.example.net/....

The path on Wamp is http://localhost/testing/....

My images are on the basic, relative Drupal path /sites/default/files/myimages/
For example image1.gif is under /sites/default/files/myimages/image1.gif.

This works fine on the remote hosted server. But on my localhost set-up the images do not show.

When I add the localhost directory of /testing to the path like this /testing/sites/default/files/myimages/image1.gif - the images show up.

It would be tedious to change all the path settings for all the images page by page. What I need is a simple general solution without changing every page individually.

Is there a simple way to set this path somewhere in general for the entire localhost installation? Because, when I move the lot back to the hosted server I need the relative path of basic Drupal in tact.

Thanks for any suggestions -

Comments

pobster’s picture

Just read the settings.php file about mulitsites and everything will become clear. Ignore for a minute the phrasing - multi-sites and just concentrate on what you're trying to achieve... Accessing Drupal away from its root (i.e. localhost will work fine, but you're after using localhost/testing...) so instead of using sites/default use - sites/localhost.testing (or something like that, read the file comments for clarification). Reason being is that Drupal will then add in the extra 'directory' to paths through its API, you then gain that 'base directory'.

Pobster

tryitonce’s picture

Hi Pobster,

I really appreciate your help and just spend quite a bit of time searching around for mulitsites info on Drupal.org. (http://drupal.org/node/43816 - Beyond the basics >> HowTos >> Multi-site installation and set-up plus various searches).

I experimented with various settings in the settings.php and with directories on the local set-up. But I am nowhere near a solution.

Could you just point out the paragraph in settings.php I need to understand. In my settings.php there is not the term "mulitsites".

Do I need to make changes to .htaccess as well?

Thanks

My settings.php file:

<?php
// $Id: default.settings.php,v 1.8.2.1 2008/08/13 06:52:36 dries Exp $

/**
 * @file
 * Drupal site-specific configuration file.
 *
 * IMPORTANT NOTE:
 * This file may have been set to read-only by the Drupal installation
 * program. If you make changes to this file, be sure to protect it again
 * after making your modifications. Failure to remove write permissions
 * to this file is a security risk.
 *
 * The configuration file to be loaded is based upon the rules below.
 *
 * The configuration directory will be discovered by stripping the
 * website's hostname from left to right and pathname from right to
 * left. The first configuration file found will be used and any
 * others will be ignored. If no other configuration file is found
 * then the default configuration file at 'sites/default' will be used.
 *
 * For example, for a fictitious site installed at
 * http://www.drupal.org/mysite/test/, the 'settings.php'
 * is searched in the following directories:
 *
 *  1. sites/www.drupal.org.mysite.test
 *  2. sites/drupal.org.mysite.test
 *  3. sites/org.mysite.test
 *
 *  4. sites/www.drupal.org.mysite
 *  5. sites/drupal.org.mysite
 *  6. sites/org.mysite
 *
 *  7. sites/www.drupal.org
 *  8. sites/drupal.org
 *  9. sites/org
 *
 * 10. sites/default
 *
 * If you are installing on a non-standard port number, prefix the
 * hostname with that number. For example,
 * http://www.drupal.org:8080/mysite/test/ could be loaded from
 * sites/8080.www.drupal.org.mysite.test/.
 */

/**
 * Database settings:
 *
 * Note that the $db_url variable gets parsed using PHP's built-in
 * URL parser (i.e. using the "parse_url()" function) so make sure
 * not to confuse the parser. If your username, password
 * or database name contain characters used to delineate
 * $db_url parts, you can escape them via URI hex encodings:
 *
 *   : = %3a   / = %2f   @ = %40
 *   + = %2b   ( = %28   ) = %29
 *   ? = %3f   = = %3d   & = %26
 *
 * To specify multiple connections to be used in your site (i.e. for
 * complex custom modules) you can also specify an associative array
 * of $db_url variables with the 'default' element used until otherwise
 * requested.
 *
 * You can optionally set prefixes for some or all database table names
 * by using the $db_prefix setting. If a prefix is specified, the table
 * name will be prepended with its value. Be sure to use valid database
 * characters only, usually alphanumeric and underscore. If no prefixes
 * are desired, leave it as an empty string ''.
 *
 * To have all database names prefixed, set $db_prefix as a string:
 *
 *   $db_prefix = 'main_';
 *
 * To provide prefixes for specific tables, set $db_prefix as an array.
 * The array's keys are the table names and the values are the prefixes.
 * The 'default' element holds the prefix for any tables not specified
 * elsewhere in the array. Example:
 *
 *   $db_prefix = array(
 *     'default'   => 'main_',
 *     'users'     => 'shared_',
 *     'sessions'  => 'shared_',
 *     'role'      => 'shared_',
 *     'authmap'   => 'shared_',
 *   );
 *
 * Database URL format:
 *   $db_url = 'mysql://username:password@localhost/databasename';
 *   $db_url = 'mysqli://username:password@localhost/databasename';
 *   $db_url = 'pgsql://username:password@localhost/databasename';
 */
$db_url = 'mysqli://root:dbuser@localhost/testing';
$db_prefix = '';

/**
 * Access control for update.php script
 *
 * If you are updating your Drupal installation using the update.php script
 * being not logged in as administrator, you will need to modify the access
 * check statement below. Change the FALSE to a TRUE to disable the access
 * check. After finishing the upgrade, be sure to open this file again
 * and change the TRUE back to a FALSE!
 */
$update_free_access = FALSE;

/**
 * Base URL (optional).
 *
 * If you are experiencing issues with different site domains,
 * uncomment the Base URL statement below (remove the leading hash sign)
 * and fill in the URL to your Drupal installation.
 *
 * You might also want to force users to use a given domain.
 * See the .htaccess file for more information.
 *
 * Examples:
 *   $base_url = 'http://www.example.com';
 *   $base_url = 'http://www.example.com:8888';
 *   $base_url = 'http://www.example.com/drupal';
 *   $base_url = 'https://www.example.com:8888/drupal';
 *
 * It is not allowed to have a trailing slash; Drupal will add it
 * for you.
 */
$base_url = 'http://localhost/testing';  // NO trailing slash!

/**
 * PHP settings:
 *
 * To see what PHP settings are possible, including whether they can
 * be set at runtime (ie., when ini_set() occurs), read the PHP
 * documentation at http://www.php.net/manual/en/ini.php#ini.list
 * and take a look at the .htaccess file to see which non-runtime
 * settings are used there. Settings defined here should not be
 * duplicated there so as to avoid conflict issues.
 */
ini_set('arg_separator.output',     '&amp;');
ini_set('magic_quotes_runtime',     0);
ini_set('magic_quotes_sybase',      0);
ini_set('session.cache_expire',     200000);
ini_set('session.cache_limiter',    'none');
ini_set('session.cookie_lifetime',  2000000);
ini_set('session.gc_maxlifetime',   200000);
ini_set('session.save_handler',     'user');
ini_set('session.use_only_cookies', 1);
ini_set('session.use_trans_sid',    0);
ini_set('url_rewriter.tags',        '');

/**
 * Drupal automatically generates a unique session cookie name for each site
 * based on on its full domain name. If you have multiple domains pointing at
 * the same Drupal site, you can either redirect them all to a single domain
 * (see comment in .htaccess), or uncomment the line below and specify their
 * shared base domain. Doing so assures that users remain logged in as they
 * cross between your various domains.
 */
# $cookie_domain = 'example.com';

/**
 * Variable overrides:
 *
 * To override specific entries in the 'variable' table for this site,
 * set them here. You usually don't need to use this feature. This is
 * useful in a configuration file for a vhost or directory, rather than
 * the default settings.php. Any configuration setting from the 'variable'
 * table can be given a new value. Note that any values you provide in
 * these variable overrides will not be modifiable from the Drupal
 * administration interface.
 *
 * Remove the leading hash signs to enable.
 */
# $conf = array(
#   'site_name' => 'My Drupal site',
#   'theme_default' => 'minnelli',
#   'anonymous' => 'Visitor',
/**
 * A custom theme can be set for the off-line page. This applies when the site
 * is explicitly set to off-line mode through the administration page or when
 * the database is inactive due to an error. It can be set through the
 * 'maintenance_theme' key. The template file should also be copied into the
 * theme. It is located inside 'modules/system/maintenance-page.tpl.php'.
 * Note: This setting does not apply to installation and update pages.
 */
#   'maintenance_theme' => 'minnelli',
/**
 * reverse_proxy accepts a boolean value.
 *
 * Enable this setting to determine the correct IP address of the remote
 * client by examining information stored in the X-Forwarded-For headers.
 * X-Forwarded-For headers are a standard mechanism for identifying client
 * systems connecting through a reverse proxy server, such as Squid or
 * Pound. Reverse proxy servers are often used to enhance the performance
 * of heavily visited sites and may also provide other site caching,
 * security or encryption benefits. If this Drupal installation operates
 * behind a reverse proxy, this setting should be enabled so that correct
 * IP address information is captured in Drupal's session management,
 * logging, statistics and access management systems; if you are unsure
 * about this setting, do not have a reverse proxy, or Drupal operates in
 * a shared hosting environment, this setting should be set to disabled.
 */
#   'reverse_proxy' => TRUE,
/**
 * reverse_proxy accepts an array of IP addresses.
 *
 * Each element of this array is the IP address of any of your reverse
 * proxies. Filling this array Drupal will trust the information stored
 * in the X-Forwarded-For headers only if Remote IP address is one of
 * these, that is the request reaches the web server from one of your
 * reverse proxies. Otherwise, the client could directly connect to
 * your web server spoofing the X-Forwarded-For headers.
 */
#   'reverse_proxy_addresses' => array('a.b.c.d', ...),
# );

/**
 * String overrides:
 *
 * To override specific strings on your site with or without enabling locale
 * module, add an entry to this list. This functionality allows you to change
 * a small number of your site's default English language interface strings.
 *
 * Remove the leading hash signs to enable.
 */
# $conf['locale_custom_strings_en'] = array(
#   'forum'      => 'Discussion board',
#   '@count min' => '@count minutes',
# );

/**
* Multilingual settings
*
* This is a collection of variables that can be set up for each language when i18n is enabled.
* These are the basic ones for Drupal core, but you can add your own here.
*/
$conf['i18n_variables'] = array(
  // Site name, slogan, mission, etc..
'site_name',
'site_slogan',
'site_mission',
'site_footer',
'anonymous',
  // Different front page for each language
'site_frontpage',
  // Primary and secondary links
'menu_primary_links_source',
'menu_secondary_links_source',
  // Contact form information
'contact_form_information',
  // Different User Registration email message for each language
'user_mail_register_admin_created_body',
);
pobster’s picture

It's not so much about what's in the settings.php file as more where you have it? Read the blurb right at the top;

/**
* @file
* Drupal site-specific configuration file.
*
* IMPORTANT NOTE:
* This file may have been set to read-only by the Drupal installation
* program. If you make changes to this file, be sure to protect it again
* after making your modifications. Failure to remove write permissions
* to this file is a security risk.
*
* The configuration file to be loaded is based upon the rules below.
*
* The configuration directory will be discovered by stripping the
* website's hostname from left to right and pathname from right to
* left. The first configuration file found will be used and any
* others will be ignored. If no other configuration file is found
* then the default configuration file at 'sites/default' will be used.
*
* For example, for a fictitious site installed at
* http://www.drupal.org/mysite/test/, the 'settings.php'
* is searched in the following directories:
*
*  1. sites/www.drupal.org.mysite.test
*  2. sites/drupal.org.mysite.test
*  3. sites/org.mysite.test
*
*  4. sites/www.drupal.org.mysite
*  5. sites/drupal.org.mysite
*  6. sites/org.mysite
*
*  7. sites/www.drupal.org
*  8. sites/drupal.org
*  9. sites/org
*
* 10. sites/default

And no, leave the .htaccess file exactly as it is (and probably the base_url setting as well).

Pobster

unleash’s picture

hi there - does it have to do with the settings -
well i also am not able to upload images

can this be rootet in the settings.php

glofalcon’s picture

hello, tryitonce did you get this resolved ? having the same problem of image not showing up after moving to localhost. All pages are working fine though. I checked the url of the images. they were wrong everywhere. Apparently, the subfolder is not getting added to http://localhost in my image filepaths.

i.e., it shows up as http://localhost/sites/all/themes/dummyname/images/imagefile.jpg

when it should have been,

http://localhost/subfolder/sites/all/themes/dummyname/images/imagefile.jpg

how do I get drupal to update the file path properly for all the images ? Any help would be appreciated.

Thanks

tryitonce’s picture

No, I didn't resolve it. I just know the images are there and the localhost is now just used for testing and I do not transfer back to the server.

Yes, it would be good to resolve this - but right now I won't have time to look at this again. Should you have some more ideas let's keep exchanging them here and hopefully in time we will find the answer.

Good luck ....

TmaX-2’s picture

I found a way around this, a temporary solution....
Theres an error, in spite of setting my base url to
localhost/mysite
after importing on Localhost my images
were still not loading like your case.

When i checked path everything was alright.Then i thought it was a permissions issue
spent a day trying to work my way around the permissions issue but that wasn't the case.

The image files had right paths but the base url was not working so the image files were pointing to
localhost/sites/default/files/image.jpg
instead of
localhost/mysite/sites/default/files/image.jpg

Tried to get this error fixed but couldnt find any solution
Finally since i didnt want to re edit all my image links again i just
copied the folder sites/default/files/image.jpg on the localhost htdocs..

Now all my images are loading fine..At least this servers as a temporary solution..
If you do find a solution to this problem do keep us posted

edboost’s picture

Not sure if this is the same problem, but I just changed domain names (on a multi-site install). I thought that changing the base_URL in settings.php and the directory name would do the trick.

It did -- in that I could get to the site, but no images (and missing theme components too).

I found that my File System image path (in Configuration) was set to the old domain name. When I fixed that, the images showed up.

nathanofearth’s picture

I was struggling with this issue for weeks with WAMP, fortunately someone informed me about DAMP (amp stack especially for Drupal!).

http://acquia.com/documentation/acquia-drupal-stack

Easy to set up, works fine for me. All links work, I am able to use Backup/Migrate module to import/export between development and live sites.

DAMP comes with an Acquia Drupal distribution, but you don't have to use it.

Follow these instructions on importing an existing site to local
http://acquia.com/documentation/acquia-drupal-stack/import

Good luck!
nathan

tryitonce’s picture

Thanks - will try soon

iolartes’s picture

I had a similar problem but on LAMP -using Linux as an OS.
It turns out that when Drupal renders images inserted in blog post, it doesn't use the relative path to the Drupal installation but to the server itself. I was able to fix the missing pictures by changing the configuration in the Apache file server. I pointed the document root to the Drupal installation directory. Granted this is not hte perfect solutions for those with multiple Drupal installs, but it helps if you only need to replicate one site.

faridjame’s picture

Have you tried setting the $base_url in settings.php to match the address of your Drupal site:

$base_url = "http://localhost/testing/othersubdirectory";

Make sure you clear the cache after this change.

xeeshangulzar’s picture

I just changed my URL and site is working fine. Thank You

bdornbush’s picture

I was trying to set up WAMP today. I copied the database and files from a remote server to my local PC, into a subdirectory "C:\wamp\www\mysite". When I did this, everything worked fine except for the urls for images, which are "/sites/default/files/image.jpg" instead of the needed "/mysite/sites/default/files/image.jpg"

I edited "mysite\sites\default\" to "mysite\sites\localhost.mysite" thinking that perhaps the multisite mechanism would generate the proper image urls needed. I also edited settings.php to include "$base_url = 'http://localhost/mysite';"

The first time I did the rename of default, Drupal ran install.php instead of loading the site so somehow it didn't recognize the folder within "sites". I tried to undo it, and redo it and clear cache, but the theme wasn't loading properly (I am using a subtheme of Sky). I changed the theme to Bartik, and the theme loaded but Drupal was still not generating the needed urls for the images.

So no matter what of the above advice I follow, I still don't get the images to load.

ntigh52’s picture

I hope that it just in wamp and not will happend when import the web site to another domain / hosting server!

bdornbush’s picture

I got this to work by setting up a virtualhost in WAMP. You configure apache to support virtual hosts, and then create a few configuration files, and it works. See http://blog.jlbn.net/?p=23 for details.

davidjmcq’s picture

I struggled with a similar (same?) problem, which I solved in Linux by creating a symbolic link thus:

root@testhost:/var/www/drupal/sites# ln -s example.com testsite
root@testhost:/var/www/drupal/sites# ls
example.com all default testsite

example.com is the name of your original live site. Drupal goes looking for a lot of files relative to this directory. By simply adding a symlink you fool Drupal into doing the right thing.

IMHO all files should be relative to the files/ directory, but apparently they aren't.

I'm assuming you can do the same thing in Windows, but thankfully I don't have to worry about that :)

kerrycurtain’s picture

Upon importing my database to a testsite many images were not displaying.

Days ago I read on a post somewhere that the .htaccess file of the testsite was the culprit.

The post advised that the following lines of the file required a comment (#):

SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
Options None
For security reasons, Option followsymlinks cannot be overridden.
Options +FollowSymLinks

like so.....

SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
#Options None
# For security reasons, Option followsymlinks cannot be overridden.
#Options +FollowSymLinks

Be aware though that there are 2 .htaccess files (which I have only now just discovered)....

1. /testsite (or whatever your directory is called)
2. /testsite(or whatever your directory is called)/sites/default/files

Both need to be commented to get all images to display.

Oh yes, I also changed the base url to that of my testsite in the settings.php file.

Hope this saves someone hours of grief!!

Collins405’s picture

just uncommenting #RewriteBase / then flushing the cache worked for me.

/chris

abdulgaffar’s picture

I have deleted what inside /files/.htaccess and flush cache everything worked fine. Images are loading properly.
I mean leave .htaccess file empty in /files folder.
Cheers ~~~

scoutex’s picture

Thank you!