Drupal Best Practices for Small Organizations and Small Budgets

From DevSummit
Jump to navigation Jump to search

facilitated by Jack Aponte

Participants

  • Scott, David, Jack, and Thiago, experience w/ drupal
  • Jack started working with drupal at 4.7
    • Considers self a site builder.
      • Some would say web developer, but they write very little custom code.
    • Focus on core + a toolset of widely used, supported and stable modules.

Overview

  • "We're going to look at how people can make practical, long-lasting sites using tools that are often reusable and shareable without writing custom code, and getting mired in complexity."
  • Works mostly with small budgets 10-15k sometimes less than 10.

Using Drupal

  • Q. "Why would you pick Drupal over Wordpress"
    • Avoid writing custom code, doesn't want to live in code-land.
    • Wordpress has gotten more powerful (beyond post+page), Wordpress is catching up.
    • Views is a clincher, the sort of control you have makes the difference.
  • Nonprofits often get stuck with sites with tons of custom code (specially in older version of Drupal, before best-practices and modules 'floating to the top')... this creates costs over time.
  • Use exciting modules,
    • but for key pieces of functionality, page layout, navigation, taxonomy use "tried and true" modules.

How to define "Tried and True????"

  • Number of maintainers
  • Frequency of commits
  • How recently commit activity occurred
  • Who maintains it (this takes a while, but with familiarity you start to see who documents well, what tends to work etc).
  • Open issues, specifically bugs (for your version of drupal)
  • Does the maintainer tend to reply to issues?
  • Maintenance status.

Tips and Tricks

FEATURES walkthrough (http://dgo.to/features)

  • Take something like "news and announcements"
  • You can repurpose stuff for other sites!
  • Why rebuild it for every site, when very little changes between implementations.
  • Describe what components make up a feature
  • "News and Announcements" Content Type
  • Dependencies often get automatically added (views, fields, etc).
  • Then they get exported to code, as a module.. and you can commit it to git.
  • Move it between installs.
  • Or install it in a new site that has similar functionality.

Drush

  • DRUSH! it's complicated, powerful and feature rich!
  • Update all your modules, automate tasks, save thousands of clicks.
  • drush fd - features diff - what changed in my database (via the ui) from the code version of my feature (code).
  • If there are changes that aren't in code yet, it will show as "Overidden"

Case Study

  • Usecase: [usworker.coop]
  • Cost in the 15k range, but it does a lot!
    • Quirky requirements
    • Two domain names
    • One drupal install / database / codebase
    • Two themes
      • [institute.usworker.coop]
      • [usworker.coop]
    • One CiviCRM
    • "Theres a module for that" : Domain_Access
    • There were some issues with the NodeAccess ( no space _ ) module... access to different roles for different Nodes.
    • Panels
      • Works nicely with views.
      • A nice way to make layouts, there are tons of layouts premade.
      • Custom pages for say "taxonomy term pages" or a specific thing "my for members page"
      • Overview of the node_view panel page... which lets you override the main node layout.
        • You can drag and drop panes in your layouts.
        • You can show bits of content to specific users and user types.
    • You can also do things for specific nodes of specific sites.


Some cool modules

  • Basic toolkit
  • Views
  • Panels
    • Mini panes (exportable)
  • ChaosTools (ctools) - needed for Views and Panels and has a bunch of nice little helper modules
  • Features
  • Backup migrate (They just use it for backup, can be set up to backup the DB x times a day)
  • Login Toboggin (allows for email, improves the access stuff)
  • Admin menu (improves the admin experience)

Admin Modules and Themes

  • Module Filter

Themes

  • Adaptive theme

Other

  • Palante WYSIWYG is a nice feature that bundles a bunch of wysiwyg configuration.
  • WYSIWYG - CKEdit
    • And drupal 8 is going full CKEdit (3.61, 4 is still iffy on integration with D7)
  • File field sources
    • Uses IMCE (file browser for media assets, and is shared with your WYSIWYG)

We're going to add Jack's BADCamp notes here

Retrieved from "https://devsummit.aspirationtech.org/index.php?title=Drupal_Best_Practices_for_Small_Organizations_and_Small_Budgets&oldid=211"