Impending Drupal Site Launch? Use the List
After months of site development, code, more code, and long hours, launch day arrives. A site launch can come as a relief, create a bittersweet moment, or one filled with pride and a sense of accomplishment, not unlike a parent sending a child off to their first day of kindergarten.
Every team wants their deployment process to be as close to a gentle push into deep waters as possible. At Zivtech we've launched many Drupal sites, and have compiled a checklist that we use to help things stay snag-free. We typically run through the checklist several days before launch, once the site is already on its production server(s). It ensures we didn't miss anything critical to a live site and reminds us to change settings that are appropriate only during the development cycle. This list is geared toward Drupal 7 sites but can be used for earlier versions with little difference. We hope this checklist helps prepare you and your site for the big day. Feel free to comment on items we should add or that you do differently.
Security and Spam Possibilities
- Make sure file permissions for file directories and code directory are set correctly: http://drupal.org/node/244924
- Run the 'Security Review' module on the production environment: http://drupal.org/project/security_review
- On /admin/modules
The 'PHP Filter' module must be disabled.
- On /admin/config/content/formats
Filtered HTML or plain text MUST be set as the default to prevent cross-site scripting attacks. You must also check the configuration of the Filtered HTML format to ensure that the HTML filter is enabled for it and that no tags are allowed such as img, embed or object. If the 'Better Formats' module is enabled, check the default formats assigned to the roles.
- On /admin/config/people/accounts
Check the registration settings are appropriate for the site.
- Check for any security releases and run updates (testing locally first) if required.
- Drupal 7 will automatically alert you about security updates for enabled modules. If the client receives ongoing support, set the email to the proper notifications address.
- Make sure that only the modules that are being used are enabled. The more modules that are enabled, the slower the site will run and may be confusing to the administrators.
- Uninstall, then git remove any modules that are not being used and are not part of core.
- 'Devel' module and other similar tools should be disabled at launch, but not removed.
- On /admin/config/system/site-information
Make sure the email address and name are correct.
- On /admin/structure/contact and /admin/config/content/webform
Make sure email addresses are set correctly for contact forms and webforms.
- Disable reroute_email module after informing all developers and QA users that email is going live.
- Ensure permissions are set appropriately and minimally.
- Any permission granted to anonymous users should generally also be given to authenticated users.
- Be careful with granting the administer users permission.
- The 'View Media' permission from the 'Media' module actually bypasses other file control and should only be for administrators.
- Be sure that if one or more node access modules is in use (workflow access, og access, content access etc) that node permissions are not given which would prevent access from being determined by these modules.
- Once permissions are set, create a test user for each role, log in as them and try using the site the way they would to see if all goes well. (Hopefully this and some of the other items in this list were done during QA rather than now, but this is your last reminder!)
- Ensure that 'Cron' has been running.
- Make sure database updates are up to date.
- Take care of any other concerns listed on this page.
- On /admin/config/search/path/patterns
Make sure all paths are set properly, especially node path settings.
- On /admin/config/search/path/settings
Change general settings for 'Update actions' to something other than 'Create a new alias.' and 'Delete the old alias.', which are only appropriate during development.
In most cases 'Create a new alias but leave existing alias functioning' is appropriate for production. Alternatively or in combination, you can set redirects to be made when aliases are changed with the 'Redirect' module at /admin/config/search/redirect/settings.
Content types & Nodes
- Check to see if there are any content types not being used.
If there are, confirm the type can be removed, and if so delete that content type.
- Delete any dummy nodes that were created during development for testing. Track these down by searching for 'test', 'dummy', and for content created by the super user.
- Delete any views no longer in use.
- Ensure all views have been exported to Features and are not in an overridden state.
- Public facing views, especially on the home page and on sites with a lot of authenticated traffic, should be configured within each view for caching.
Set the 'Error messages' display to 'None'.
- Set 'Caching Mode' to normal.
- Enable 'Page compression'.
- 'Block caching' should be enabled, unless there is help text on the form warning otherwise. Minimum cache lifetime and expiration of cached pages should both be an hour, or as appropriate for the site.
- Alter the following lines in settings.php:
ini_set('session.cache_expire', 200000); ini_set('session.cache_limiter', 'none'); ini_set('session.cookie_lifetime', 2000000); ini_set('session.gc_maxlifetime', 200000);
The default values result in the sessions table growing very quickly and unnecessarily. Changing the numbers to something reasonable will not hinder the user experience and will prevent database bloating.
- Check for full URLs in node bodies etc. The client may have put in full URLs that will not work when the site goes live. Search in PHPMyAdmin or by grepping a tab-separated database dump, and fix or flag to the client anything you find.
Remove .txt files from Core
- Get rid of CHANGELOG.txt etc (from git etc). Do NOT remove robots.txt!
- Edit robots.txt to be standard (in case it has been edited during dev to restrict search crawlers).
Do a click-through (for small sites without a formal QA process).
- In addition to checking the site as a test admin, also check the site logged out as an anonymous user.
- Click around and make sure there are no broken links and everything looks okay.
Update external services
- If using Google Analytics or Facebook integration, you need to update settings for the live domain. You may need to put these settings changes into a script to run at launch time.
- If using Commerce, ensure that the payment provider is set to live and has been tested.
If using SSL (you should be), change your local /etc/hosts to point the site to its live domain and ensure SSL redirection is working correctly.
Make sure all features are up to date so that the launch configuration is saved and can be reverted to.
Are you an aspiring web developer, fresh out of college and eager to dive into Philly’s exploding tech startup scene? Are you a growing startup or established company in need of talented developers to help take your business to the next level?
Zivtech was thrilled last week when Philadelphia Mayor Michael A. Nutter announced that we were one of five winners of Startup PHL’s second round of Call for Ideas Grants, for a 6-week Web Development Bootcamp. We are hosting and teaching this bootcamp along with another awesome Philly web development firm--Neomind Labs--the goal of which is to allow us to share our expertise with, and help create job opportunities for, the next generation of Philly-based professional web developers.
We at Zivtech have been working with Drupal for a long time, some of us for over 10 years, and in that time we’ve gotten to use (and sometimes build) a lot of really cool modules to develop stellar sites for our clients. We have sifted through thousands of modules on Drupal.org, going far beyond the first couple pages of results and venturing deep into the unknown, unheard of, and ultimately under-appreciated modules. We sent out a question to our staff to ask for their favorite obscure modules, and we've compiled this list to share some of these modules that we have found particularly helpful, and to help ensure that they don't fall through the cracks. All of these modules have fewer than 8,000 active installs, and most have under 5,000.
As a Senior Developer here at Zivtech, part of my job is to develop with an eye towards security. If you follow development and security news, you know that achieving security is pretty hard in complex systems. But, while correctly implementing security across a site is challenging, some aspects of security are actually pretty easy and we've known what to do and what not to do for a long time.
Introducing Bear Skin, a comprehensive skin for Zivtech's Bear base theme.
The quality assurance (QA) phase of a web development project is the last phase before launch. While the development team has a lot of experience with QA phases, oftentimes the client team is new to the process, which can lead to stress. Let's prevent this with a little Q&A on QA.
Nominees for the 17th annual Webby Awards have been announced! And Zivtech-built sites are in the running for four awards!
This weekend 9 members of the Zivtech staff will be participating and competing in Startup Weekend Health Philadelphia 2013, which, according to their site, ”centers on building a web or mobile application that could be the basis for a credible business. After 500+ Startup Weekends world-wide, this will be the first dedicated solely to healthcare’s unique problems.”
We love Responsive Web Design, and we love Drupal. But do they love each other? After working on a number of RWD and Drupal projects this year, I'm happy to report that they get along just fine. Though "Love" might be stretching it a bit.
I've worked on many "Site Rescue" jobs, in which a client comes with a sick, but often brand-new and expensive Drupal site, desperately needing it fixed in a number of ways. Through this work I've seen a lot of patterns of "worst practices" employed. I enjoy the challenge of this cleanup work, while feeling bad for the clients who have been taken by incompetent vendors. I refer to these sites as "lemons" and I've made a study of their characteristics.