Drupal.org

Drupal.org and its sub-sites (api.drupal.org, groups.drupal.org, etc) will be going down for 20 minutes Monday, May 7, 5:00 PDT (May 8, 00:00 UTC). This maintenance window will be used to upgrade our single sign on system. Please follow the @drupal_infra twitter account for updates during the downtime and thanks for your patience!

Sites will remain functional for the majority of the scheduled downtime, but everyone will be logged out. You may not be able to log into sub-sites for a few minutes as the update is rolled out.

Drupal 7.14 is now available, which contains bug fixes as well as fixes for security vulnerabilities from Drupal 7.13.

Drupal 6.26, which fixes known bugs (no security issues) is also available for download.

Download Drupal 7.14
Download Drupal 6.26

Upgrading your existing Drupal 7 and 6 sites is strongly recommended. There are no new features in these releases. For more information about the Drupal 7.x release series, consult the Drupal 7.0 release announcement, more information on the 6.x releases can be found in the Drupal 6.0 release announcement. Drupal 5 is no longer maintained, upgrading to Drupal 7 is recommended.

Security information

We have a security announcement mailing list, a history of all security advisories, and an RSS feed with the most recent security advisories. We strongly advise Drupal administrators to sign up for the list.

Drupal 7 and 6 include the built-in Update status module, which informs you about important updates to your modules and themes.

Bug reports

Both Drupal 7.x and 6.x branches are being maintained, so given enough bug fixes (not just bug reports) more maintenance releases will be made available, according to our monthly release cycle.

Changelog

Drupal 7.13 only includes fixes for security issues. Drupal 7.14 also includes bugfixes. The full list of changes between the 7.12 and 7.14 releases can be found by reading the 7.14 release notes. A complete list of all bug fixes in the stable 7.x branch can be found in the git commit log.

Drupal 6.26 only includes bugfixes.

Security vulnerabilities

Drupal 7.13 were released in response to the discovery of security vulnerabilities. Details can be found in the official security advisory:

• SA-CORE-2012-002

To fix the security problems, please upgrade to Drupal 7.13.

What is included with each release?

We made two versions of Drupal 7 available, so you can choose to only include security fixes (Drupal 7.13) or security fixes and bugfixes (Drupal 7.14). You can choose your preferred version. We are trying to make it easier and quicker to roll out security updates by making security-only releases available as well as ones with bugfixes included. We hope this helps you roll out the fixes as soon as possible. Read more details in the handbook.

Known issues

None at this time.

The call for papers is still open for DrupalCon Munich -- but only until May 11!  Trainings too! The DrupalCon content team is looking for sessions that cover pushing the boundaries of Drupal and its increasing use as a cross platform system. Help shape what is presented at DrupalCon with this year's theme, "Open Up! Connecting systems and people."

Any proposals for sessions should fit within one of the following tracks:

• Coding and Development
• Community
• Design and Theming
• Business and Strategy
• Site building
• DevOps

To learn more about each topic, view the Session Track page. Here you can find out the anticipated audience and the topic focus, as set forward by each track chair. Selected Sessions and Trainings will be announced May 29.

Curious to learn how sessions are selected at DrupalCon? Learn more about the session selection process.

Core conversations will open for submissions on May 29, read more about Core Conversations on our website.

We are also inviting all organizations with training experience to submit proposals for the Pre-Conference Trainings, to be held on Monday, 20th August 2012.

Open Up - submit your session before May 11!  We look forward to seeing you in Munich August 20-24. Join the Drupal community in Europe this summer and register now for early-bird pricing.

We are thrilled to announce that Google will be sponsoring 13 Drupal projects for Summer of Code 2012. We would like to extend our sincere thanks to Google, who are investing over $72,000 in the Drupal project.

As always, we had many more projects that we would have liked to accept than we were able to. The mentoring team deliberated fiercely over the past two weeks, and arrived at the final acceptance list.

Drupal will benefit from microdata support for contrib field types, help topic module for documentation team, sales reports integration for drupal commerce, materialization plugin support for views, search api statistics etc.

If you would like to keep up to date on Summer of Code happenings, would like to volunteer to help test students' projects, and/or would like to help students as they find their way in our community, please join the SoC 2012 working group and help out in whatever ways you can.

Here's to another great summer! :)

Application Student Mentors Auto Tagging Articles using Semantic Analysis/ Topic Modelling Arjun Kapur Matt Chapman Enhancing Feedback module (D7) Manu Chaudhary Alex Weber Enhancing Secure Code Review Module Udit Jaggi Michael Hess Extend microdata support to contrib field types Anca Dumitrache Lin Clark Help Topic module for the Drupal Documentation Team and for the help system temaruk Jennifer Hodgdon Improving RESTful Web Services Sebastian (sepgil) klausi Materialization Plugin for Views Dhruv Baldawa Janez Urevc Phone / SMS / VoIP integration with Drupal Commons nitech Leo Burd Port Og_panels to D7 and Improve Message notify to make it the source of email notifications sanjay rohila ezra-g Preparing Menu Block Module for Drupal 8 Core Chad Whitman Dave Reid and John Albin Wilkins Sales Reports for Drupal Commerce Christophe Van Gysel Daniel Wehner Search API Statistics Michael Timofejev Thomas Seidl Translation Management Tools Server Sebastian Siemssen Miro Dietiker

Drupal.org and its sub-sites (api.drupal.org, groups.drupal.org, git.drupal.org, etc) will be going down for 45 minutes Thursday, April 19, 5:00 PDT (April 20 00:00 UTC). This maintenance window will be used to upgrade our backend media servers. Please follow the @drupal_infra twitter account for updates during the downtime and thanks for your patience!

NOTE: During this downtime window, we will also disable access to the git repositories via SSH. The git:// protocol will still be functional.

Back in 2009, Groups.Drupal.Org (GDO) went through a major transition including upgrading from Drupal 5 to Drupal 6, a redesign, and adding new maintainers. We are currently in the process of a similar transition. The site has already gone through a redesign, and as we make plans to transition to Drupal 7, we will also be moving to new maintainers for the next year.

Making it easier to contribute to GDO

Between the Drupal Association’s initiative to improve *.drupal.org, the community brainstorming on site improvements, and feature requests in the Groups.Drupal.Org issue queue, there is clearly a lot of interest in making improvements to GDO. However, for folks who want to roll up their sleeves and help by filing a patch, the path to replicating GDO for development purposes hasn’t always been clear. As a strategy for making it easier for anyone in the Drupal community to file a patch and streamlining maintenance efforts for the site, we have proposed that GDO will run the Commons distribution of Drupal for Drupal 7. Of course, this means that improvements made to GDO benefit sites powered by Drupal Commons and vice-versa, that generic improvements to Commons will benefit GDO.

New maintainers: Meet Ezra, Scott, and Justin

Helping with this transition, Ezra Gildesgame (ezra-g), maintainer of Drupal Commons, is also now a maintainer of groups.drupal.org. Ezra is the technical lead for Drupal distributions at Acquia, has been contributing to Drupal for over 5 years, and also maintains the Conference Organizing Distribution (COD).

Our other new Groups.Drupal.Org maintainers are Scott Reynen (sreynen) and Justin Toupin (justin2pin) from Aten Design Group. Scott is Lead Developer at Aten and has been contributing to Drupal for over 5 years, including helping to organize the Denver group on GDO. Justin Toupin is CEO at Aten, and has been leading the organization’s involvement in Drupal since version 4.7.

Getting involved: How you can make GDO better

This process of upgrading Groups.Drupal.Org is an especially good time to get involved by joining a few different groups and queues:

• Commons related are the Commons group, and the Commons issue queue for bugs/ideas that affect all Commons sites.
• The GDO issue queue is for features and tasks specific to Groups.Drupal.Org.
• Groups to discuss the site: http://groups.drupal.org/maintenance and http://groups.drupal.org/groups-drupal-org

Note that Ezra, Scott, and Justin have agreed to work on the site for at least a year. If you think you might want to take over in a year, the best way to do that is to get involved working on the site in these issue queues.

Thanks, Greg & Josh!

This is also a great opportunity to thank Greg Knaddison (greggles) and Josh Koenig for their help maintaining Groups.Drupal.Org over the past few years. Josh and Greg found they were too busy with other projects unrelated to community site building which made it harder to find time for GDO (Josh building Pantheon and Greg working with Acquia’s Profesional Services Security Group and the Drupal Security Team). Greg and Josh hope that transitioning to people who spend more of their lives working on community sites will help GDO be an even more valuable collaboration platform for our community.

Hi friends. I'm hoping that you'll support another Drupal community initiative that I've recently dreamed up. All you have to do is add a /drupalgive page to your organization's web site.

Two organizations have published already at http://www.acquia.com/drupalgive and http://www.chapterthree.com/drupalgive. These pages are based on a design by Nica Lorber of Chapter Three. Feel free to reuse this design or just publish a plain listing page. It is better to publish a plain page than none at all. Or use the Feature at http://drupal.org/project/drupalgive.

A /drupalgive page highlights the great work that your organization is doing for the Drupal project. Not only does your organization receive credit for the work you do, but we also nudge other organizations to give back as well. I expect that employees and potential hires from non-contributing organizations will start demanding to give back. This initiative gives those folks something to point to when advocating and educating inside their organization.

Here are examples of appropriate and inappropriate items for a /drupalgive page:

Appropriate

1. A podcast educating folks about great Contrib modules.
2. A link to a significant patch review or commit on drupal.org.
3. A blog post about Drupalish wireframe templates that anyone can use.

Inappropriate

1. An announcement about your latest site launch (even whitehouse.gov).
2. A new video was added to your commercial video subscription service.
3. New features for your paid Drupal hosting service.

Your /drupalgive page should also emit an RSS feed at /drupalgive/rss. We'll add your feed to the new Planet Drupalgive (page, RSS). To get added to the feed, follow the Drupal Planet process. Lastly, please include a link to http://drupal.org/project/drupalgive so that folks can learn more about the initiative.

One simple way to build a /drupalgive page is to add a 'drupalgive' term to your site taxonomy and tag posts with it. Alias the term detail page to /drupalgive and you are done. An alternative is to create a dedicated content type for these entries and a simple View at /drupalgive will show the listing.

Please comment below and lend your support or provide other input.

Bojhan Somers and Roy Scholten are the Drupal UX Team leads.

We believe that Drupal 8 User Experience needs a lot of work to truly make all users of Drupal love what they are working with. We believe that by improving core, we improve the entire Drupal experience for everyone.

How are we doing this? By working with core initiatives, providing ideas, sketches, wireframes, detailed designs, and actively engaging in discussion. D7UX taught us a lot of hard lessons, we now know how to communicate our design rationale more clearly, maintain a UX vision throughout the maze of issues, and empower developers.

What are we working on? We are working on a few initiatives; mobile, blocks & layouts, multilingual and leading a lot of smaller efforts around improving our content authoring and site building experiences.

Drupal 8 design progress so far Content creation

Our content creation experience is still far from being great, but we have been improving the content creation experience from all angles. We have received lots of feedback on our proposals, and iterated with the community on various parts of this experience.

• Research on a interaction model for the content creation page
• Redesigning the Create Content page
• Find content iterations

We have now finalized most of our research activities and we want to start implementing a few of our major ideas. For this to happen, we need developers who want to improve this part of core.

There are two very actionable issues at #1510532: Implement the new create content page design and #1510544: Actual preview of content for you to help out on!

Blocks & Layouts

The blocks & layout initiative started by EclipseGC focuses on solving the messy experience of placing parts (blocks, views, panes) on the page. We believe this can be fundamentally better if we tackle it in core. This initiative will allow us to arrange and organize blocks into flexible layouts through a drag and drop interface. This initiative has many UX components, from finding the right blocks, to selecting the context, to creating mobile layouts.

We have done a lot of research the past few months to understand the space we are designing for. It’s incredibly complex, but will be a huge win if we can provide a great solution straight out of the box.

• Research on pages & components; what are the fundamental concepts?
• Research on context usecases; what are the primary use cases?

We will need help from everyone; developers, designers, user researchers, end users and business owners! Become part of the discussion in the Drupal 8 Blocks & Layouts everywhere initiative group.

UX team activities

UX team bi-weekly office hours

We started to hold bi-weekly UX "office hours" (next one will take place 16 April, 20:00 UTC, 4PM NYC, 4 AM Tuesday Singapore/Shanghai), where we will discuss recent activities of the team but also review contributed modules. This has resulted in modules such as Taxonomy Acces Control making major improvements.

UX team activity

The team has been busy in Q1 2012:

• Becky Gessler, Garen Checkly and Jen Lampton conducted a usability study at the Google offices, resulting in a detailed findings report and Drupalcon Denver core conversation talk on how to solve it.
• Lisa Rex, Dharmesh Mistry (dcmistry), Erik Stielstra (sutha), Alexander Ross (bleen18) have done a total of 22 interviews about how people use the module page.
• Lewis Nyman has been working hard on designing Drupal’s mobile interface, resulting in interesting discussions around navigation, principles and actual implementation of ideas in the mobile issue queue.
• Roy Scholten(yoroy) has presented on Core product: 3 is the magic number and organised several sprints around UX at Drupalcon.
• Jared Ponchot has been contributing design proposals, to our effort to redesign the content creation page.
• Kristjan Jansen (kika), Jeff Noyes (Noyz) and Kevin O'Leary (tkoleary), Michael Keara (UserAdvocate) have put out various ideas around media UX, creating UI standards for add/edit flows, optimizing the content listing and research for the Blocks & layout initiative.

We have also released our ideas around redesigning the module page, adding a project browser to core, adding search everywhere, draft revisions and much more in the usability issue queue!

We need your help!

We need volunteers:

• Developers who can help us with the PHP, CSS or JS parts of these changes.
• New and experienced UX designers to work on the new features that we want to introduce in Drupal 8.
• A project manager who can help break down tasks, coordinate contributors, update blog posts and issues, and help the UX team & leads focus more on UX.

If you're interested in becoming a contributor to the UX Team in one of the roles above, contact Bojhan Somers and/or Roy Scholten.

You can find us in in the usability group, contact us directly by e-mail (or drupal.org contact form), join us on IRC in #drupal-usability, or find us in person at Frontend United.

The cool stuff we're working on

Still not sure? We we love a lot more help to pursue all these crazy ideas within the next 7 months:

• Improving the content creation experience. Discussion take place in our design proposal, and implementation is taking place in #1510532: Implement the new create content page design
• Layouts & Blocks initiative, building a drag & drop editor where you can place components, build layouts and manage pages. Discussions take place in the Layouts & Blocks group.
• Mobile administration, Drupal 8 should be great to use on any phone help us in making the administration mobile friendly. Discussions are taking place in the Mobile group

Thanks!

- Bojhan and Roy

AttachmentSize ux_sprinting.jpg55.93 KB

Hello from Jennifer, your friendly Drupal Documentation Team leader! It’s time for a quarterly update on what’s happening in the Documentation team.

First off, I just want to remind everyone that I’m still planning to step down as Documentation Team Leader at the end of 2012. If you’re interested in becoming the co-leader or assistant leader now, and taking over at the end of 2012 as the main team leader, see http://groups.drupal.org/node/203258 for more information. It would be good to find someone soon!

Events

• The Documentation Team is currently holding weekly "Documentation Office Hours"—one-hour IRC meetings on Tuesday afternoon (North American time), open to anyone for questions and discussions about contributing to documentation. This schedule is likely to change soon; join the discussion about a new time for office hours.
• The API documentation cleanup sprint from last quarter has continued into this quarter. The goal is to bring the Drupal 7 and 8 core API documentation much more in line with our documentation standards. To join in, visit the issue page.

Milestones and Accomplishments

• Lots of content was updated on Drupal.org this quarter. Of particular note:
• There used to be a "Community and Support" link in the top navigation of Drupal.org; now there are separate Community and Support links, and the Support page has been completely redone (a redesign of the Community page is also in the plans). Hopefully this will help people new to Drupal connect with the help they need to get started. Thanks to Lisa Rex, David Hernandez, and others for making this happen!
• The Omega theme project organized a group to update the Omega section of the Community Documentation.
• The Media module project organized a group to update the Media documentation.
• An effort is underway to create a Mobile section in the documentation.
• We started a New Contributor Tasks section on Drupal.org. This is a place where people new to contributing to Drupal can go to find meaningful and doable tasks to start with. If you have ideas for the section, there’s a page describing how to add to it (with templates), and a suggestions page too.
• 712 different contributors made a total of 3976 revisions to documentation pages on Drupal.org. Wow! (I have a new statistics page that totals this up). Apologies if your project didn't make it into the list above -- there's a lot going on and I can't keep track of it all!
• Neil Drumm and I (with the help of other patch contributors) are continuing to make updates to the software for http://api.drupal.org. This quarter, there were major improvements to the linking and references features of the site -- check it out if you haven't been there lately! If you would like to work on the API module, check out the issue queue (http://drupal.org/project/issues/api) or find jhodgdon in IRC to get oriented.
• I was given permission to commit Drupal Core 7/8 documentation and coding standards patches in February, and to help out in case of "Core Is Broken!!" emergencies. Hopefully this will lessen the burden on Angie, Nat, and Dries, freeing them up to concentrate on bugs that improve the Drupal software functionality.

Docs Infrastructure

Last year, the Docs Team (or at least its leadership) got a bit discouraged about Documentation infrastructure improvements taking quite a while to get deployed to Drupal.org. But now there's a new process for getting improvements deployed, and Neil Drumm is working on them with hours funded by the Drupal Association. So, I'd like to get us working on improvements to "docs infrastructure" (tools, navigation, etc. for Drupal documentation writers and users) again.

I started working on that this quarter, and several small things were deployed. That went well, so there are now more in progress. Two that we hope to get done soon are a Docs Team effort to have better navigation for Community Docs, and LoMo's project to replace the Books page with a content type/View. Join in the discussion and/or help out!

And as a preview, this summer I would like to really get working on the "curated docs" we've been talking about for a year or more... Watch http://groups.drupal.org/documentation-team for updates!

Next Steps

If you're interested in helping with Drupal documentation:

• New contributors: Check out the tasks in the New Contributor Tasks section, or read http://drupal.org/contribute/documentation to learn all about contributing to documentation. Or come to the weekly office hours (see Events section above) to ask questions and get started.
• Drupal Documentation announcements, discussions, and events are posted on http://groups.drupal.org/documentation-team and on Twitter (@drupaldocs).
• API documentation cleanup sprint (for programmer-documenters): http://drupal.org/node/1310084
• Work on the API module: http://drupal.org/project/issues/api

Why Drupal was chosen:  Drupal natively afforded us the framework to build a site that was highly functional and customized yet not locked-down in core structure. When stacked up next to other CMS' which are built to allow simple content hierarchies (like Joomla), Drupal excels in providing the ability to ignore vertical hierarchy and organize multi-media content multi-laterally through taxonomy and associated access permissions. Completed Drupal site or project URL:  http://calarts.edu/

The nation's first art institute to offer BFAs and MFAs in both the visual and performing arts, CalArts is dedicated to training and nurturing the next generation of professional artists, fostering brilliance and innovation within the broadest context possible. Emphasis is placed on new and experimental work and students are admitted solely on the basis of artistic ability. To encourage innovation and experimentation, CalArts' six schools--Art, Critical Studies, Dance, Film/Video, Music and Theater--are all housed under one roof in a unique, five-story building with the equivalent of 11 acres of square footage in Valencia, California, just 30 minutes north of downtown Los Angeles.

Describe the project (goals, requirements and outcome):  The nation's first art institute to offer BFAs and MFAs in both the visual and performing arts, CalArts is dedicated to training and nurturing the next generation of professional artists, fostering brilliance and innovation within the broadest context possible. Emphasis is placed on new and experimental work and students are admitted solely on the basis of artistic ability. To encourage innovation and experimentation, CalArts' six schools--Art, Critical Studies, Dance, Film/Video, Music and Theater--are all housed under one roof in a unique, five-story building with the equivalent of 11 acres of square footage in Valencia, California, just 30 minutes north of downtown Los Angeles. INTRODUCTION: After years of managing an ever-growing static-HTML website which included sub-sites for each of its six schools, CalArts was preparing to move their web presence to a Content Management System and looking for an Open Source solution to meet a series of functional and aesthetic requirements. SITE REQUIREMENTS: Given the size of content already comprising the old static site, CalArts needed a CMS which could offer innovative means of site navigation whilst allowing inter-relational multi-media content. To better clarify the specific abilities of each CMS we considered for the solution, Design Guru and CalArts defined a general set of site requirements. In addition to simply storing content and allowing stake-holders to add to/edit it, the site needed to provide modular scalability and function as an application framework that could provide unique data-handling and grow depending on the changing needs of the Institute through time; without needing to undergo massive core upgrades to afford such changes. Here are some major requirements of the new CMS solution: User-accessible, hierarchical content : Access to all published material on-site should be subject to a robust permissions system, Content/Comment publishing authority and viewing ability should be user- specific, definable by user-groups. Extensive calendar functionality : The ability to restrict event attendance/viewing per user group, Users will be able to post events to a common event listing, based on their site permissions, The ability to relate multi-media to particular event listings (eg. Attach an image or video clip), Site-wide Forums & Commenting: In order to increase multi-lateral communication, threaded commenting will be available throughout the site. News publishing : Permissions-specific ability to submit/publish & view news postings, News-to-front-page; high-level users (eg. Staff) will be able to assign news postings to the Institute/School front-pages. News, as well as other content on the site, can be un/subscribed to by users, based on permission and content taxonomy, News Syndication via RSS Advanced Theming possibilities : Aesthetically separate each school and other areas of the site whilst maintaining an overall site 'design,' Each content item on the site should be style-able independently, Dynamic navigation should be able to be presented in multiple areas of the site, Content should be group-able (e.g. Faculty types per school; to display in vertical lists that can load individually but be presented alongside these lists.) SOLUTION: After considering relative merits of a number of CMS' the decision was made to develop the site in Drupal 5.x Drupal natively afforded us the framework to build a site that was highly functional and customized yet not locked-down in core structure. When stacked up next to other CMS' which are built to allow simple content hierarchies (like Joomla), Drupal excels in providing the ability to ignore vertical hierarchy and organize multi-media content multi-laterally through taxonomy and associated access permissions. Of course, at its core, Drupal's use of 'nodes' meant that we could relate anything on the site to each other - which proved to be an invaluable feature of the site when looking at styling and multi-admin content management issues. Three key aspects of the build were crucial; Aesthetic demands of the site required a combination of third party modules to allow styling patterns across content types, site areas and so on, Hundreds of site users were to be administrators of various areas of the site and afforded permissions accordingly; they had to not be able to interfere with each other's content and all had to be able to work on the site with ease - the default permissions layer would need to be extended and a WYSIWYG editor installed with some image/file handling capability, Custom content types would be necessary along with their dynamic display through lists.TECHNICAL:In order to meet the various site requirements and build aspects listed above, we made good use of the following Drupal modules. Modules Key modules used:  Node style Menu Trails Menu Trim LoginToboggan Administration menu Views Bonus Pack User Import Taxonomy Access Control Devel Content Construction Kit (CCK) Category Views Panels Usernode Javascript Tools Pathauto FCKeditor - WYSIWYG HTML editor IMCE Why these modules were chosen:  The general overview of how these modules come together is that we have various content types on the site though it mainly consists of 'page' content. Pages have URLs written by the Pathauto module and in some cases, where we need specific URLs per page which are outside of the rules, specific content types have been created which do not have rules set. Those content types are still subject to the same categories and are thus accessible in site-wide searches and when users click on the tags at the bottom of pages etc... We used the Views module extensively throughout the site to create custom lists of nodes and those lists aren't always displayed as pages. You can see an implementation of Views blocks on faculty bio pages per school - where the blocks act as dynamic menus; listing all 'usernode' content in particular categories. Each block is headed with a title and the overall effect is a menu which could not have been created with the stock Drupal menu system. One of the focal accomplishments we made with drupal on this site is the depth to which site theming can take place. With the Node Style module, we have created a series of styles to present each school and other site areas as visually distinct, yet with the same layout - provided by two custom Drupal themes. One theme is simply two columns with a top area that features 5 block areas to store the top menus and search bar. The second theme is a variation of the first; with an additional block position to create the effect of three vertical columns - where the middle one displays views-block-powered dynamic list menus (like on faculty bio pages). In order to load the dual layers of rotating background imagery per site area, node styles simply call specific image rotation scripts written in php via CSS. Note: this is just a partial list of what we've installed on the site - to give you some leads on modules we really feel were crucial in being able to construct this specific site. Community contributions: 

Unknown.

Project team: 

Perhaps the main feel-good factor when working with Drupal is the amazing community to learn from and bounce ideas around with. Thanks to anyone who posts to drupal.org and hangs out in #drupal-support - as well as Robert Douglass (from lullabot) for tips and feedback over the past couple of months.

Why Drupal was chosen:  PrintedArt is an online collection of fine art photography that sells finished artwork to its customers. The artwork gets printed on gallery-grade display material, usually an aluminum dibond plate with an acrylic front for better display and durability. When we planned the project we had take a number of factors into account that led us to the combination of Drupal and Ubercart as our platform of choice. The system had to take submissions from photographers and also allow them to make modifications to the items they own. It would need to have a full ordering system to process credit cards and a workflow system that allows us to dispatch work orders to our fulfillment center. When evaluating the different platform choices, we had already done a thorough investigation into a number of competing platforms: On our short list of candidates were Joomla/Virtuemart, Alfresco, Magento and Drupal/Ubercart. The decision for Drupal was made in large part because of its module architecture that lends itself very well for a "gradual improvement" development strategy. It helped, of course, that our hosting provider was offering a fully supported Drupal installation that can be automatically upgraded using their control panel. Completed Drupal site or project URL:  http://www.printedart.com/

Printed Art is a platform for photographers to display and sell their work as finished art, ready to hang on the wall. Photographers submit their artwork for the PrintedArt Collection to be reviewed by our curators. Once the curators approve a submission, an ubercart product node gets automatically generated and attached to the image node. Customers can then configure an image by choosing the size and material for their order.

In addition to the collection, PrintedArt is also offering printing services where customers upload their own images to be produced as artwork on aluminum dibond and acrylic. After the upload, images are automatically analyzed to determine the print sizes that can be offered based on the image resolution.

Modules Key modules used:  Image Ubercart UC Node Checkout Content Construction Kit (CCK) Workflow Why these modules were chosen:  N/A Community contributions: 

N/A

Project team: 

G Meredith Group - owns and operates PrintedArt.com and worked on the Drupal architecture, planned the rollout and implemented a large part of the features described above.

Eleks Design Studio - implemented 3rd-party API integrations, worked on custom Drupal modules for workflow management and eCommerce.

G Meredith Consulting - provided marketing strategy for the PrintedArt rollout.

Why Drupal was chosen:  N/A Completed Drupal site or project URL:  http://itunes.apple.com/us/app/specimania/id480234800?mt=8 Describe the project (goals, requirements and outcome):  <img src="http://drupal.org/files/photo 2.PNG" alt="VS Board Game" width="150" /> <img src="http://drupal.org/files/photo 3.PNG" alt="Card Example" width="150" /> <img src="http://drupal.org/files/photo 3_0.PNG" alt="Matching Game" width="150" /> <img src="http://drupal.org/files/photo 4.PNG" alt="Unlock Cards" width="150" /> View the trailer here: http://youtu.be/X_kEDF43oRg <a href="http://itunes.apple.com/us/app/specimania/id480234800?mt=8">Download Specimania on iTunes</a> <h2>Combing forces with one of the largest research-based museums in the world</h2> For The Field Museum's first application, the goals were very clear: <ol> <li>Engage young families with children 2-12</li> <li>Represent all facets of the museums exhibits/research without affecting the desire to visit the museum</li> <li>Find a way to involve the incredible scientific staff in the project without overwhelming them with tasks</li> <li>Reach audiences outside of the museum and encourage attendance</li> <li>Make learning awesome</li> </ol> Some incredible brainstorming with the New Media team resulted in a digital trading card game called 'Specimania'. Here is how it set out achieving the projects goals: <h3>Engage young families with children 2-12</h3> For children 2-5 we created a matching game. Cards from the game are placed in a 4x4 grid. Users tap and/or scratch the dirt off the cards in order to reveal matches. If a user finds all the matches in the game within 30 seconds, they unlock a new Character Card. For children 6-12 we created a trading card game. The game mechanics revolve around a deck of characters, boosters that power the cards, and gotcha cards that act to trump normal game play. <h3>Represent all facets of the museums exhibits/research without affecting the desire to visit the museum</h3> We separated the deck of cards into the 4 halls of the museum: Anthropology, Botany, Geology, and Zoology. From that, scientists nominated 12 Characters from their discipline to be professionally illustrated. The scientists were then tasked with coming up with 1-3 paragraphs of text that contained facts and history of the specimen/artifact. <h3>Find a way to involve the incredible scientific staff in the project without overwhelming them with organizational tasks</h3> There are 48 scientifically accurate cards in the game that came together via 2 rounds of sketches, 2 rounds of illustrations, character names, types of cards, halls, trivia questions/answers, challenge names/points, comments and approval status. Do keep this from becoming an organizational nightmare, we turned to our friend Drupal. <h3>Reach audiences outside of the museum and encourage attendance</h3> To help connect outside of the museum, we integrated game center (coming in the second update) so that users can play live against other players around the world. To encourage attendance, there are certain cards that can ONLY be unlocked through special codes found in the museum. To get the most rare and powerful cards, yes you still you need to go the museum. <h3>Make learning awesome</h3> Our friend and Emmy Award Nominee Saxton Moore and his team at <a href="http://pixelpiratestudio.blogspot.com/">Pixel Pirate Studios</a> did all the custom illustrations. The back of each card has a short description about that Character. Users who answer trivia questions correctly get 10 units of power added to their card! More points mean more powerful cards in the Vs game. We've also found that pretty much any age group gravitates to answering the trivia, including 3+ year olds with the help of their parents. <h2>Summary</h2> Specimania from The Field Museum of Natural History represents a celebration of our fascination and love for the sciences. Discovery and education can be fun and current and it takes institutions willing to think outside of the box to truly be successful. We hope you enjoy playing! <h2>Who is Eight Bit Studios?</h2> <a href="http://www.youtube.com/user/eightbitstudios">http://www.youtube.com/user/eightbitstudios</a> <a href="http://eightbitstudios.com" target="_blank">http://eightbitstudios.com</a> <h2>Official Release</h2> Ever wondered what treasures lie hidden within The Field Museum’s vaults? Curious about the creatures that lurk within its halls? Unlock the Museum’s secrets via a new, downloadable iPhone and iPad app that contains collectible cards featuring unbelievable artifacts, animals, fossils, plants and more from the institution’s vast collections. Explore the deck to learn more about the headline-making history of each card character, and test your new-found knowledge with the Trivia Question portion of the game. Or compete with your friends to see who comes out on top! Younger kids can get in on the action, too, by matching card characters in a memory game. Modules Key modules used:  CCK Add Multiple Fields CCK List Content Taxonomy ImageField Imagefield Crop ImageCache Services Why these modules were chosen:  We leveraged the following modules which made this application possible: <ul> <li>CCK - For obvious reasons :)</li> <li>CCK Count - For limiting length of Challenge names</li> <li>CCK List - For Trivia Questions</li> <li>CK Editor - For descriptions of the back of the cards</li> <li>Content Taxonomy - For selecting what hall the card belonged to</li> <li>ImageField Crap & ImageCache - For placing/scaling images for in game and review</li> <li>Services - Using JSON, we fed information directly into the iOS Application binary so that as we deployed the app to a large testing group, it had all the most up to date information from the Drupal site</li> </ul> Community contributions: 

N/A

Team members:  seahostler

Why Drupal was chosen:  <p>Although the implementation that we're about to describe isn't going to be unique in the Drupal-verse, it still presents how some interesting challenges were overcome which may help future Drupalers when they are faced with large volumes of frequently changing, heavy data. It may also help convince business decision makers to use Drupal in ways they hadn't previously considered.</p> Completed Drupal site or project URL:  http://apps.facebook.com/propertyplace/ Describe the project (goals, requirements and outcome):  <p>Although the implementation that we're about to describe isn't going to be unique in the Drupal-verse, it still presents how some interesting challenges were overcome which may help future Drupalers when they are faced with large volumes of frequently changing, heavy data. It may also help convince business decision makers to use Drupal in ways they hadn't previously considered.</p> <h2>Contents</h2> <ul> <li><a href="#prop-a">Background and Project Goals</a></li> <li><a href="#prop-b">Data</a></li> <li><a href="#prop-c">Content Types</a></li> <li><a href="#prop-d">Search</a></li> <li><a href="#prop-e">Modules</a></li> <li><a href="#prop-f">Facebook Integration</a></li> <li><a href="#prop-g">E-commerce</a></li> <li><a href="#prop-h">Hardware & Server Setup</a></li> <li><a href="#prop-i">Performance</a></li> <li><a href="#prop-j">UI</a></li> <li><a href="#prop-k">Implementation Partner Details</a></li> </ul> <h2 id="prop-a">Background and Project Goals</h2> <img src="http://drupal.org/files/pp.png" alt="Property Place screenshot" align="right" /> <p><a href="http://apps.facebook.com/propertyplace/">Property Place</a> is a Facebook application constructed using Drupal 7 that allows users to search, share and sell property via their Facebook account. It offers consumers and selling agents a more intuitive and efficient marketing alternative to existing channels. The application aims to be the number one Facebook property application, and although the app is focused on the UK market at present, it has global ambition and capability.</p> <p>At a high level, the site takes a data feed from a 3rd party that contains every property available to rent or buy in the UK, cleanses it and imports it into Drupal.</p> <h2 id="prop-b">Data</h2> <p>What separates this from a run-of-the-mill Drupal install is the volume of data that we had to contend with.</p> <h3>Data challenges</h3> <ul> <li>Approximately 400,000 active properties.</li> <li>3m supplemental items of information, covering things like rooms sizes and other property features.</li> <li>Data churn of approximately 10,000 new properties a day + up to 30,000 updates + 10,000 deletions.</li> <li>2GB of property data held within CSV format.</li> <li>350GB of property images held in 2,000,000 different files.</li> <li>The new data is made available twice daily via FTP.</li> </ul> <h3>Data cleansing</h3> <p>Due to the volume and quality of data being processed, it was necessary to write a custom import process that sat outside of Drupal and dealt with the initial data load. This process worked by walking sequentially through the CSV file, calculating a hash of each row and comparing them to the hash values we already had within a non-Drupal database for a given property ID. Doing this meant that we were only updating / inserting rows that had changed which is important from a performance perspective. Importing the CSV file into a temporary database also gave us the opportunity to cleanse some of the data held with the CSV where appropriate, and also add new fields that would be useful for the property taxonomy later, such as, price band, property type etc.</p> <p>The other challenge at this stage in the process was that when a property is removed from sale or rent, then the property is just stripped from the data feed. This meant that without some form of additional cleanup process, then a large amount of orphaned properties would exist on the site. To get around this we needed another process to identify those properties that no longer existed within the feed, and then remove them from the site.</p> <p>This part of the data cleansing process takes around 30 minutes, without using the hashing approach, it would have taken closer to 5 hours - a reduction of 90%.</p> <h3>Data Import</h3> <p>With the data from the CSV file now held within a local non-Drupal DB, we need to come up with a way to import it into Drupal.</p> <h4>Feeds</h4> <p>After having had some success with the <a href="http://drupal.org/project/feeds">Feeds</a> module on previous projects whereby we were handling something in the region of 20,000 records with a churn of about 200-500 a day, we initially decided to give it a try on the Property Place project. However, it didn't take us long to realise that we were pushing Feeds to a place that it wasn't designed to go.</p> <p>One of our primary concerns was that using Feeds required us to create an intermediary data format - by default, Feeds lets you pass data to it in either CSV or XML format (although there now seems to be a new module called <a href="http://drupal.org/project/feeds_sql">feeds_sql</a> that allows you to take data straight from a db). In our early tests Feeds struggled handle the volume of data that we were trying to throw at it. It also became especially frustrating for us when a data import failed, as it was often then necessary to delete all the previously imported nodes, and start afresh instead of being allowed to rollback changes.</p> <p>Feeds was also quite inflexible when it comes to updating content which was a huge part of this process. Overall it felt like we were trying to make Feeds do things it wasn't designed for.</p> <h4>Migrate</h4> <p>After realising that Feeds was not the right tool for the job, we decided to try using the another popular data migration / import module in the shape of <a href="http://drupal.org/project/migrate">Migrate</a>. Migrate was developed by a company called Curve and has been used extensively on the migration of several high profile projects to Drupal, such as The Economist and The Examiner.</p> <p>Migrate differs from other import modules in that you have to write your own migration classes as opposed to relying on web UI to configure an import. Although this requires a bit more effort upfront to understand the module and do something useful with it, it does provide much greater flexibility as you are able to run custom code at the point of import. For example, we were able to do things like find images on the local disk and add them to the property if they existed, and add taxonomy terms based on certain combinations of fields.</p> <p>One of the particularly useful features of the Migration module is what it calls a highwater field. The highwater field essentially allows you to make and rollback imports based on date. In the context of this project, to leverage the power of this feature we had to add a last modified timestamp column to records in our non-Drupal DB. We then relied on Migrate to compare the last modified timestamp column in our non-Drupal DB, to the Migrate internal record of the last modified date of the last piece of content that was migrated. Anything that's newer then gets imported/updated. To achieve the same effect with Feeds we were having to dynamically create a csv file of new or updated records, in small enough batches so that Feeds could handle it - it was all just getting a bit too messy!</p> <p>One of the other features that the Migrate module offered us, was that it allowed us to easily collect data from multiple columns and add them to a single multi-valued field in Drupal.</p> <p>What really sets Migrate apart (from a developer perspective) from the other modules that we looked at, is that it allows you to rollback an import, make changes to your code and then re-import. This is a real time saver when you're developing as you'll often need to alter items on the way in to Drupal, test it, modify the code and test again!</p> <h3>Image handling</h3> <h4>Downloading the images</h4> <p>Importing 350GB of images into Drupal using conventional means is a bit of a non-starter, particularly when they are only made available individually, there are some 2 million of them, and the only means of retrieving them is via HTTP.</p> <p>One of the main issues that we found when attempting to programmatically download that volume of images, is that if you are doing it sequentially using CURL or file_get_contents, then you are subject to timeout errors, false 404s and 500 errors - all of which slow the download process. We calculated that doing it this way would have taken some 8 weeks as we were pulling images down at a painfully slow rate of 5 - 10GB a day despite having a lightening quick Internet connection.</p> <p>What we needed was a multi-threaded solution. After considering writing some custom php that utilised that CURL's multi-threading ability, and a variety of other options, we realised that there was a far more simple approach. Step forward the trusty unix wget command. By calling it with only a few parameters, we were able max-out our Internet connection and download every image into an organised directory. In the snippet below you can see how we have chained together wget commands so that they run in parallel - here we have shown three, but in practice we use something nearer ten.</p> <code> sudo wget -x -q -i images.txt & sudo wget -x -q -i images.txt & sudo wget -x -q -i images.txt </code> <p>What each of these statements effectively do is:</p> <ul> <li>Run through each of the images in the images.txt file</li> <li>Download each image into a directory structure that is defined by the url.</li> <li>Only download it if the last modified date of the remote file is newer that the one currently held in the local directory structure.</li> <li>Do this quietly.</li> </ul> <p>This process also works for the ongoing image downloads.</p> <h3>High-level data import process summary</h3> <p>After a fairly long process of trial and error we manged to get the daily import time down to around 90 minutes.</p> <ol> <li>Trigger the import process with a cron job.</li> <li>Get property CSV data from FTP.</li> <li>Verify data with checksum.</li> <li>Import data into holding db whilst performing some data cleansing, and supplementing it with new data.</li> <li>Generate list of properties to be deleted (known by the fact that they were no longer present in the feed).</li> <li>Generate list of images that are associated with each property</li> <li>Start the wget image download process</li> <li>Begin the import using the Drupal Migrate module</li> <li>Add / update properties</li> </ol> <h2 id="prop-c">Content Types</h2> <p>The site is split into 2 main content types; one handles the properties and all information relating to them, the other stores information relating to clients (i.e. estate agents).</p> <p>At the start of the project we had some debate as to what the ideal content type configuration should be, mostly around the properties content type. We didn't know if it was better to have a single properties content type, with references to other nodes that held detail about the rooms along with any specific photo's or notes. This would have meant that the number of nodes held within Drupal would have been in the millions which made us slightly uneasy. In the end we decided to have just one content type for properties, and set it up in such a way that made it possible to store everything that was required - again made possible by the Migrate module.</p> <h2 id="prop-d">Search</h2> <p>With the default Drupal search functionality not really being designed to handle the volume of data that the site contained, it was apparent that we needed to interface with an enterprise grade search tool. We needed a search tool that offered us the following key features:</p> <ul> <li><strong>Faceted search.</strong> This would allow users to filter search results by taxonomy terms that we had set against properties, such as number of bedrooms, price band, house type etc.</li> <li><strong>Advanced sorting.</strong> We needed to allow users to perform a search, filter by several items, and then sort the results on values such as price, date added and the like.</li> <li><strong>Fast.</strong> We needed to be able to deal with several free-text searches a second.</li> <li><strong>Geo-spatial Search.</strong> With all of the properties held within the site having their locations geo-coded, we needed to make sure that the search functionality allowed us to do "distance from" type searches.</li> <li><strong>Scalable.</strong> If the volume of traffic meets the forecasts, then we needed to be confident that we could scale the search functionality to meet the performance demands.</li> </ul> <p>We already had <a href="http://lucene.apache.org/solr/">Apache Solr</a> in mind at the start of the project, and after some research decided that it was still the right solution for us. Primarily because, it comfortably met the above requirements, had existing Drupal module support (<a href="http://drupal.org/project/search_api">search_api</a>, <a href="http://drupal.org/project/search_api_sorts">Search API sorts</a>, <a href="http://drupal.org/project/search_api_ranges">Search API ranges</a>, <a href="http://drupal.org/project/apachesolr">Solr search</a>), had a growing following within the Drupal community.</p> <p>The auto-suggest functionality was implemented in a slightly custom way. To power this, we took data from several different fields at the time of the import process, and import them into a separate "location" table which the auto complete then looks up on. With this table being indexed, the auto-suggestions happen quickly.</p> <h2 id="prop-e">Modules</h2> <p>With performance being a very important part of the project, we tried to use the leanest suite of modules that we possibly could. We have mentioned the key modules that we used for the project throughout this case-study so we won't list them all here again, beyond those we used the all the usual ones that most projects call upon at some stage; views, rules, webform etc.</p> <h2 id="prop-f">Facebook Integration</h2> <p>When it comes to Facebook module options for Drupal, your choices are fairly limited if you require a shortcut to having a Facebook canvas based application. Having built a fair number of Facebook applications in the past, we knew that the level of control that we required could only be achieved by creating a custom module.</p> <p>The key bits of functionality that we required for the Facebook integration, was the auto-login, getting the permissions from the user, social plug-ins and custom posts to wall. To meet all these requirements it was apparent that we needed to use the 3 different elements of the Facebook libraries; PHP SDK, JS API & Social Plugins.</p> <h3>PHP SDK 3.11</h3> <p>Using Drupal to power a Facebook application is nothing revolutionary - all you have to do is include the <a href="https://github.com/facebook/php-sdk">Facebook PHP SDK</a>, perform some authentication and away you go. That wasn't enough for this implementation however as it was necessary to dynamically create a Drupal user account based on their Facebook details to allow for features such as "My properties" and the property upload to work.</p> <p>When developing for Facebook however, there are a couple of gotchas that you should look out for:</p> <ul> <li>You should tweak the settings.php so that cookies expire at the end of the session so that your application session and Facebook session are synced.</li> <li>Be wary of any POST backs from Facebook as they can cause 500 errors under the right circumstances.</li> <li>Make sure that you set the correct headers for you Facebook application (we needed to include header('P3P: CP="CAO PSA OUR"') to prevent a continuous redirection loop in IE)</li> </ul> <h3>JS API</h3> <p>Given that the Facebook login code was handled by the PHP, all that the <a href="http://developers.facebook.com/docs/reference/javascript/">Facebook JavaScript library</a> was needed for was the posting to wall functionality which was primarily via the <a href="http://developers.facebook.com/docs/reference/javascript/FB.ui/">FB.ui function</a>. I have included a snippet of Facebook JS code that we are using within the app that does just this (and have left the comments in so that you can see why developers often become frustrated using the Facebook API!):</p> <code> //Create a Send dialogue. // NOTE: You must use display:popup otherwise it will break - known FB bug // NOTE: You cannot use a Facebook URL in the link otherwise it will break. It needs to be the path that the app sits on. FB.ui({ method: 'send', name: 'Property Place', link: window.location.href, picture: 'http://property-place.net/sites/all/themes/pp/css/i/75x75-pp.jpg', description: 'Check out my selection of properties', display: 'popup' }); </code> <p>There are other basic Facebook JavaScript functions that are pretty much essential for a decent user experience that are probably worth mentioning here, which are:</p> <ul> <li>FB.Canvas.setAutoGrow() - this allows the iframe that your application sits within to dynamically resize. If you don't use this function then you will get scrollbars around you application.</li> <li>FB.Canvas.scrollTo(0,0) - forces the page to go to the top of the iframe that the application sits within after every page reload. If you don't use this then after you click a link within the app, the page won't reload with you at the top, it will instead stay in the same position relative to the outer Facebook surround.</li> </ul> <h3>Open Graph tags</h3> <p>Properly configured <a href="http://developers.facebook.com/docs/opengraph/">Open Graph tags</a> are crucial if you want peoples shares of your content to be as "rich" as possible. This is best illustrated with an example:</p> <ul> <li>Full "Rich" snippet<br><img src="http://drupal.org/files/og-rich.png" alt="" /></li> <li>Non-rich snippet<br><img src="http://drupal.org/files/og-non-rich.png" alt="" /></li> </ul> <p>Open Graph tags aren't difficult to implement thanks to the <a href="http://drupal.org/project/metatag">Meta Tags</a> module. With this installed you can configure it so that the Open Graph tags are dynamically rendered based on fields held within a content type.</p> <h3>Social Plugins</h3> <p>The Facebook <a href="http://developers.facebook.com/docs/plugins/">social plugins</a> have come on massively in the last 12 months, meaning that the need to use the full Facebook JS API can be consigned to highly customised tasks.</p> <p>The one gotcha of using the Facebook Social Plugins in AJAX heavy apps, is that if you're returning any content containing Facebook plugin markup, then you need to tell the Facebook library that you've inserted some into the document e.g.</p> <p>If you return:</p> <code> <fb:like send="true" width="450" show_faces="true"></fb:like> </code> <p>Then you need to call the function:</p> <code> FB.XFBML.parse() </code> <h2 id="prop-g">E-commerce</h2> <p>Properties within the feed get displayed on the website normally and without any special prominence, but there was a requirement to allow users to add their properties to the site manually, for a fee. If a user agrees to pay this fee, then they will have a tiered suite of options about how they would like the property to be featured on the site.</p> <h3>Drupal Commerce Integration</h3> <p>The obvious way of allowing this type of transaction to take place on the site is by using <a href="http://drupal.org/project/commerce">Drupal Commerce</a> and a supported payment gateway.</p> <ul> <li>Commerce is flexible - you can do just about anything you can think of</li> <li>Paying for the node to be published using custom checkout rules</li> </ul> <h3>Facebook Credits</h3> <p>With Property Place being a Facebook application, it made sense that users would also be able to pay for listings on the app using the <a href="http://developers.facebook.com/docs/credits/">Facebook Credits</a> currency. Although this functionality isn't quite in place on the application yet, it is planned for a future phase of development.</p> <h2 id="prop-h">Hardware & Server Setup</h2> <p>Putting the application on a shared server or budget VPS wasn't really an option. We needed something that was capable of handling the data volume, and traffic forecasts.</p> <p>We settled on using Amazon's <a href="http://aws.amazon.com/ec2/instance-types/">EC2</a> offering as it seemed like a fairly cost-effective offering and provided scaling features that we could manage ourselves.</p> <h3>Scalability</h3> <p>At present, the entire application including the Solr server runs off the same server instance. Not great practice from the point of view of sys admin purists, but it works, and saves the cost of an additional server to be setup and maintained.</p> <p>When the current setup gets to the point whereby it looks to be struggling to cope, we will have a couple of options. One option could be put the site assets onto a CDN which would reduce the number of requests that the server has to deal with. Another option could be to put Apache Solr on it's own server, thus massively reducing the mysql load on the primary server... given that the entire site is pretty much driven off search requests. This will buy us some time until the next upgrade is required. At this point we will then have the option to either throw more CPU cores or RAM at the primary server (thanks to the flexibility of Amazon EC2), or think about scaling horizontally and relying on load balanced servers.</p> <h3>Security</h3> <p>One of the requirements of a Facebook application is that the app sits on a server with a valid security certificate.</p> <h2 id="prop-i">Performance</h2> <p>They always say that you should worry about performance at the end of the project, rather than getting distracted by it during a build within reason. Build first, refine later. At the end of the project we spent quite a bit of time trying to get page load time down for all key pages on the site.</p> <h3>xhprof</h3> <p>With so many different modules and systems working together and a less than rapid site loading up in your browser, you need some way of finding out where the bottlenecks in your code are. Short of embarking on semi-educated shotgun debugging mission, it makes sense to employ the help of a tool called <a href="https://github.com/facebook/xhprof">xhprof</a> that has been designed by our friends at Facebook to do just this. When xhprof is used in conjunction with Devel, you have a powerful memory profiler on your hands that is capable of pin pointing optimisation-ripe areas of your site.</p> <p>Our process for speeding up the site was simple; load up a page on the site with xhprof and Devel enabled, look for the listed slow functions, attempt to speed them up, and repeat.</p> <h3>Facebook PHP SDK</h3> <p>One of the major bottlenecks that xhprof identified was the Facebook login code - it was adding some 2 to 3 seconds per page request. The solution to this was simple of course, only attempt to log the user into Facebook at the start of the session, auto-log the user into Drupal using their Facebook credentials that they have just volunteered, and then rely on Drupal sessions to maintain the users session. Logging out is handled by configuring Drupal to end a session at the end of the browser session - this is achieved by updating the following variables in the settings.php file:</p> <code> ini_set('session.cookie_lifetime', 0); </code> <h3>CDN</h3> <p>Although the site doesn't use a CDN at the present time (due to budget limitations), it will be something that we consider should traffic grow to a level where it can be justified.</p> <h3>APC</h3> <p>APC stands for "Alternative PHP Cache". APC is an opcode cache that speeds up your site by caching both PHP code and variables.</p> <h3>Indexing tables</h3> <p>Probably the single most important thing you can do to speed up database queries when you're dealing with large volume of data is making sure that your tables have indexes on. Drupal does this by default on it's core tables, but if you create any database tables outside of Drupal for use with Migrate, then adding indexes will massively speed things up for you.</p> <h2 id="prop-l">UI</h2> <p>We chose to base the front end markup on a theme called "<a href="http://drupal.org/project/omega">Omega Theme</a>". This gave us a lightweight HTML5 based framework that was easy to work with and modify. It also provided a responsive approach that we may be able to build upon for future development work on the site.</p> <p>We used AJAX requests where appropriate to keep initial page response time to a minimum and enhance the usability of the application.</p> <h2 id="prop-k">Implementation Partner Details</h2> <ul> <li>Name company: Zoocha Ltd.</li> <li>URL company: <a href="http://zoocha.com">http://zoocha.com</a></li> <li>Contact email: info@zoocha.com</li> </ul> Modules Key modules used:  Feeds feeds_sql Migrate Meta tags Why these modules were chosen:  N/A Community contributions: 

N/A

Team members:  davepratt

Why Drupal was chosen:  Sparkeo approached us after a shift in focus from building a generic social network using Drupal 5. They understood that they needed to focus on the content creators (who would embed their custom player) and that they needed some more power on the design side and with Drupal. They have a talented development team and a great Drupal consultant that built the original site but could not scale his services to support the next level of complexity and requirements. In looking for Drupal talent, they found us. By using Drupal and switching between consultants and shops that can communicate and cooperate with each other, Sparkeo saved a lot of time and money using an existing infrastructure to build upon and simplified our ability to dive in the project. Completed Drupal site or project URL:  http://www.sparkeo.com/ Describe the project (goals, requirements and outcome):  Sparkeo is a video platform for knowledge entrepreneurs that enables them to create a business by creating, promoting and selling video courses leveraging their expertise. Sparkeo provides a complete toolset for the monetization and creation of interactive courses. Sparkeo is not a destination Web site but a platform where users can create their courses and take them anywhere over the Web as a stand-alone video player. This will allow the content creators to be where their paying audience and students might be, such as blogs, Web sites or any social network. One of the most important features of this solution is the inclusion of a portable payment solution which enables the user to purchase directly from the player itself, <a href="http://www.linnovate.net/blog/sparkeo-drupal-kaltura-powered-e-learning-platform">anywhere it’s embedded</a>. One of the interesting things about the product that we created for Sparkeo is that through its evolution as a project we identified it as a perfect example of the benefits of building a platform under Drupal because it covers almost all of the sales pitches that we (<a href="http://www.linnovate.net/">at Linnovate</a>) use with our potential customers. Modules Key modules used:  Kaltura Views Gigya - Social optimization Ubercart Rules Services Content Profile Why these modules were chosen:  <h2>"Lego-like integration using reusable components"</h2> The emphasis of Sparkeo's solution is not to become a destination site at first, but instead to give independent content creators a powerful platform to monetize the video content they create. They could not do this while embedding the video from an external network like YouTube or Blip because they had to control (and brand) the user experience. Sparkeo designed a beautiful Kaltura-powered player using Inkod-Hypera's UI services and built all kind of goodies into it which needed to be supported by services that we custom built on the Drupal side using the Services module. These services consisted of - <ul> <li>Saving a Highlight</li> <li>Authentication: Enabling you to log in and register through the player independently</li> <li>Comments</li> <li>Highlights</li> <li>Questions</li> <li>Rating</li> <li>Flagging of the content as inappropriate</li> <li>Displaying the biographies of content creators</li> <li>Displaying additional metadata about the videos</li> </ul> Community contributions: 

n/a

Project team: 

Linnovate

Inkod Hypera. Inkod is one of Israel's leading design studios and the company that is behind the design and UI of the Web site and video player. They have a great balance between usability, marketing, business and design skills and we love working with them.

Kaltura. Although we've known the Kaltura team for quite a while, this project gave us a chance to work closely with their services division and together take their platform to new heights. Ninja Flash artists + a strong passion for Web technology = great fun.

Why Drupal was chosen:  N/A Completed Drupal site or project URL:  http://www.vocalo.org/

Vocalo.org is a bold new concept in community media: a complex social media website and an associated broadcast radio station in Chicago, IL.

Vocalo.org is a place for people to compose and share stories -- including images, audio, and video -- with their fellow users. User-generated content is broadcast on the radio station as well as made available on the website for licensed remixing. Vocalo users span the globe, while the broadcast radio station (89.5 FM) and local focus keep the project true to its roots.

Vocalo.org also engages the community with free "Media Creation Workshops" in Chicago-area communities.

The Vocalo.org website was created by the Chicago Technology Cooperative (CTC) on behalf of Chicago Public Radio, using a heavily customized version of Drupal 6. The current version of the site began development in November 2007 and was launched on May 15th, 2008.

Major features:

Integration with the broadcast system at the radio station for syncing on-air playlists and schedules with the website and allowing hosts to easily broadcast user-generated audio on the air.

A cross-browser, AJAX-enabled media library allowing users to seamlessly upload images, audio clips, video files, and media from 3rd party sites like YouTube into an online WYSIWYG editor with a drag-and-drop interface.

Telephone podcasting which allows users to call a hotline and record audio content directly onto the site using only their telephone.
A full palette of online community features including social networking, private and instant messaging, and folksonomy.

CTC was able to leverage the robust contributed module space in the Drupal community, help propel those efforts on to Drupal 6, and develop a new social media platform -- Scald -- to fulfill the vision of the Vocalo project. In the words of Vocalo.org's Online Community Manager, Shannon Heffernan:

CTC has the creativity to develop tools outside the realm of what Drupal provided. It's exciting to work with an organization that is committed to finding specific custom solutions for our needs, while considering how we could both benefit from and contribute to the Open Source Community.

Background:

The original Vocalo.org pilot site, which was built on Drupal 5, was launched in May 2007 after two months of rapid development by CTC. The initial site included some broadcast integration features, basic social networking capabilities, and the ability for users to upload images, audio, and video clips. This early community media sharing functionality was implemented using CCK and Views.

Multiple iterations of the site were released over the summer of 2007, culminating in a version 1.6 release in the early fall. During this period, the broadcast and community media model rapidly evolved with input from Vocalo early adopters, staff, and hosts. The radio broadcast was limited to a small test market on the outskirts of Chicago, and the site was not heavily promoted.

As the concept and pilot site became increasingly popular, Vocalo.org staff and CTC developers jointly developed a plan for implementing Vocalo.org 2.0 with a suite of new features and more sophisticated media management tools for both users and on-air hosts. Plans are underway to heavily promote the site as the on-air radio broadcast footprint expands from the smaller test market to millions of potential listeners in the Chicago metropolitan area in September 2008.

The requirements of the site -- large numbers of content items, sophisticated design, video and audio transcoding, real-time media broadcasting, and an increasing number of users -- demanded that scalability and performance be considered high priority. Though Drupal 6 was still in active development, it was clear that building against Drupal 5 would not satisfy the site's requirements.

Media enabled nodes:

Vocalo.org needed to exercise fine-grained control over the display of media in different areas of the site. Sometimes an uploaded video should be a direct link, sometimes a thumbnail, sometimes presented using a Flash-based player. As developers, CTC faced a competing concern: how to manage highly specified theming without creating a system too complicated to be easily modified or maintained.

The solution was to introduce the concept of display contexts. Each major content type has a global default template, but it can be overridden based on both specific node type and the current display context. Following Drupal conventions, every theme retains the power to override the defaults to account for the idiosyncracies of the particular type of media in question, and allows for the targeting of special cases without duplicating common ones.

The display layer depends on two indispensable modules: Media Mover (which was ported to Drupal 6 by CTC developer Brandon Bergren AKA bdragon) and Imagecache. These modules, and the underlying free software libraries they use, provide the display layer with a powerful set of tools for converting, manipulating, and repurposing an incredible range of media.

Vocalo.org wanted users to go beyond simply uploading a few files -- users should be able to use their media to tell stories via personal blogs, and information about the media used in a post must be available for theming and search. Using Drupal's Input Filters, Scald tracks the use of media in Vocalo's blog posts and attaches information about included media for use elsewhere within Drupal.

Type, Upload, Drag:

The Vocalo.org post creation system creates a cohesive platform for all of Vocalo's content creation tasks: uploading media, browsing one's own and others' media, and the ability to smoothly combine rich media and text into stories. Type, upload, drag: Vocalo.org makes creating stories and uploading media simple and fast.

The custom form workflow and UI depends on a customized version of WYMEditor, and drew heavily from the popups project to provide the user with a swift method for uploading media. On the back end, a modified upload module handles file type detection and utilizes Media Mover to handle the necessary conversions. All the user does is upload a file.

Frustrated by the common conventions for media attachment in other editors, CTC developers Brandon Bergren (bdragon) and David Eads (davideads) created a WYMEditor plugin to allow the user to click and drag media from their library to a blog post, and to see how the media will look in their post. Here, the Scald contextual rendering system found a powerful use: when a user “drops” audio or video into the post editor, what she sees looks like a Flash player, but is really a simple facsimile created with minimal XHTML and CSS. This makes it easy for the editor to manipulate these items, and sidesteps several browser inconsistencies and bugs.

In the database, media used inside blog posts is represented with simple tags which are interpreted and rendered when the posts are displayed. This simple format means that Scald is compatible with a huge variety of rich editors and even the lowly text box.

The Chicago Technology Cooperative's David Eads is actively involved in developing the new, ground-up rewrite of WYMEditor, and bringing it to Drupal.

The media library uses the Scald Data API to allow the user to search and select Scald-adapted nodes based on a variety of characteristics including author, title, description, taxonomy terms, Scald Unified Type, publication status, etc. Scald will work with Views 2 to provide powerful query building to end users, but retains the Scald Data API to allow developers a more specific and efficient method for sifting through media content.

Beyond the the web:

To engage with the broad, demographically diverse population of Chicago, Vocalo.org wanted to provide users with a way to publish their content online without Internet access. CTC developed a telephone podcasting module using the OneBox voicemail service, though the module could be used with any number of similar services.

The system is dead-simple and incredibly robust: A user registers her phone number by adding it to her profile. When the Vocalo OneBox receives a message from the registered number, the audio is automatically posted to her blog.

For the Vocalo.org, this message is attached to a custom node type. Phone audio nodes have a Scald Adapter, which allow them to interact seamlessly with the site. However, the module can easily be extended to route and process the audio in a wide variety of ways. This is another of the modules CTC is planning to release in the very near future.

Online and on-air:

Hosts needed the ability to put together playlists of user-generated and third party content and also to notify users that their content will be on the air. The website needed to provide users with accurate information about the station's broadcast schedule and live broadcast. Additionally the website needed to provide users with ways to interact with the broadcast while online.

To engage users online with the spontaneous nature of the live broadcast, CTC developed a lean, efficient chat system dubbed the ShoutBox. The live hosts post questions to the online audience and discuss the responses on the broadcast. The ShoutBox helps blur the lines between "listener", "user", and "participant".

To help hosts, CTC wrote a custom playlist module which provides the ability to build playlists out of contributed media as well as arbitrary data. To further engage the audience, the playlist module contains a notification system that lets users know their media will be on-air by sending them an email or a private message. The playlist module exploits the Scald system with a drag-and-drop interface and robust search tools for the hosts.

Social networking tools:

The social networking functions of Vocalo.org were effectively met by the existing set of social networking tools in the Drupal contrib space (Buddylist, Privatemsg, Service Links, and Fivestar). When CTC began development of the site, many of these modules were not ported to Drupal 6, so CTC ported and modified them to fit Vocalo's specific needs.

Future development:

As Vocalo.org continues to grow as a site and a community, additional features will continue to be added. Current plans for the future include additional media management tools and more mobile integration, such as the ability to publish multimedia content directly from a mobile phone or handheld. In addition, many community media organizations have been exposed to Vocalo.org and are planning similar efforts in their own communities.

Free software, public media:

With Vocalo.org, Chicago Public Radio has demonstrated that it is on the forefront of bringing the values and traditions of public broadcast media into the so-called Web 2.0 era. The strength and flexibility of Drupal have helped make Vocalo.org the success it is as a place to share, discuss, and interact.

As active participants in the Drupal ecology, a team of CTC developers led by Tom Wolf (t-dub) are currently modularizing much of the custom code created for Vocalo.org so that it can be published on drupal.org. CTC developers will be involved in actively maintaining, extending, and supporting Scald into the forseeable future. In addition, many of the changes and optimizations made to other contrib modules, including Drupal 5-to-Drupal 6 ports, have already been submitted back upstream.

CTC is honored to have the opportunity to help bring this vision into being, and in the spirit of public media, to both draw on the incredible efforts of others to create and nourish Drupal and the many other free software tools used, and to share the fruits of our labor with the Drupal community.

Modules Key modules used:  Scald Media Mover ImageCache WYMeditor Why these modules were chosen:  N/A Community contributions: 

The foundation of Vocalo.org 2.0 is Scald, which abstracts and unifies many types of multimedia content. Scald provides media-oriented data manipulation, display, access control, and caching functionality layered on top of the Drupal CMS.

Any type of node created in Drupal can be adapted for use with Scald. Using the familiar hook mechanism, Scald provides developers with a simple mechanism for creating adapters which determine the appropriate title, description, author, metadata, access rules, and file information for any piece of content. On vocalo.org the various Scald Adapters provide a standardized set of video information for theming and search, regardless of whether the video was uploaded by the user or came from a 3rd party video hosting site.

In addition to providing a consistent interface to media data, Scald's permission system allows for sophisticated handling of data access and editing rules. Vocalo.org must balance protecting its users' copyright concerns while encouraging remixing and reuse. The Scald access system allows developers to represent complex permission rules with a minimum of hassle.

The Chicago Technology Cooperative plans to release a suite of modules based on the work done developing the Vocalo.org media infrastructure. Scald will be released in early September with the other related modules following into the fall.

Team members:  bdragon davideads t-dub Project team: 

Chicago Technology Cooperative (CTC)

Why Drupal was chosen:  Why we chose Drupal The previous version of our site was built on Drupal 5 so we were already familiar with the platform. As the whole site was to be completely redesigned, we built the new one afresh rather than try to upgrade the existing one. We'd had experience of accessing (free) help from the excellent Drupal community and this was a big factor in choosing Drupal again. Plus the Views module in-particular seemed to make it much more powerful and easily adaptable than something like Wordpress. We have one member of staff who writes and adds all the content, and a tiny 'online' budget so we needed something that could be maintained for free whilst still being able to add new pages and functionality. The site has a very heavy illustrative, poster style and deliberately has long (deep) pages - making it quite different from most NGO sites. We wanted the CMS to make the menus, sliders etc work very easily but we also wanted a lot more flexibility within it than most setups. Some of the pages are written mainly in plain HTML rather than being more prescriptive about what goes where. This means that it does require a degree of HTML/CSS knowledge by the user, but it also allows a huge freedom and flexibility in terms of creating custom layouts (for instance the <a href="http://www.warchild.org.uk/issues/child-soldiers">Child Soldiers page</a>). Completed Drupal site or project URL:  http://www.warchild.org.uk

War Child UK is a small charity that helps protect children in some of the world's most dangerous conflict-affected countries. Our main site www.warchild.org.uk is was built from scratch on Drupal 7 in October 2011.

Describe the project (goals, requirements and outcome):  HTML5 and CSS3 As the site was unlikely to have a major refresh for the next few years, we decided to build it using the Boron HTML5 base theme, and it uses some CSS3 properties like border-radius quite heavily. It uses rge CSSPie module to make sure these features render properly for non-CSS3 compliant browesers like IE7 and IE8. The design was created by Mike Kus and then converted to a Drupal theme. Views The site makes extensive use of the excellent Views Module (now part of Drupal core). It has some custom-styled Views Sliders (for instance on the home page) and many pages (like Discography) are Views-Grid based. The fact that these are relatively easy to make and amend is one of the best features of Drupal. Panels As there's a variety of layouts, the Panels module is also used extensively. Once a couple of custom templates were created, these could be used to create many different pages. Static Page Caching The site uses the Boost module to deliver pages to browsers much faster. Rather than querying the database every time it wants to dynamically create a new page, the site instead saves a static .html version of the page in its cache folder and serves that up to the user instead - which is much faster. It took a bit of fiddling to get it set up properly, but it was well worth it as it runs pretty quickly on a fairly basic server environment. Donations As a charity site, one of its most important functions is for online donations. This is perhaps the one area where we struggled most. The donation form is connected to a payment gateway (Worldpay) who process the transaction and then send a simple callback to a MYSQL table on our server. We looked at various shopping cart modules like Ubercart but none seemed to quite fit the bill. It means that we have to go through phpMyAdmin to export the table in csv format to see the donations. We don't have (or want) an SSL certificate and all the compliance issues that go with it, so the transactions are done via a themed Worldpay page. We don't collect or even see the users' card details. The build The site's theme was built internally and then we used an agency (New Digital Partnership) to provide specialist Drupal help to set up some of the templates and functionality. It took about 6 months, though in hindsight and with better planning on our behalf it could have been built much quicker. The result The site was featured as a .net magazine site of the month and gets thousands of visitors per month from CSS gallery sites thanks to its design. The online donations have increased approximately five-fold and the traffic has doubled as the site is more SEO friendly and has made our free Google Adwords campaigns a lot more effective. Apologies if some of the above info isn't as detailed as it might be - I'm a intermediate Drupal user but not much of a PHP coder or module developer - which is why I'm enormously grateful for all the patience and support that people here on the Drupal community have shown me over the last few years! Feel free to post any questions in the comments below. Modules Key modules used:  Views Panels Boost Why these modules were chosen:  n/a Community contributions: 

n/a

Project team: 

Ben
Online Manager at War Child

Why Drupal was chosen:  We chose Drupal as our CMS platform because it is a robust system that is easy to scale. SEO has always been an integral part of our business, so the fact that Drupal handled SEO elements pretty well out-of-the-box was attractive. Completed Drupal site or project URL:  http://www.tax-compare.com/

Tax-Compare is a comparison website that allows visitors to compare the major providers of tax software and select one that will best suit their needs. The site was launched in 2008 as static HTML, but due to the nature of our business, it was re-launched in 2010 using Drupal 6.

Modules Key modules used:  Pathauto Global Redirect Path redirect Keyword Link Views Glossary Why these modules were chosen:  We made our system even more SEO-friendly by using contributed modules <a href="http://drupal.org/project/pathauto">PathAuto</a>, <a href="http://drupal.org/project/globalredirect">Global Redirect</a>, <a href="http://drupal.org/project/path_redirect">Path Redirect</a>, <a href="http://drupal.org/project/page_title">Page Title</a> and <a href="http://drupal.org/project/nodewords">Nodewords</a>. We used the Views module to build all the comparison grids. And finally, a rich resource section was built for Tax-Compare with the help of the Glossary module. Tax vocabulary terms mentioned in the content are automatically linked to a page with a full definition. Community contributions: 

We also made a major contribution back to the Drupal community by submitting a patch for the Keyword Link module. Our patch adds an interface to build keyword link values and pairs. It also has more complicated logic for linking keywords.

Why Drupal was chosen:  There were snags early in the prototyping process. The community building software being used didn't support heterogeneous categorization. We wanted two taxonomies for the same content: one for five discussion topics that would serve as site-wide containers, and another for free tagging. Additionally, we saw issues on the horizon with creating page content that would be separate from the blog, structured under a hierarchical menu, but capable of being categorized just like a blog post. In the technical setting at that time, these features were simply unavailable–at least without extensive custom development. The problems we were up against essentially boiled down to categorization–something Drupal excels at. Beyond categorization, Drupal's community features, configurable content-types, access control, flexible menus, and RSS publishing were attractive. Additionally, content management "at large" was a subject we often visited in our work with Colonial Williamsburg, and had just as often abandoned due to issues of cost, licensing, and interoperability within an already massive web architecture. As a fairly isolated piece within their broad spectrum of web deployments, iCitizenForum.com would be an ideal test-case for the Drupal framework. Completed Drupal site or project URL:  http://icitizenforum.com/

At the end of 2007, Aten Design Group worked with The Colonial Williamsburg Foundation to deploy iCitizenForum.com, a Drupal website about Citizenship. The following case study documents some of the factors that led to choosing Drupal, and outlines the technical approach for the project.

The Colonial Williamsburg Foundation operates the world's largest living history museum in Williamsburg, Virginia. The foundation preserves and interprets a 301-acre Historic Area; operates museums, outreach programs, and the John D. Rockefeller Library; and carries out important research and archaeology pertaining to the origins of America. In accordance with its mission, "That the Future May Learn from the Past", the foundation is concerned not only with recreating the 18th-century experience, but with facilitating education about the idea of America–both in its beginnings, and in its relevance for the future.

iCitizenForum.com, a website that promotes discussion around the topic of Citizenship, is a fitting extension of this core mission.

Describe the project (goals, requirements and outcome):  By the time of Aten Design Group's involvement with the project in late 2007, work had already started. Designs had been produced. A website had been custom-coded in ColdFusion. Community features had been implemented using a .NET-based social software solution. The concept had already gone through several major evolutions, and its stakeholders felt that the latest iteration still wasn't quite spot-on. We began our work with a collaborative discovery process to reassess the primary goals for the website and identify the best steps forward. The central purpose of the project, as defined during this process, would be to engage users with a discussion around the idea of Citizenship. In line with this goal, we established the following requirements: <ul> <li>Use blogs, organized by themes and tags, as the primary means of engaging users.</li> <li>Leverage video as a prominent means for delivering content, in blog posts and elsewhere in the website.</li> <li>Offer forums as a platform for supplemental discussion.</li> <li>Provide in-depth resource materials, including translations for some documents, with background information on the subject of Citizenship.</li> </ul> <h3>Windows Hosting</h3> Colonial Williamsburg runs IIS on Windows NT servers, uses ColdFusion for development, and serves up data with Microsoft SQL Server. It was an uncommon environment for Drupal. Time constraints and a pre-existing service agreement for a dedicated NT server made considering LAMP unrealistic, so we began exploring the viability of hosting Drupal on Windows in a production environment. We installed PHP 5, MySQL, and an IIS module (ISAPI Rewrite) to provide mod_rewrite-like URL rewriting for clean URLs. <h2>Implementation</h2> With server configuration mostly behind us, we began building out the website. <h3>Content Types and Teaser Lists</h3> We implemented content types using the CCK, and created custom PHP blocks to handle content lists. We went back and forth a bit on whether to do this with views or custom queries, but in the end sided with the latter–our decision aided by the fact that lists would need little-to-no editing, and did not depend on joins with CCK fields. Additionally, each "Discussion Topic" category within the website has a correlating Discussion Topic node, assigned to its respective category, which serves as a stub for listing related posts. This approach provides workflow controls for categories that are already available for nodes. New topics won't actually appear in the website until the appropriate user publishes the correlating Discussion Topic node. Throughout the website, custom blocks inspect the current page, determine the current Discussion Topic, and display lists of related content. <h3>Site-wide Call-outs</h3> The client needed a way to call-out any content from within the website in the form of graphic promotions assigned to the right-hand sidebar. This was accomplished by creating a custom block that displays images attached to any content in the website via a CCK imagefield labeled "callout". <h3>WYSIWYG</h3> Originally, content was entered and edited with the help of TinyMCE. We later swapped TinyMCE for Markdown, plagued with the same old problems presented with JavaScript-based attempts at WYSIWYG. (Read more about our thoughts on WYSIWYG vs Markdown.) <h3>CAPTCHA</h3> CAPTCHA was used for all input fields available to unauthenticated users. We chose Math CAPTCHA, rather than image-based CAPTCHA, for accessibility reasons. <h3>Translations</h3> Multiple translations of citizenship resources were accommodated via a custom content type (Page Translations) equipped with a Node Reference field for linking to original texts. Each translation features an overview "about" page that provides a description of the content and goals within iCitzenForum.com, as well as a list of all additional resources available within the website in that specific language. Because the implementation uses a custom content type with a CCK node-relate field, dynamically generating these lists, and linking each translation page back to its respective source, was relatively simple. Throughout the website, translations are represented visually as a series of flags beneath the title of any document where additional translations are available. In the site-wide footer, these same flags each link to an overview "about" page for the respective translation. <h3>Video Content</h3> Some of the most interesting functionality at iCitzenForum.com involves its handling of video content. Early in the project, we simply allowed content contributors to paste embed code from YouTube, Vimeo, Blip and similar websites into the body field of blog posts. Later, we began discussing a way of aggregating posts that contain video into a single, self-contained video library. Additionally, video editors at Colonial Williamsburg wanted the ability to more closely control the quality of videos being published, which in this case meant hosting the video locally. We wanted to maintain the ability to syndicate video to third-party video websites, but wanted to better manage the quality of original videos posted within iCitizenForum.com. These new requirements pushed additional development in two directions. First, we needed a way to list video posts together in a library-like setting. Second, we needed to dynamically push videos out to services like YouTube. <h3>Video Library</h3> To accomplish the first requirement, we created a simple module called VideoLib that provides a configurable view for displaying video content, relevant taxonomies, and related videos within a single view-port. The module exposes several theme functions that offer in-depth control over the look and feel of the video library. It includes JavaScript that applies unobtrusive AJAX actions to the taxonomy and related video navigation, providing a highly responsive, single-page experience for users. Video is attached to content via a CCK file-field labeled "video". Any content type can behave as video content simply by adding the "video" field to it. Within the settings page for VideoLib, admin users can specify which content types that have the "video" field should be included in the video library. Additionally, administrators can choose which taxonomies to expose as navigation blocks. In this case, we wanted Discussion Topics to appear as navigation options down the left side of the page, but not Tags. It is worth noting that we could have used a combination of page and block views to accomplish a similar end result. We opted instead to create a custom module that rolls all of the necessary functionality into a single, more portable, centrally managed feature for this website, with potential application for future projects as well. <h3>Link Rewriting</h3> Stepping back a moment to the video library functionality, it is worth going into a bit of detail about the way we handled linking. Within the video library itself, all links are routed to URLs that appear as "videolib/{term id}/{node id}", a menu path controlled by the VideoLib module, which in turn handles all of the necessary functionality for displaying videos. We wanted to go beyond this, and make sure that any node within the video library could be displayed outside the library as well (in teaser lists, for example). To accomplish this, we used the custom_url_rewrite system hook function in settings.php. Within that function, we detect if the "node/{node id}" path belongs to a video post. If it does, we dynamically rewrite the URL to "videolib/{term id}/{node id}". <h2>Wrapping Up, Moving Forward</h2> Drupal's robust taxonomy features, combined with its powerful content management capabilities that, while excelling at community features, provide more than a social-software solution, made it an excellent choice for the iCitizenForum project. The initial Drupal-powered deployment launched just eight weeks after redesign efforts began, largely due to the wide range of features already available in core and contributed modules–without the need for extensive custom development. Since launch in early 2008, numerous new features and modifications have been incorporated back into the website. Moving forward, the vision for iCitizenForum.com is that it continues to evolve and adapt. Drupal, with its modular architecture, support for open standards, and passionate community, continues to be an ideal platform for the project. Modules Key modules used:  Youtube API Why these modules were chosen:  The Youtube API module was developed for the project. Community contributions: 

The development effort for the video syndication capabilities, spearheaded by Brad Bowman, quickly evolved into a full-fledged YouTube API module that offers a wide range of interface capabilities that go far beyond the initial needs for simple content syndication. The YouTube API module provides functions for programmatic video management, FeedAPI integration, video feeds, commenting, authentication, rating, and managing favorites between Drupal websites and YouTube.

In addition to automatically pushing content to YouTube and Vimeo, the video library features a video-specific RSS feed that includes all nodes from within the library, their teasers, and their associated videos.

Team members:  beeradb Project team: 

Aten Design Group

Why Drupal was chosen:  Made with Drupal 5 this site is still an awesome example of successful implementation. Completed Drupal site or project URL:  http://www.popsci.com/

In February 2008, Popular Science, the fifth-oldest continually-published monthly magazine, relaunched its online presence with an enterprise-level website developed by pingVision, powered by Drupal.
http://drupal.org/node/233090

Describe the project (goals, requirements and outcome):  Until the year of relaunch, Popular Science's online presence was dominated by proprietary web content management solutions. With this relaunch, the Popular Science team wanted to take the online presence of the magazine into the open source world. <h2>Website Goals and Challenges</h2> Prior to its relaunch, the Popular Science website used various different systems to deliver content. One of the goals for the new site was to bring these disparate sites together into a unified user interface while increasing usability and functionality. Drupal's inherent flexibility and extensibility afforded the delivery of Popular Science's usability and functional requirements. One of the big challenges, however, was converting and importing several years' worth of content from a Vignette 7 CMS and several TypePad blogs. Another challenge was the integration of several third-party services, including a fantasy stock trading system, video conversion and hosting services, and advertising. In approaching the development of the new PopSci.com, we took advantage of various contributed modules, and created a number of custom modules, including the Drupal Markup Engine for content placement within nodes and Node Carousel for displaying content. Finally, scalability was a primary concern, as PopSci already had a large and active user base. By specifying a load-balanced multi-server cluster to serve up the site, combined with the use of Memcache, PopSci.com post-relaunch was able to weather an average load of 60 pages per second with a spike of over 1.1 million page views in 24 hours -- a new record for Popular Science. <h2>Content Types</h2> It was important to the PopSci.com editors that they have complete control over the placement of media and supporting content not only in full node view but also in teaser view. They wanted the ability to paginate long articles and place any number of images or even related blocks into the content of a node. The media placement also needed to be intelligent enough to work with legacy content imported from Vignette and Typepad. Most of this was accomplished with the creation of a new module called the Drupal Markup Engine, or DME. The DME works in conjunction with the content-types that were created for this project with the Content Construction Kit (CCK) by providing a custom, extensible input filter. <h3>Articles</h3> Articles are the main content-type on the site. All blog posts from TypePad and articles from Vignette were consolidated as articles in Drupal. The article content-type uses the DME extensively. Referenced images can be placed anywhere in an article using the DME. If a referenced image node isn't specifically placed within the content body by the DME, it is automatically displayed at the top of the article and in the article's teaser view. Images may also be placed directly in the teaser using the DME. This approach provides maximum flexibility with images entered through Drupal and with images from legacy content, which required no human intervention to make the latter work. The DME is also used to place a related content block (containing links to nodes in Node Reference fields or nodes with similar taxonomy terms) into the content and to set pagination for the article. <h3>Article Structure</h3> <ul> <li>Article Images -- Node Reference to images used in the article.</li> <li>Associated Photo Gallery -- Node Reference to an Photo Gallery.</li> <li>Body -- The article's body.</li> <li>Category Badge -- A taxonomy image that will apply a graphical badge to the article.</li> <li>Credit -- The credit is the contributor of the article.</li> <li>DEK -- A brief description of the article.</li> <li>Primary Category -- The primary taxonomy for the site represented by the main navigation areas.</li> <li>Related Articles -- Node Reference field to relate other articles.</li> <li>Tags -- An auto-fill taxonomy field.</li> <li>Title -- Core title field.</li> <li>V7id -- The Vignette 7 ID of the original article so that it can be cross-referenced. This was useful for redirecting old urls to new Drupal content. [See discussion about imports below]</li> <li>Video Link -- Node Reference to related videos.</li> </ul> <h3>Current Issue</h3> The "current issue" node type represents an issue of the magazine. It is used to store images of the magazines cover associated with dates. This node type is used in various promotional content throughout the site. <strong>Current Issue Structure</strong> <ul> <li>Cover -- An image representing the magazine cover.</li> <li>Issue Date -- Publication date of the issue.</li> <li>Title -- Core title field.</li> </ul> <h3>Featured Tout</h3> The Featured tout is a node type created to be used solely in a Node Carousel driven by a Node Queue. The featured touts simply require the Popular Science editors to create graphics that are of the appropriate dimensions. These can be seen on the front page of http://popsci.com/. <strong>Featured Tout Structure</strong> <ul> <li>Associated Article -- Node Reference to the article being touted.</li> <li>DEK -- A brief description of the article being touted.</li> <li>Index Display Link -- The word used as the link in the tout.</li> <li>Title -- Core title field.</li> </ul> <h3>Images</h3> Images are used extensively on the site and needed to be invoked in a number of ways. Images are used in different forms in articles, teaser widgets, and photo galleries. If an image has related content, links to that content are shown in all but teaser views. Images are not served as stand alone images on the site but are invoked in Articles and Photo Galleries. <strong>Image Structure</strong> <ul> <li>Credit -- The contributor of the image.</li> <li>DEK -- A brief description of the image.</li> <li>Photo Gallery Link -- Node Reference to Photo Galleries. If an image references a gallery it shows up in that Photo Gallery.</li> <li>Photo Gallery Weights -- This field contains a series of number pairs with each pair representing the photo gallery and the image's weight in that photo gallery.</li> <li>Primary Category -- The primary taxonomy for the site represented by the main navigation areas.</li> <li>Title -- Core title field.</li> <li>V7id -- The Vignette 7 ID of the original image so that it can be cross-referenced. This was useful for redirecting old urls to new Drupal content.</li> <li>Video Link -- Node Reference to related videos.</li> </ul> <h3>Photo Gallery</h3> A Photo Gallery is a node type serving to collect image nodes and content to be displayed to the end user as a photo gallery. The images are designated for a photo gallery by editing the image and entering the gallery title in the appropriate Node Reference field. Galleries are presented as Node Carousels to give them a slick, interactive feel. <strong>Photo Gallery Structure</strong> <ul> <li>Category Badge -- A taxonomy image that will apply a graphical badge to the image.</li> <li>Credit -- The contributor of the image.</li> <li>DEK -- A brief description of the image.</li> <li>Icon -- A Node Reference field to the image to use when viewing the gallery in teaser view.</li> <li>Primary Category -- The primary taxonomy for the site represented by the main navigation areas.</li> <li>Tags -- An auto-fill taxonomy field.</li> <li>Title -- Core title field.</li> <li>V7id -- The Vignette 7 ID of the original image so that it can be cross-referenced. This was useful for redirecting old urls to new Drupal content.</li> </ul> <h3>User Video</h3> The Video node enables posting of video to either YouTube or OnStream. We developed a custom media module, which creates a custom Media Profile CCK field that can be attached to any node, allowing editors and admins to restrict the services used on a per-content-type basis. The custom media module differs from the existing emfield module by offering greater flexibility -- such as allowing users to upload videos to the services straight from Drupal. <strong>Video Structure</strong> <ul> <li>Category Badge -- A taxonomy image that will apply a graphical badge to the video.</li> <li>Credit -- The contributor of the video.</li> <li>DEK -- A brief description of the video.</li> <li>Primary Category -- The primary taxonomy for the site represented by the main navigation areas.</li> <li>Tags -- An auto-fill taxonomy field.</li> <li>Title -- Core title field.</li> <li>Video Link -- A hosted video handled by an extension to the media module.</li> </ul> <h3>Data Import</h3> Part of the motivation to move the existing content over to Drupal was to escape the rigid complexity and cost associated with the Vignette CMS. The Vignette dataset was a 1.66GB Oracle database -- and that didn't include the more than 15,000 images referenced in the Vignette data which also had to be imported into the new site. The first step in the migration process was to use the MySQL Migration Toolkit to transfer the data to MySQL. We wrote a custom module that used cron to feed the Oracle data through Drupal's APIs in manageable chunks. And finally, we imported the images by extracting their locations from the Oracle data and, via shell script, executing a series of wget commands to download the images. As each piece of content was created in Drupal it was tagged with the Yahoo Terms module, which despite some odd results provided a good start on tagging the immense amount of un-tagged Vignette data. Once the preparations were in place, the entire import process took approximately two solid days of execution time to complete. A portion of the import process centered around how to deal with the urls that had been generated by Vignette, so that an article called up by its old Vignette address could be found in the new Drupal architecture. In order to accomplish this, during the import we took the associated Vignette ID for each unit of information imported from Vignette into Drupal and placed it into a CCK field in its destination node in Drupal. To actually find those articles in Drupal, a hook was written that works with the Custom Error module to look for the old Vignette ID in the url when a 404 occurs and issues the correct redirect code. Not only were we able to handle the redirects while historic links were used, but in a very short time Google had updated their search results showing the new paths. <h3>Search</h3> The design of the PopSci search results required the search results to be grouped by content type, with tabs allowing re-sorting of the results by Most Relevant, Most Recent, Most Viewed, Top Rated, and Most Commented. On top of that, users needed to be able to subscribe to rss feeds of the results. We achieved this functionality by developing an extended version of Drupal's core search, displaying the various results in blocks of paginated content, with AJAX tabsets to access other sortings of the results. Each search is also cached, given a hashed id, and associated with the user performing the search to allow the saving the searches for future reference. <h3>AJAX Tabs</h3> In many instances the design comps we received required a nested set of tabs that could function to filter the content being displayed on a particular page. This was largely handled by the Tabs component of the Javascript Tools module. However, the large tabbed datasets displayed on each of the main category pages and in searches needed to be a custom coded solution to be able to work in a responsive fashion with larger amounts of data. <h3>Performance</h3> Naturally, there is a hefty selection of hardware powering the Popular Science website, but the true performance winner of this project was the Memcache module which integrates Drupal with Memcached and the PECL Memcache library. Out of the box, this module worked extremely well for us, with the exception of path aliases: A full page load was generating as many as 700 queries to determine path aliases. Pulling these queries through Memcache gave us the speed we needed to maintain an initial average load of approximately 60-70 page views per second. Modules Key modules used:  abuse Avatar Approval Custom Error jQuery Update Pathauto Update Status URL list Account reminder LoginToboggan Content Construction Kit (CCK) Date Fivestar ImageField Link AdSense API Coder dba views Devel Javascript Tools SimpleTest Filter by node type HTML corrector ImageCache Taxonomy Image CAPTCHA Why these modules were chosen:  These modules were chosen to be able to implement demanded functionality. Community contributions: 

Unknown.

Organizations involved:  PINGV Team members:  AjK alasda cyberswat coltrane ezra-g greggles gregnostic jcfiala Project team: 

Katherine Lawrence http://drupal.org/user/42890 - unfindable with autocomplete

laura s - Laura Scott
matthews - Matthew Saunders
skywalker2208 - Simon Laug
3goose - Radovan "Rad" Anzulovic
zarabadoo - Al Steffen

Why Drupal was chosen:  On my previous site, <a href="http://www.biologynews.net/">Biology News Net</a>, I hit the limitations of <a href="http://www.movabletype.org/">Movable Type</a> really fast; adding functionality was complicated, performance was not great (even on a dedicated server), customization was not really doable. Just as an example, the forum is actually a phpBB installation that has its sessions tied to the Movable Type sessions - it's clunky even if it works, and upgrading is a nightmare. As I could not really expect more from a blogging engine – Movable Type served me well - I searched for something better - this is when I found Drupal and fell in love with it! It has a significant learning curve, but it is so powerful that the time invested to learn it is easily worth it in the long run. Completed Drupal site or project URL:  http://esciencenews.com/

Eureka! Science News is a site dedicated to provide the very latest science news, but with a special twist – it is entirely automated! There is no human editor behind it - it finds relationships between news stories from all major science sites and regroups, categorizes, ranks, tags, finds related press releases and publishes them directly on the site. The result is an efficient overview of everything happening in science, right when it happens.

Describe the project (goals, requirements and outcome):  I wanted to build a site that would report science news as it happens. I felt the need to automate the process while keeping the quality at a high level. So much science news is posted every day, but frankly, not all of it interesting. I found the inspiration in initiatives like <a href="http://www.techmeme.com/">Techmeme</a> and <a href="http://news.google.com/">Google News</a>. <h2>Building the Eureka Engine</h2> First, I identified the principal components of an intelligent news aggregator: <ul> <li>A source of news, such as an RSS aggregator</li> <li>A clustering engine, to group news together</li> <li>A classification engine, to categorize the news (Is this Biology, Physics, Medicine or Astronomy?)</li> <li>A way to assign scores to clusters, to determine in which order the news should be displayed</li> </ul> First, I needed a good RSS aggregator; the default one provided by Drupal was inadequate, as it did not create Drupal nodes out of RSS items. The other aggregators available at the time were Leech and Feedparser, but they were implementing lots of functionality I did not really need and were not yet mature. Fortunately, <a href="http://tedserbinski.com/">Ted Serbinski </a>(<a href="http://drupal.org/user/12932">m3avrck</a>) came to the rescue, releasing <a href="http://drupal.org/project/simplefeed">Simplefeed</a> just when I needed it. Simple, fast, efficient: I could not ask for more! Next, I built three custom modules to implement the remaining functionalities. The process was easy thanks to the infinite extensibility of Drupal – the hooks system is just wonderful! The result is what I call the Eureka! Engine. Here are some details about these three modules: <h3>Clusterer.module</h3> The first step is to regroup similar items in clusters. Two things are needed to cluster items together: a similarity metric and a clustering algorithm. In the case of text, similarity metrics can be based on the occurrence of words in two texts – a document can be represented as a vector (see <a href="http://en.wikipedia.org/wiki/Vector_Space_Model">vector space model</a>). Fortunately, MySQL Fulltext engine does exactly this – by using a whole article as a fulltext query against all other articles, it is possible to calculate a similarity score between every pair of articles. I use a sliding window technique to limit the number of items clusterer.module needs to look at (highly related news items are often published in a relatively small timeframe so looking at a ‘window’ of a few days worth of news at a time is adequate). Hierarchical clustering algorithms have a complexity of O(n^2), sometimes worse, so it gets exponentially more expensive to compute clusters as you add more items. To regroup items, I used a <a href="http://search.cpan.org/~mdehoon/Algorithm-Cluster/perl/Cluster.pm">Perl API to a C library</a> implementing hierarchical clustering; it is very fast, clustering a thousand items in a few seconds. I initially tried to implement my own clustering algorithm in PHP but it was slow and memory inefficient. Do not reinvent the wheel if you do not have to! Lots of tweaking was necessary to find the ideal clustering parameters that would allow great precision and accuracy. Be too permissive and you end up with mega clusters of unrelated stories - be too restrictive and related stories do not cluster together anymore. In the end, I got something very satisfying. <h3>Categorizer.module</h3> There are many classification algorithms out there; I needed an accurate one, but most importantly, a very fast one (many items to classify from RSS feeds). I chose a <a href="http://en.wikipedia.org/wiki/Naive_Bayes_classifier">naïve Bayesian filter</a> – your email software probably uses a similar approach to determine whether incoming mail is spam or not. In the case of Eureka Science News, the algorithm needs to classify incoming news items in eight categories – Astronomy, Biology, Climate, Health, Math, Palaeontology, Physics and Psychology. For this purpose, I ported / reworked a <a href="http://www.xhtml.net/scripts/PHPNaiveBayesianFilter">naïve Bayesian php library to Drupal</a>. It is reasonably fast and categorizes a new item in about a tenth of a second. The system is surprisingly accurate once trained properly - of course, it makes errors every now and then (especially when it encounters a post made up of words it did not see before) but I am pleased with its performance so far. In the future, the system could be improved by using <a href="http://en.wikipedia.org/wiki/Latent_semantic_analysis">latent semantic analysis</a>. <h3>Publisher.module</h3> Finally, I built a module to rank clusters of news and to find and parse related press releases. The module ranks clusters based on the number of items they contain, the timeliness of each of those items and a few other factors such as popularity – the score is time-decayed using a formula based on radioactive half-life decay, keeping only fresh or popular news at the top of the front page. The system as a whole outperformed my expectations; it even outsmarted me on a few occasions where it found links between stories I did not think were related (why did it regroup those four articles, they are not highly related! Oh, wait… they are slightly related but were presented at the same international conference! Cool!). You should be able to do the same on your sites pretty soon - thanks to the <a href="http://drupal.org/node/261340">memetracker.module</a> from Kyle Mathews, a Google Summer of Code 2008 student! He plans to build a generic framework which will allow the automatic clustering and classification of Drupal nodes. Cannot wait to see what kind of implementation he will come up with – a generic framework is more complicated to build than a site-specific one such as Eureka Science News. <h2>Search: Meet the Sphinx</h2> At first I used Google Site Search as the search solution, as I felt that Drupal search.module could not keep up with a very large number of nodes (the site produced about 50 000 nodes in a month and a half during testing – what about in 5 years, with more sources?). With Google Site search, the updates were not instant, (there is a significant delay between when an item is published and when Google will crawl it), the interface was also very restrictive - even if I could integrate the results directly in the site, I could not alter the layout or results in any way. I discovered <a href="http://www.sphinxsearch.com/">Sphinx Search</a> thanks to <a href="http://drupal4hu.com/node/129">a post made by chx on his blog.</a> It is easy to configure and extremely fast - it indexes hundreds of thousands of nodes in mere seconds and searches are all returned in one second or less. Using a “main + delta” scheme of indexing, I can index news as soon as they are published. In addition to the search form, I used one of sphinx built-in function to generate our stopwords list (for clustering / classification). <h2>Design</h2> I used a CSS framework: <a href="http://code.google.com/p/blueprintcss/">Blueprint CSS</a>. It is ideal for a grid design (which in turn is great for news sites). The results obtained with Blueprint are cross-browser compliant which is a huge timesaver. The framework comes bundled with a CSS reset (so that the site will look the same in every browser) and a nice basic typography which keeps a vertical rhythm of 18px (this means that every line of text will fall on the same virtual ‘line’, giving a virtual rhythm which is nice to the eye). Coupled with Panels.module, it allowed us to create the design of most major pages on the site in record time – it is also very simple to test different layouts since it is so easy to use. Even when using a framework, CSS still has pitfalls – I was hit by somewhat obscure bugs in different browsers (guillotine bug, some menu completely disappearing in IE6, just to name a few). I used <a href="http://browsershots.org/">Browsershots.org</a> to a great extent – screenshots of your site in just about every browser, free! <h2>Performance</h2> Performance is always the #1 concern when building a site with a potentially huge number of nodes. Eureka Science News is quite complex, so I generated custom SQL for almost everything instead of using the Views module - just about every query is optimized and thus very fast. Views is used exclusively for the Archive. MySQL optimization is important and the Drupal page caching mechanism and the MySQL query cache are not an excuse to have badly optimized queries. What if I want users to register in the future? What about the one user hitting an uncached page that is forced to wait seconds while the page loads? Servint – I installed APC cache, tweaked Apache and Mysql but did not yet install more advanced performance improvements like Memcache. Right now AB (Apache benchmark) gives us upward of 500 requests per second on a cached page, which is very satisfying. I applied the <a href="http://developer.yahoo.com/yslow/">YSlow</a> principles thoroughly – a special thanks to Wimleers for his <a href="http://wimleers.com/article/improving-drupals-page-loading-performance">detailed post about YSlow vs Drupal </a>– while I left things out like using a Content delivery network for now as I feel it is overkill, I keep a very interested eye on Wimleers CDN.module. Some of the things which made a small but noticeable difference on the page loading times: <ul> <li> Minified CSS and JS using <a href="http://developer.yahoo.com/yui/compressor/">Yahoo YUI compressor</a></li> <li> Aggregated JS and CSS</li> <li> Used CSS sprites for small icons</li> <li> Used PNG crush and <a href="http://people.bath.ac.uk/ea2aced/tech/png/pngslim.zip">PNGslim</a> to reduce the size of all the images on the site</li> </ul> I also used Drupal cache_set and cache_get functions for SQL intensive blocks that are on every page - like the ‘popular’ block. Be wary of implementing tons of javascript plugins, as that can affect load time performance. At one point the ‘recent images’ block on the front page were embedded into a javascript carousel, but it impacted the page load times significantly (users had to download additional images that they wouldn’t see most of the time, plus the actual javascript parsing and execution time was significantly high - 500 milliseconds for that carousel alone). Sure it looked cool, but cool is not our #1 priority, performance is! Drupal page cache is great for anonymous users, but can also create problems; I wanted to display the amount of time elapsed since the publication of news items in some place (‘published 2 hours ago’) but with minute precision. I did not want users to see for example ‘published 1 minute ago’ for 10 minutes. I resolved the problem by porting Drupal format_interval function to JavaScript. The optimization paid off as the site was hit by Reddit (two different stories), YC News and Stumbleupon the day of the launch and the following days: the relatively modest VPS did not even break a sweat; page loads were still instant, even with about 3000 page views within a few hours, about 15 000 in a few days. Since then we have been hit by Slashdot multiple times and were featured on the front page of Mashable with no performance problems whatsoever. I feel confident that a single VPS will be able to handle the growth of the site for quite some time. <h2>Miscellaneous</h2> <h3>Developing on Windows</h3> Doing web dev work on Windows is possible! I built everything using Windows exclusively – using <a href="http://www.en.wampserver.com/">Wamp</a> and Notepad++ mainly. I also could not live without the Firebug and the <a href="https://addons.mozilla.org/en-US/firefox/addon/4125">‘It’s all text!’</a> extensions for Firefox. Modules Key modules used:  SimpleFeed Views Pathauto Global Redirect ImageCache Panels Taxonomy Access Control Quickstats Service links Why these modules were chosen:  n/a Community contributions: 

n/a