Agregador de canals

El proper dijous 10 de maig, dins del marc de les sessions mensuals organitzades per Drupal.cat, es durà a terme una sessió d'introducció a Rules.

Rules ens permet l'automatització de certes tasques en resposta a determinats esdeveniments al nostre lloc web. Això s'aconsegueix mitjançant l'ús de regles ECA (Event Condition Action). D'aquesta manera, substitueix el mòdul Trigger (Core Drupal), augmentant les seves funcionalitats.

Aquesta sessió consistirà en una introducció teòrica al mòdul i a les seves característiques, amb una segona part de demostració pràctica. En qualsevol cas, no es tracta d'un taller i no és necessari portar ordinador (tot i que pot ser interessant per comprovar allò que es vagi explicant).

La durada de la sessió serà d'una hora amb mitja hora per a preguntes.

El ponent serà en Modesto Caballero, desenvolupador freelance especialitzat en Drupal.

data:  10/05/2012 - 18:30 - 20:00 Lloc: 

Citilab de Cornellà

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.

Els propers 15-16-17 de Juny es durà a terme a Barcelona el Drupal Developer Days Europeu. L'esdeveniment tindrà lloc a les instal·lacions del Citilab de Cornellà.

L'esdeveniment s'està organitzant des de drupal.cat, però ens cal molta més ajuda. Per això t'animem a participar com a voluntari.

Adopta un drupaler! Si vius a Barcelona o rodalies i tens espai a casa teva (ni que sigui un sofà) i no t'importaria allotjar durant la setmana del drupal developer days contacta amb nosaltres.

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

El proper dijous 12 d'abril, dins del marc de les sessions mensuals organitzades per Drupal.cat, es durà a terme una sessió de node.js.

Node.js es una plataforma de programació d'aplicacions en xarxa amb JavaScript seguint el paradigma d'orientació a events. D'aquesta manera l'aprofitament de la màquina on s'executa és màxim. Encara que la seva característica principal i per la qual està destacant tant en la actualitat tecnològica és la velocitat de resposta en sistemes client-servidor. Està especialment orientat a construir aplicacions on és necessari mantenir moltes connexions obertes de manera simultània. Concretament és ideal per aplicacions RTW (Real Time Web). Node.js és un complement ideal per a Drupal quan es tracta d'incloure capacitats de temps real en el nostre lloc.

La sessió estarà especialment orientada a les capacitats i recursos de Node.js en relació amb aplicacions web i concretament amb Drupal. El nivell de la sessió és introductori.

Arquitectura

Node.js segueix un model d'execució "single-thread", "non-blocking" i "event-driven". Veurem què significa i per què és preferible, en determinades aplicacions, a altres models de execució.

API

Node.js està construït al voltant del motor JavaScript de Google Chrome, el V8. Els seus creadors han dotat a JavaScript de les biblioteques necessàries per executar funcions d'IO (entrada i eixida), bé a disc, bé a xarxa, carregar biblioteques, executar processos de sistema, i altres capacitats per tal de poder construir programes complets de servidor.

NPM i mòduls destacats

NPM és el gestor de paquets estàndard de Node.js. Permet, instal·lar (d'un repositori central) i dur a terme tasques de manteniment de les extensions (mòduls) que puga necessitar la nostra aplicació. Veurem també els mòduls més destacables en relació amb aplicacions web.

Crítiques i problemes data:  12/04/2012 - 18:30 - 20:00 Lloc: 

Citilab de Cornellà

llegiu més

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:  With the overload of fitness fads and training trends out there, Chunk Fitness is a response to the confusing and often misleading information found online. Many sites offer quick fixes to fitness issues but Chunk Fitness relies on a more traditional approach of healthy eating, cardio exercise, and weight lifting. Completed Drupal site or project URL:  http://www.chunkfitness.com/

With the overload of fitness fads and training trends out there, Chunk Fitness is a response to the confusing and often misleading information found online. Many sites offer quick fixes to fitness issues but Chunk Fitness relies on a more traditional approach of healthy eating, cardio exercise, and weight lifting.

Describe the project (goals, requirements and outcome):  The Theme We started off with the Zen Theme 6.x-2.1 and cultivated our branding around that. The Zen Theme is incredibly powerful and flexible. We are very proud to say that we have our site looking 99.9% similar across all the major browsers from IE7-9, Firefox, Safari, and Chrome. Some other interesting techniques used with the theme are hand crafted PNG sprites. We found it most effective to use two sprites for the entire site (obviously a single image on a single page will not be put into the site sprite). The first sprite was created for images that appear across all or most pages of content throughout the website. The second sprite was made just for the home page. The rotating banner on the home page was created with a stand alone PHP script called Front Page Slide Show. It may be updated to Views_slideshow at some point. Originally designed with a standard drop down menu, Chunk Fitness was desperately in need of something more robust due to the sheer amount of content that is planned to be produced. The best user experience device we could implement to achieve a logical approach to listing out these options was a Mega Menu style drop down menu. Modules Key modules used:  Embedded Media Field Superfish Flag AddThis Taxonomy Super Select (TSS) Why these modules were chosen:  Critical Drupal Modules Obviously just about all Drupal sites use modules like views and taxonomy so we won't mention those. These are less mainstream modules that really make Chunk Fitness what it is. Community contributions: 

Unknown.

Why Drupal was chosen:  The SSES courseweb project had as a goal to extend the existing website for Stockholm School of Entrepreneurship, from being (more or less) a brochure site, to a site where: <ul> <li>course administrators (“registrars”) keep their CRM, searching and managing profile information for students, teachers, event speakers and more;</li> <li>course administrators can add and manage courses, and manage student applications for courses;</li> <li>teachers can log in and manage courses that they give, including adding assignments for students, blogging, and publishing course schedule and documents; and</li> <li>students can log in and get relevant information about their courses as well as hand in assignments.</li> </ul> Completed Drupal site or project URL:  http://www.sses.se Describe the project (goals, requirements and outcome):  Before starting the development, we considered creating a new site instead of extending the existing one. Drupal 7 was an attractive option, mostly due to how <a href="http://drupal.org/project/og">Organic groups</a> (and now also <a href="http://drupal.org/project/workbench_access">Workbench Access</a>)would have simplified our access functionality, but other complex requirements – combined with the maturity of Drupal 6 modules – made us decide for Drupal 6. Having the courseweb on the existing site was no requirement from the client, but a single sign-on was desired. This, combined with almost completely separated functionality, made us conclude that extending the existing site was probably the best choice. It has caused <em>some</em> problems, but we have not regretted the decision. To allow for extending the site in a clean way, all our new functionality was packaged and deployed as <a href="http://drupal.org/project/features">features</a>. The site ended up with eight new features: <ul> <li>cw_profile: Stores configuration relating to importing and merging profiles, as well as creation of user accounts. This is a big feature.</li> <li>cw_course: Stores configuration relating to courses and adding students to courses. This is a big feature.</li> <li>cw_assignment: Stores configuration relating to student assignments and submissions, on courses.</li> <li>cw_blog: Stores configuration relating to the course blogs.</li> <li>cw_faq: Stores (the eventually superfluous) configuration for course FAQ – this functionality was drastically simplified to save time.</li> <li>cw_permissions: Stores general permissions settings for the site.</li> <li>cw_context: Stores settings for the Context module.</li> <li>cw_messages: Stores the settings for automated e-mail messages, kept in a separate feature to allow overriding by client.</li> </ul> These features are not completely independent of eachother, which would be the ideal case, most of them are even cross-dependent – they require each other. They are, however, separated enough to allow them to be enabled one by one. During the development we regularly fetched new database dumps, installing our features on clean sites. This assured us that we did not have any settings not stored outside features. A few settings (such as enabling the node template custom page in Page manager) were not possible to export with Features, which made us end up with a few manual deploy instructions (most of which actually were just “enable feature X”). Our project was version controlled using <a href="http://en.wikipedia.org/wiki/Git_%28software%29">Git</a>. <h3>Some words about the project form</h3> As stated before, it is difficult to overstate the client’s active role in this project. Sebastian showed great interest in the project, could attend meetings with short notice, were open to (or rather embraced) the flexible planning of agile development, and were in general a nice chap whenever we met. We have strived to do scrum – or structured agile development – during this project. Our tools have been: <ul> <li>Sprints of two weeks (minus one day), starting with a sprint planning meeting and ending with a demonstration for the client, followed by a retrospective meeting.</li> <li>Actually, the first sprint was divided into two one-week sprints. This turned out to be a great way of getting a shorter feedback loop at the beginning of the project, which was good both for getting started with actual development, getting a first estimate of our development velocity, and getting feedback from the client. We will continue with this habit. (A special thanks to <a href="http://www.crisp.se/hans.brattberg">Hans Brattberg</a> at Crisp, who guided us in our agile approach at the first meeting.)</li> <li>Hand-written cards with user stories. To begin with these were huge, like “Administrators should be able to manage courses”, but they were broken down into feasible chunks at the relevant sprint planning meeting. Cards were size estimated as “small” (hours), “medium” (days) or “large” (weeks). At the sprint planning meeting the client would proritize the cards to get an ordered list filling the upcoming sprint, plus a few extra cards in case of unexpected development velocity. (Since every demonstration meeting inevitably lead to a number of really small tasks – such as “allow sorting on school name in table X” – we will in the future shift to a more detailed scale for size estimation. Also, the “medium” category became too wide.)</li> <li>After each sprint planning meeting we would write tasks to each user story. These were development tasks, written as post-it notes and stuck to the relevant card. Our velocity – and our <a href="http://en.wikipedia.org/wiki/Burn_down_chart">burndown chart</a> – was based on number of post-its.</li> <li>We used a physical wall for moving cards and post-its from “in queue” to “in progress” (or usually our desks), “ready for test” and finally “tested and done”. Cards that were demonstrated to the client were stored away in an envelope. (We actually tried using <a href="http://www.atlassian.com/software/jira/">JIRA</a> during one of the sprints, but the physical wall was superior in most ways.)</li> <li>We recorded a number of automated tests using <a href="http://en.wikipedia.org/wiki/Selenium_%28software%29">Selenium</a>, but they were not really a part of our workflow. We may make this a step on the scrumboard in future projects.</li> <li>Instead of e-mailing the client (or ourselves), everything was kept as discussions at our intranet-ish tool. Whenever we had problems knowing how to interpret details in user stories (rare) or encountered unexpected problems and wanted to suggest alternative functionality (more common), we developers talked directly to the client – in text or asking for a quick meeting if necessary.</li> <li>We actually ended up scrapping our <a href="http://en.wikipedia.org/wiki/Stand-up_meeting">daily scrum meeting</a> in Team Arnold, exchanging it to a time in the morning when we could tell each other things we felt the others needed to know. The two persons in the team involved in the development communicated all the time anyway, and most days no useful information was conveyed on the daily scrum. (Our team has multiple projects running in parallel – the three other members were only involved in the SSES project when special skills were needed.)</li> </ul> The most useful tools were probably the division of development into sprints – including client demonstration, having a limited number of user stories to focus on per sprint, and the communication with the client. Modules Key modules used:  Views Rules Page Manager Blank Features Content Access Node access user reference Node access node reference Views Bulk Operations (VBO) Panels Contextual Administration Feeds Content Profile Rules Bonus Pack Why these modules were chosen:  The site additions were developed collectively by <em>Team Arnold</em> (also known as “team 4”) at NodeOne, primarily by <a href="http://nodeone.se/user/9">Michael Axelsson</a> and <a href="http://nodeone.se/user/20">Johan Falk</a>. The development spanned four sprints of two weeks each, summing to approx. 450 hours. The development was made in scrum style, where the excellent communication and reaction time by the client (represented by <a href="http://www.sses.se/information/staff/central-office/sebastian-razola">Sebastian Razola</a>). It is difficult to overstate Sebastian’s role in getting this project to such a good result. Community contributions: 

N/A?

AttachmentSize Technical documentation for -SSES courseweb- - NodeOne.pdf675.53 KB SSES courseweb 2- Site architecture – node types and sections - NodeOne.pdf465.54 KB SSES courseweb 3- Course content and access - NodeOne.pdf500.54 KB SSES courseweb 4- Profile management - NodeOne.pdf489.54 KB SSES courseweb 5- Automatic e-mail notifications - NodeOne.pdf426.83 KB

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)