CalArts recently relaunched their website using Drupal 6 as a platform for the various schools and programs to serve the content the way they want to their audience while still allowing us the ability to have some control on the overall look/feel and ability to publish one piece of content to multiple locations. View how we did it!

4. Work at California Institute of the Arts.

5. Working with Drupal since 2006 (4.6.x).

7. First art institute to offer BFAs and MFAs in visual and performing arts.

8. Comprised of 6 schools (Music, Theater, Art, Dance, Film/Video, and Critical Studies).

9. Located in Valencia, 30 minutes north of LA.

11. Odd theme integration along with poor use and availability of content types.

12. Very poor workflow.

13. Site content administrator had to create a piece of content and then assign userswith ability to edit content.

14. Most of the schools decided to create their own separate sites.

15. Repeated/different student enrollment information.

16. Repeated/different faculty/staff information.

18. Drupal 7 was (at the time, felt like) around the corner.

19. Did not want our main site to effectively be ‘unsupported’.

20. Got very lucky – provided with option to start a site from scratch (so evaluate modules, content types, overall architecture).

21. Opted for Drupal 6.

22. Very Stable.

24. 2 developers.

25. 3 primary content editors.

26. 10 subsite content editors.

27. Organized ourselves using BaseCamp.

28. Most had used basecamp in the past and were comfortable with it.

29. Subversion code repository.

30. Easy set of tools for everyone involved to use.

32. Need way to unify all of the above under one system.

33. Provide similar look/feel.

34. Provide customizability in:

35. Colourscheme.

36. Typography.

37. Control over what can go in predefined regions.

38. Content + Aliases.

40. Improved site-wide search.

41. Better workflow for content editors (ability to create/edit/delete content on their own ).

43. Were initially experimenting with one primary site theme with multiple subthemes (for each subdomain).

44. Eventually opted to use one theme (some small issues with Domain Access which were unavoidable but ended up working in our favour).

46. Featured Gallery

47. First sidebar Content Top Second Sidebar

48. Content

49. Content Bottom

50. Page Closure

52. Blog RSS Feed to populate various blogs on our sites.

53. Directory Profile.

54. Employment Listing.

55. Event.

56. Frontpage Link (simple link w/ image to call on something important on our site(s)).

57. Gallery (container for below).

58. Audio, Video, Photo w/ node reference.

59. News Item.

60. Program Page.

61. Site Page.

63. Staple of most Drupal sites.

64. Domain (http://drupal.org/project/domain).

65. Most important piece of the puzzle for us.

66. Came with a large chunk of the functionality out of the box

67. Publish content to multiple domains.

68. Allow a specific domain to be the source of the content.

69. Allow for subdomain-specific settings.

70. Domain prefix allowed us to ensure each subdomain had its own aliasing tables (since each subdomain may have an ‘about’ section).

72. Provided a simpler way to define our menus and for users to make tree selections on our site.

73. Feeds.

74. Import content from site blog and for various other content.

75. WYSIWYG.

76. Easier editing for content editors.

77. Used Pathologic (http://drupal.org/project/pathologic) to ensure links would work even after migration from dev -> production and if the URL alias for a link changed in the future.

79. Used for subdomain home pages where required.

80. Used as variant for user home page for links on creating new content, editing some of their existing content.

81. Features

82. Very important for establishing the entry of content type / views / imagecache / feed / panels updates to our site.

83. Create / Test out functionality of these pieces on our dev site. Create feature (module) of these pieces and migrate them up to the live site.

84. Allowed us to disable the UI for some of the modules wherever possible on the live site.

86. Faceted search

87. Quite fast (site currently only consists of ~2000 nodes)

88. Integrates fairly well with Domain Access

89. Generally excellent results

90. Plan to eventually migrate to Solr (once the IT team decides to move out of FreeBSD to Ubuntu or RedHat)

91. Shadowbox (http://drupal.org/project/shadowbox)

92. Was (at time) more stable than Lightbox2.

93. External Links (to let users know they are exiting current domain)

95. Can be used to serve images, js, css files from other domains

96. Can speed up site load time quite a bit.

97. We currently only use it for images (http://static.calarts.edu)

98. SWFTools

99. Used for audio formatters

100. Depending on audio content type usage, may be removed from site.

101. Rubik

102. Ok, its not a module. Fantastic admin theme.

104. Sites could not have their own aliases.

105. Used domain prefix so each domain had its own aliases table.

106. Did similar for caches but also had its own issue.

108. Helper module for Domain Nodetype

109. Ensures content type is published to a particular domain

110. Ensures content type is always sourced at particular domain

111. Redirects user to particular domain (so the alias would be created on the appropriate domain)

112. If content was created for a particular domain (and user is not on same domain), user is notified with recommendation to switch to appropriate domain.

113. Domain specific settings

114. Runs on cron task.

115. Checks the feeds items that were retrieved and sets the source domain to be the same as the feed they belong to.

117. Customizability in:

118. Typography

119. Were heading down path of using sIFR but I was not comfortable with using flash for displaying

120. Colour Scheme

121. Domains and Backgrounds

122. Background module only worked within scope of a single domain.

123. Carousel that fit our needs

125. Views plugin (surprisingly easy to create)

126. Fairly lightweight.

127. Very fast.

128. Not necessarily useful to others in community (primary reason for not being in contrib)

129. Domain Background (not in contrib – evaluating usefulness to rest of community)

130. Upload a background image or select a background color.

131. Allows for centering, tiling, positioning.

132. Friendly to sites setup using domain access/multi-site settings.

133. CalArts Twitter Pull

134. Lightweight module for pulling in twitter status.

136. Fonts defined in .fontinfo file (similar writeup as .info files)

137. Webfont loader API from google uses javascript to figure out browser, load correct font, and stylesheet has ‘hooks’ to figure out what stage the font rendering (individual and overall) is currently in.

138. Currently supports custom fonts, google fonts, and typekit.

139. Flexicolor (http://drupal.org/project/flexicolor)

140. Create a series of selectors for which colours can then be chosen.

141. Create presets for the various colour pieces to toggle against.

143. Perform test migration (time it out).

144. Slightly different from a typical site migration

145. Domain access defines domains with aliases in the database.

146. Opted to perform a search/replace

147. All content came through correctly

148. Certain variable/views settings did not

149. The settings are serialized; if we modify them, PHP does not know how to convert them back since they are no longer the same length.

150. Affected very small portion of site; they were documented.

152. Not compatible with domain access if you want each site to have different settings.

153. Our modules are little better for it; helped us understand how these modules work so we have more flexible modules.

154. You will have to define the caching tables from all your domains to your Drupal installation if you are prefixing the cache tables.

155. Clearing all cache from one site also deletes the aggregated css/js files (so if files are shared across the sites, your other domains cache tables will be referencing these delete files and so your site pages will look ‘off’

157. But now gets hidden.

158. Schools at CalArts much more confident about the website.

159. Various programs in schools are interested in being a part of what was created.

160. Started with the MFA programs in the Critical Thinking department, character animation program is next.

161. Many feature requests from the content editors from the various schools (mostly to do with media, blogging).

163. Content publishing scheduler (looking at various modules and implementations).

164. Collection of media galleries (more and more like Flickr)

165. More refinement of our contrib modules into D.O.

166. More settings as features

167. Performance optimizations

168. Memcache

169. Solr