0

I have developed a D7 website locally (WAMP), now I want to move it to a production server.

The production server has a SVN repository, so when I want to move my local files to the server I do a commit of all the changed files. To sync the databases I get a dump of the local DB and I import it in the DB on the server. First of all, is this a proper way to move my site to production or is there a better workflow?

The problems I encounter are these:

  • When I enable caching and aggregation on my local site and then sync the two databases, when I go to the production site it's like all my stylesheets are gone. There's no css styles applied whatsoever.

  • When I disable caching and aggregation and sync the databases, the styles are back but it's like it's the design of a month ago. The design of the local site doesn't resemble the design of the production site. When I look at the page source, I see the CSS files getting called as: pages.css?mmtwln. What does this ?mmtwln mean?

  • I can't login to the admin pages on the production site. When I enter my username and password nothing happens but the page getting refreshed. No error message, no red border around the textboxes. The rewrite module is enabled on the production site. I also set the $base_url and $cookie_domain in the settings.php (I have a multisite configuration, should $base_url and $cookie_domain go in sites/default/settings.php or sites/mysite/settings.php?).

If anyone can help me with any of these questions, or point me in the right direction I'll be forever grateful.

3
  • Exclude /sites/*/files/css and /sites/*/files/js from repository. It's just a cache so it should never be committed or migrated.
  • Before each migration purge /sites/*/files/css and /sites/*/files/js. That way you will get rid of months old cache. After each migration, make sure these directories are writeable. mmtwln seems to be a string added by Drupal or some module to prevent proxy caching, or it may be a string added by a proxy itself. it shouldn't affect static files at all (except cache prevention, but even that isn't sure)
  • Your site fails at saving cookies. Check your cookie domain settings in sites/mysite/settings.php and make sure you have right data in example.org/admin/config/system/site-information

If above is insufficient:

  • manually (via ssh/sftp/ftp) compare offending CSS files. Does the version downloaded from server look the same as version you was sure you uploaded? If not, consult your sysadmin as your server is malfunctioning somehow.
  • if the version you download from server via ssh is the same you uploaded, but differs from the one you downloaded via http, check carefully your .htaccess - probably there are some redirection rules that make your server to serve file from different location. Common offender is boost module, if you used to have it installed and now only it's rewrites are left, you can easily get the exact behaviour you described.
| improve this answer | |
  • Thanks for your response, they're some great pointers. I tried the first two though, but to no avail. I still get the "old" design. – Smos May 15 '13 at 15:05
  • Expanded my answer, added 2 more points. – Mołot May 16 '13 at 6:27
  • Apparently the files that are in my repository don't match with the files on the webserver. Don't know why yet, but that's the reason I get the old design. Thanks for your help! – Smos May 17 '13 at 7:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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