January 17, 2012
The university department is at the center of academic life. All across higher education, tens of thousands of departments have organized themselves to teach courses and perform research. As it turns out, most departments need a website to promote their work and each of those websites is basically the same.
June 21, 2011
Oxfam is an international confederation of 15 organizations working together in 98 countries to find lasting solutions to poverty and injustice. Since they need to communicate quickly and richly with their staff, partners, and allies across the world, they turned to Drupal as a framework to help build and power many of their public and private websites.
April 03, 2011
The university department is at the center of academic life. All across higher education, tens of thousands of departments have organized themselves to teach courses and perform research. As it turns out, most departments need a website to promote their work and each of those websites is basically the same. Open Academy is an academic departmental website in a box.
February 28, 2011
February 25, 2011
Matt Cheney delivered a presentation showcasing the power of the CCK module at Drupal Camp Austin.
September 29, 2009
As we talked about in the last post about Drupal Development Tools, the process of making Drupal websites is a lot like cooking and requires great tools, techniques, and secret sauce to make it all happen. Here are some of the techniques we use on our projects: The Techniques Due Diligence and Drupal Development Plans Just as breakfast is the most important meal of the day, writing an initial Drupal development plan is the most important part of any project. It might seem like paperwork or busywork, especially to seasoned developers where Agile is Cowboy spelled backwards, but it has been my experience that every extra hour you spend planning saves you several hours at the end of the project - plus all the headaches. This process is pretty straight forward for small sites - identify the major content types, views, and contributed modules you need - and then start building. It usually takes a couple of hours thinking it through and often helps to talk it through with another developer. For larger sites, the process of building a Drupal development plan should be a more involved one where you consult with all of the developers, themers, and designers involved in the process. For sure a lot of the Drupal implementation is obvious (this is a node!) , but it is the hard stuff (especially the custom code and how that all fits together) that will throw you for a loop. At Chapter Three we believe that the best development process is an iterative one and items will be changed, modified, and blended throughout the process, however, its much easier to change something if you know the structure of what you are changing in the first place. There are many ways to put together a project plan, but here is a basic Drupal development template we have used to give you some ideas. Sandbox Environments As I mentioned previously, we use SVN version control for all our projects and to take full advantage of this we give every developer their own sandbox copy of the code located at projectname.chapterthree.com/ ~username. This allows the developer to work in isolation and only commit up changes when they are ready to have them reviewed. We have an automatic SVN post-commit hook that fires on each commit to update our general development instance (project.chapterthree.com) with the latest and greatest code. There are occasionally SVN conflicts that need to be resolved, but its much safer than trying to work off the same general copy of the code - in fact, our SVN post-commit hook explicitly forbids commits from any non-sandboxed copy of the code.
September 07, 2009
In a past life, I used to teach cooking classes and as a class exercise at the end of the first class I would ask my students to cook a particular dish, using a collective set of ingredients, and bring it to the next class. Each student approached the problem differently, using their own techniques and tools, and they all mixed in their own "secret sauce" to improve on the collective ingredients. It was interesting that despite starting with the same ingredients, the students ended up in wildly different places and with different quality. The difference came from the little things - the tools, the techniques, and each chef's secret sauce. Drupal development, in a lot of ways, is like cooking. For the most part, it starts with the same basic ingredients (Drupal core + contributed modules) and often follows common recipes (make content types, create views, write custom modules), but where you end up as a final product matters a lot on the tools, techniques, and secret sauce you work with. At Chapter Three we have been doing Drupal development as a team for over three years and have chosen our tools, refined our techniques, and perfected our secret sauce in making great Drupal websites. Over the next three blog posts, we will talk how we do the work we do. The Tools SVN for Version Control The ability to selectively save and revert your work is something I often wish for when cooking and find extremely useful when coding. At Chapter Three we use SVN version control for all of our projects, big and small. This allows us to effectively manage projects with multiple developers and allows us to integrate external developers into our client process. While we recognize there are other version control systems out there with more features (Bazaar, Git), we choose SVN because of its relative simplicity and familiarity to our developers, themers, and clients. Trac for Code History and Bug Tracking To complement SVN with each site we roll out we also include a separate installation of Trac. This open source package allows us to see a timeline of our SVN commits and get visual diffs between revisions. This is helpful in auditing specific pieces of code (what happened and when) and provides a lot of assisstance in tracking down problems that might arise (if the module was broken on Friday, what changes were made to it on Wednesday and Thursday?) To manage our credentials between Trac instances we use our project management Drupal instance to control the HTTP authentication for Trac. Drush I whole heartedly agree with @ronald_istos that "drupal without drush is like life without mobile phones .. you know you managed just fine but now you just can't imagine how". Although our average site containing roughly 30 modules, installing and updating all of the modules is made really easy with Drush. With each site rollout we also deploy a symlinked wrapper around Drush that identifies the project that needs updating, switches context to the developers sandbox, and pushes up any changes to SVN. This makes updating modules on a Drupal site as easy as drush updatecode. To quickly turn on and off modules the commands drush enable module and drush disable module does wonders to increase productivity. Beyond the module management, Drush is a venerable swiss army knife of Drupal functionality allowing a developer to log directly into the MySQL database with the credentials the Drupal installation uses (drush sql cli), runs cron (drush cron), run any pending database updates (drush updatedb) and much much more. It is really easy to extend Drush's functionality and we have found this very helpful when doing extensive data imports and exports. All in all, the centeralization of all of this functionality to the command line (now not even a module!) is very powerful and indespensible to our development process.
August 07, 2009
It is a good Drupal development best practice to embed each of your views in code instead of storing them in the database. This technique will allow your views code to be managed by your version control system which makes pushing up changes to views from development to staging to live a much cleaner process. Additionally, since the views code is being loaded from disk instead of the the more expensive database you will see a modest performance improvement. All in all a pretty good thing.
July 10, 2009
As a matter of best practices with privileged user account passwords, it is important to avoid using the same password for multiple sites. The reasons for this should be pretty clear, but when you are working in a collaborative environment with multiple different sites this is easier said than done. It is really hard to remember many different complex passwords and to share them (for User 1) across your development team. An encrypted "password safe" file can be one solution, but the problems to this kind of approach should be obvious.
June 08, 2009
It should come as no surprise that San Francisco is a great place to talk about technology. The area has fostered a ridiculous amount of innovation and there are always plenty of people interested in getting together to talk about the next cool thing.