From MozillaWiki
Jump to: navigation, search




Bespoke modules and derivative theme

Notes: External checkout of a subversion repository can be done as follows ..

  • svn checkout <PROTOCOL>://<USER>@<IP|DOMAIN>/subversion/<REPOSITORY>/trunk .
    • protocol could be svn+ssh (READ / WRITE) , http (READ ONLY) , https (READ / WRITE)


Every Thursday on irc.mozilla.com #marketing or on mozillaca.com !spreadthunderbird

Getting Started

  1. Download the drupal core
  2. Download the list of contributed modules
  3. Checkout from SVN our bespoke modules and our acquia derivative theme
  4. Test the code ...

Coming soon a spreadthunderbird distribution which will include the latest core and contributed modules from D.o and installation profile for easy installation on your local server)

For more specific detailed instructions on how to setup a local MAMP server for development , please click here to read our tutorial. For generic instructions on setting up a local server on different OS's please click here

How to develop STB

  1. Request svn access if you don't already
  2. Find a bug to work on
  3. Fix the bug
  4. If the bug fixes a problem with a contributed module on drupal.org then create a patch and submit to the module maintainer for review on its project page on drupal.org. As soon as the patch is accepted and the module updated on drupal.org then update the bug on mozilla.org with the name of the module and the tag attached to the new release so that the module can be updated on Spreadthunderbird. If the bug fixes a problem with bespoke code that is in SVN on mozilla.org then create a patch upload to Bugzilla and request a review by Paul. Once the patch has been reviewed/accepted, commit to SVN with the bug # in the commit message and a brief description of what the patch does or the bug title. Add a comment to Bugzilla with the revision number of the commit: 'rXXXX'.
  5. Mark the bug as fixed
  6. QA verifies bug and marks as VERIFIED if it's really been fixed
  7. Please commit changes back to drupal.org wherever possible as it's important that we don't fork our distribution

Basic Functionality Testing

(Coming soon)

Do's and Don'ts

  • Use PEAR coding style
  • Always comment your code.
    • Function definition blocks at the least
    • Inline comments for complex code, use your best judgment
  • Always put a bug # and comment in your commit messages.
  • Don't embed HTML code in module files.
    • Define templates and keep presentation separate from logic code.
  • Don't touch the Drupal core. .
  • Don't push on Fridays or when you won't be around to verify the changes.

Staging Server

  • http://stage.spreadthunderbird.com/
  • https://stage.spreadthunderbird.com/ (points to the same location)
  • Bespoke code commited to SVN will automatically be pulled onto stage server from trunk every 10 minutes (To be confirmed)
  • Updates to drupal core and contributed modules will be pulled directly from drupal.org CVS servers
  • All pages are served behind a caching reverse-proxy which sometimes gives rise to problems accessing the site


  • File an IT bug requesting that changes on stage be synchronised with production
  • When IT closes the bug, verify the fixes/features are working.

Scheduled work to be completed by the end of Q2

  • Upgrade Spreadthunderbird to D7
    • Modules that need to be upgraded affiliates (RELEASED DEV), addtoany (RELEASED DEV), date (HEAD - D7CX), calendar (HEAD), fckeditor (?), google_analytics (DEV), mollom (DEV D7CX), Views (DEV), cacherouter (beta1 - D7CX), securepages (TODO?), microblog (TODO)
  • Other ideas for discussion
    • How to sanitize the database for development on a local server
    • Allow a user to provide their geographic location via an interactive google map and have all users visible on a google map. This can be done via the Location / Gmap contributed modules.
    • Allow users to vote on content. This can be done via the Fivestar / Voting API modules.