New Drupal Site Process: Deployment

Submitted by Nathaniel Hoag on Thu, 12/20/2012 - 21:01

Deploying a simple Drupal site on shared hosting with shell access.

PREPARE THE SITE

Set the theme to core:
drush vset theme_default bartik

Disable non-core modules:
drush pml | grep -v Core | grep Enabled | sed -n -e '/^[^(]*(\([^)]*\)).*/s//\1/p' > mods.txt
cat mods.txt | xargs drush dis

Make a database dump:
mysqldump -uuser -ppass database | gzip > output.sql.gz

Make an archive of the codebase:
tar -czvf site-archive.tar.gz -C site-directory .

New Drupal Site Process: Building

Submitted by Nathaniel Hoag on Wed, 12/19/2012 - 08:25

I recently put together a basic Drupal site and this is a documentation of some of the process and components.

The site is relatively static with a few info pages, a contact form, and one section where new content can be added. The build and deploy process is a bit informal as I'm the sole developer, and will be building, deploying and then theming. The site mostly leverages core functionality, with a couple of small enhancements such a pathauto, views, wysiwyg, and a theme.

Protecting a site from having it's database overwritten. | drupal.org

Submitted by Nathaniel Hoag on Tue, 02/07/2012 - 23:34

The full comment lays out the code. Pretty nifty way to prevent overwriting the live database.

Now, when @dev is used as the destination of the rsync or sql-sync command, --simulate=0 will take precedence, but when @live is the destination, then --simulate=1 will take precedence.

From: Protecting a site from having it's database overwritten. | drupal.org