This document discusses tips for building large web applications with Drupal, including using Drupal module install scripts, enabling and disabling modules, using Drush for updates and automation, optimizing the multisite update process, and improving performance of Drupal multisites through techniques like distributing load across multiple servers and using caching. It also introduces GROGGER, a crowdsourcing group blog project built on a Drupal multisite with a Code Igniter application for creating new sites.

1. Tips and tricks for building Large web applications with Drupal Presented by MihaiCeusan and ViorelZidariu

2. Using migraine for database migration (advantages and disadvantages) how to use Drupal Module Install Scripts High Performance Drupal multisite in a cloud environment: distributing the load, dividing the problem into more manageable tasks using Drush for updates and automation optimizing the Multisite update process Goals of this Presentation

3. Introduction to the project GROGGER ( getgrogger.com ) is a crowdsourcing group blog ( group + blog = grog ) Two components: Drupal multisite instance for the grogs and a Code Igniter app that allows users to create a grog in just two steps Grog creation is a two steps process: Creating the Drupal site ( file system, new database, generation the settings.php file) – done via sh scripts Creating the grog admin user based on the registration data – done via the Drupal BOOTSTRAP system

4. BootstrapingDrupal BootstrapingDrupal involves loading the necessary files in order to have the basic Drupal functionality in a remote php file( existing on the same server but outside the Drupalinstalation ) Bootstraping can be easily done: include the file /includes/bootstrap.inc and use the Drupal functions

5. Challenge - deployment Next step: build a proper deployment process Main architecture: Development environment Staging environment Production environment Challenge : deploy changes from one environment to the others ( including different dev environments) Code deployment done via version control ( GIT in our case )

6. Using Migraine A Drupal site ( app ) is not made just from code but also from settings ( modules, blocks, views, themes, etc ) Migraine ( Drupal test-to-production migration tool ) is a set of python scripts. How it works ? Easy !!!Migraine uses the Drupal database categories ( config, content, temp, cache ). The deploy script does a db dump of the config files, you move to the new env and run the update scripts (updates the db)

7. Using Drupal Install Scripts Drupal provides functionality to create module install scripts. Save time on the deploy and improve the Q/A process Load a production db easily and run the updates to test the functionality before deploying To deploy the updates, just run the update.php file and Drupal handles the rest for you!

8. .install Files create a file named module_name.install and put it in the module’s file directory Hooks available to .install files Hook_install() Hook_uninstall() Hook_enable() Hook_disable() Hook_requirements() Hook_schema() Hook_update_n()

9. Enabling / Disabling Modules Enable a module: module_rebuild_cache(); $module = array(‘my_module’); drupal_install_modules($module) Disable a module: module_rebuild_cache(); $module = array(‘my_module’); module_disable($module);

10. Usage You can use the Drupal Module Install Scripts for anything: Enabling / Disabling Modules Setting System Variables Custom SQL statements CCK fields manipulation Setting Permissions Demo time!

11. Drupal Multisite Performance ViorelZidariu-Popa

12. Problems to solve Lots of sites Lots of users Lots of content A few feature/bug fix updates every month to every site

13. Benefits of the cloud Lots of resources Hardware abstraction Pay only what you use

14. Distribute the load Distribute the sites Distribute the services Load balance (pressflow) Break it into pieces

15. Distribute the load

16. Throwing caches at it Proxying Content delivery network (CDN) Memcache APC cache

17. Using Drush for updates Use it for updating code or DB, run the crons Why it's not very well suited for multisite work Why is it so slow?

18. The Multisite update The jobs: sites offline update code update DBs get sites back online Downtime

19. Other improvements Running crons Snapshot for backups Using tools such as yslow devel module