Small Drupal and talking web development principles and sustainability

From DevSummit
Revision as of 23:37, 4 May 2015 by Vivian (talk | contribs) (1 revision imported)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Small Drupal

  • some folks have worked with Drupal, some have not
  • Nonprofits that have annual budgets of $500,000 or less (small budgets for websites)
  • Limited resources is not just money, it is also about time
    • people who work at small non-profits are already stretched really thin (orbs that do not have a dedicated staff member to managing the web project)
  • Develop goals and best practices for Drupal on a small scale
  • Drupal gets a bad wrap, sometimes even small orbs need some of the tools that make Drupal more powerful than Wordpress
  • Views module is the most common reason for people to chose to go with


  • allows you to form very complex content queries with a GUI interface
  • Create relatively complex SQL statements
  • Can use views to create resource libraries
  • Content Types allow you to create very intuitive forms for end-users
  • to fill out to create their content
  • How to use Drupal without hitting pitfalls (too difficult for organization to use, etc.)
  • Small Drupal projects, small budgets, with tight timelines for small organizations
  • What are the best practices to support these principles:
    • Work within the time and expertise restraints that non-profits have (don't impose a development process that is not within the engagement capacity or expertise of the client)
    • Not building a bunch of things that will cost a lot of money and time that the organization will end up not even using (example: regularly updated blog or other timely content, comment moderation, etc)
    • Create a site that can be hosted and maintained relatively easily by the client, as lightweight as possible
    • Create a site that isn't a nightmare to upgrade in the future
    • Use tried and true modules that have a lot of community support and are actively maintained
  • How do we reach these principles?
  • Do not write custom code (modules, php hooks, etc) because lots of organizations cannot afford to maintain that code as it rots, creates security holes, etc.
  • Use version control to recover from mistakes or going down the wrong path.
  • Using things like the features module to export configurations to code