4

Well, I'm finally ready to put my five-site multi-site installation online. This community has been a great help in getting me to this point. So thank you all for that.

I'm a bit nervous about the gotcha's that await me in this next step -- discovering differences in operation between my local environment and the one online. I'm running XAMPP on my computer with Apache 2.4.10, PHP 5.6.3, and MySQL 5.6.21. Drupal core and all modules are up-to-date. In addition to each site's database, there is an extra db that is accessed by all sites for common data. For the online system, I plan to select a host company from the list on the Drupal.org, so I can expect them to have all the right stuff. I plan to get a shared server account.

In my current ASP sites (which these Drupal sites will replace), I've been able to develop the sites entirely on my local computer and then just upload the files to the online server and I don't think I've ever had a problem with any differences in operations. My scripts are set up to detect whether they are running locally or online and adjust certain things (such as inter-site URLs accordingly). I've attempted to develop things in Drupal to work that way too, but I'm not sure if there are differences I don't yet know about. I'm concerned about this because on the ASP sites I never had to instal any software. The server company instals whatever is necessary to run the site and I just uploaded files compatible with their software. But in Drupal, I've had to instal Drupal over again for each site, so I'm a bit unsure about how this will translate to the online environment.

So one question I have: Is it possible to simply FTP the entire Drupal folder plus the MySQL database to an online server and have a functioning set of sites, or do I need to go through the installation process on the online computer again for each site?

The doc page on Migrating a site says that it is for single site and that migrating multi-sites is covered elsewhere, but doesn't say where. Even for a single site, it lays out a 16-step process in which I don't think I'll understand most of the steps until I've done them. In any case, that page seems to say that the answer to my above question is very much NO, that I cannot do this by just copying files over.

Anything helpful to suggest on entering this process?

  • I always move the files via git (except settings.php/files folder, this is default behaviour normally). Go trough the proper drupal installation steps and then use backup and migrate module to move my Database from dev to production. – Suranga Panagamuwa Gamage May 29 '15 at 22:52
8

To answer your question: Yes. All you should need is your code sitting on a web server and your data sitting in a database for your Drupal site to go live.

As for suggestions, I have a few regarding workflow. Drupal has a lot of pain points with deployment because not only is the content stored in the database, but most of the configuration is as well. So while you can upload modules, the settings need to be manually set on production, automatically deployed with the Features module, or automatically deployed with update hooks in modules.

Uploading your site for the first time via FTP will work, but it's usually a lot more complicated when deploying updates. Here are a few things that you should learn to help combat this:

My first suggestion would be that you set up a development server (your local dev will work), a staging server to test your deployments, and a production server which will host your live site. It's crucial to have this (or something similar) so you can catch any problems and avoid a production down situation.

Second, you should learn how to use Git for version control to manage and deploy your code. You should use it for all projects, actually, even if you're not deploying them. I cannot tell you how many times I've rolled a change to production that broke the site and was able to roll back with one command. I'm not going to try and convince you why using version control is a good idea because there is an entire internet that says you should. Here is just one article: http://www.git-tower.com/learn/git/ebook/mac/basics/why-use-version-control

Third, assuming that you're using Drupal 7, you should use the Features module to store your settings in code and deploy them via git. Features is a necessary evil in order to accomplish this, and there are a ton of quirks that give it a huge learning curve, but it's worth it in the long run. This answer seems pretty solid. A more advanced and custom approach is to use calls to hook_update_n in your modules to automatically deploy database updates and settings. This article Does a good job explaining it.

Fourth, and probably most importantly, BACK UP YOUR DATABASE AND YOUR CODE. As I mentioned before, Drupal makes heavy use of the database. If you lose that, you lose your site. Make sure you have scheduled backups for your database (and your code if it isn't in Git).

I'm not trying to scare you, but I'll be honest: if you do decide to go this route (and I believe I'm not the only one who thinks you should), there will be a lot to learn and a ton of frustration at first. I can tell you that you're going to have a maintenance nightmare on your hands if you plan to deploy updates by uploading files via FTP.

I have been to a lot of talks and training on this subject at Drupal Camps, Drupal Cons, and Drupal meet-ups, and I'm still learning how to manage deployment. Once you learn the tools and get your workflow down, things will go a lot smoother and you'll be able to recover quickly if anything bad happens.

I hope this helps. Let me know if you have any questions!

  • 1
    Wow, what a whole lotta info! Thank you. Not scaring me, but it's gonna take some before I implement all of that. In the meantime, gotta get the sites up as well as I can for now and keep note of your suggestions for improving operations moving forward. – NewSites May 31 '15 at 2:38
  • Yeah, it'll take time. I'd learn Git first. I forgot to mention backups. Make sure you have routine backups and a way to easily revert the database back if a deployment goes awry. – Richard Robinson May 31 '15 at 6:48
  • If you do migrate the database via a dump, don't forget to clear cache once the site is in place. – Darvanen Jun 2 '15 at 22:03
4

Yes, all you need to is to upload your codebase (via FTP) and import your database (via a MySQL client like phpMyAdmin, MySQL Workbench, Sequel Pro, or the command line tool mysql) to the remote server. From there, all that's needed is to make sure the settings.php for each domain points to the correct server.

A few pieces of advice:

  • Turn off all CSS/JS aggregation before you move the files/DB. One common issue I've hit is broken CSS/JS because of missing files, unwritable file directories, or something else different about the file environment.
  • Be prepared for WSOD's that might occur because you don't have PHP dependencies in your new environment. d.o. has a good writeup on how to troubleshoot this problem if you hit it.
  • Check for any PHP errors in the site logs. If you do hit any problems with an environment change, it's likely to show up in the form of PHP errors/warnings.

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.