When we deployed to a production site, CSS and images got broken.

One approach to mitigate this was editing settings.php, the base_url

$base_url = '/oursite';

(Where "oursite" is our domain, i.e. http:localhost/oursite/ )

But that also broke some functionality on our local site. For example:

The requested page "/oursite/?q=oursite/node/add/cmsdeliverable%3Ffield_demo_id_reference%3D1208" could not be found.

What other approaches can I take?

  • What is your Drupal core version?
    – AKS
    Commented Feb 3, 2016 at 17:23
  • Drupal version is 7 Commented Feb 3, 2016 at 18:13
  • What's the story with clean urls on the dev and production site? Does leaving out the ?q= change anything? Commented Feb 3, 2016 at 20:35
  • The issue is after adding the base_url statement in settings.php the "q=oursite" is getting introduced. It should be /oursite/node/add/cmsdeliverable... (clean URLs is on and works already) Commented Feb 5, 2016 at 19:29
  • Actually, clean urls is not working. Commented Feb 5, 2016 at 19:33

1 Answer 1


Firstly, your $base_url should be fully qualified: http://www.example.com.

Secondly, you should configure your $base_url to be 'dynamic' - different for development, staging and production. Detect the 'environment' and then set the $base_url accordingly.

As for the broken styling, I have seen broken theme problems related to file system rights. It may be that your site is using CSS/JS aggregation / compression. These compressed files are created on the fly by Drupal (check admin/config/development/performance). If there are file/folder rights issues on the production, the files will not be created.

May be useful to check the error log (/admin/reports/dblog) - could just point you in the right direction.

  • The CSS/JS compression disabled didn't do the trick. The module I'm using relies on base_url, but can I use base_path instread if I have to keep my base_url statement in settings.php? Commented Feb 5, 2016 at 18:54
  • What module are you using. Happy to take a look at the documentation. Also - it might be worth checking file rights on your production server. It is possible that the web server (service - the user / group running the web service) does not have the right access to the /sites/default/files folder (read / write / execute). Commented Feb 7, 2016 at 8:25
  • Using drupal.org/project/addanother. I was exploring how I can modify so it avoids inserting that extra string in the URL (see original post). Commented Feb 8, 2016 at 14:27
  • I had a quick look at that module. I assume you used it to 'replicate' some nodes (duplicate nodes, and then change some of the content - title, body, etc). It is possible that, the URL of the original was duplicated as well - so you might have one URL pointing to two different pieces of content. It is also possible that you have different URL's pointing to content that looks the same, where in fact they are different. If the title, body, etc of 2 nodes are exactly the same, 2 different URL's may render the same, but they are 2 different nodes. Commented Feb 11, 2016 at 5:32
  • Use Find Content to search for nodes in your admin section; easy to list all nodes with similar titles - and then check their URL's. If you have Path installed, you can view your list of URL's at /admin/config/search/path - check that the URL's giving your problems are not the 'same URL' pointing to different pieces of content (nodes). Commented Feb 11, 2016 at 5:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.