• look at other similar projects, how long those took, what problems you ran into on those
• hourly estimates, number of days
• write out a narrative of the expected timeline
• add a lot of padding to initial estimates
• your estimate builds your client’s expectations; don’t inflate them artificially
• if you’re really honest, some clients might come back and say no; have to accept that possibility
• if you do a high-end hourly estimate, you might come in under budget and the client might get a better deal
• keep your old proposals for similar kinds of projects; you can reuse them
• trickier with R&D work where there’s no clear answer of what it’ll take to do solve a problem before you get deep into it
• migration is a very tricky process, difficult to accurately estimate, though you can still use past experience to anticipate how long it will take
• get it in the client’s mind that estimates will have to be revisited after looking at the data
• Use formulas like if x is the amount of time you estimate, add 1/3 or 20% project management + 10% quality assurance or some other padding margin
• train clients to take responsibility for these things
• wireframe or explain exactly how you’re going to tackle a problem up front for the client
• you can give warranties on Drupal sites, though it’s not mandatory; a warranty can say “I’ll fix whatever is wrong for the three week period of this warranty”
• don’t underbid to make the sale unless you want to get burned
• your rate needs to cover your unbillable business costs
• specifically say that requesting additional estimates for additional work is paid work
• some people charge for change orders on contracts
• maintenance contracts - some people offer annual packages for basic maintenance and changes, some monthly packages, but certain requests constitute entirely new projects
• you can create those contracts with clauses that deal with if other people get involved in the projects in the interim so you aren’t expected to fix other people’s problems
• maintenance agreements = an important source of recurring revenue
• include requirements around hosting in your contracts, charge more for annoying/atypical/unfamiliar hosting situations

Presented by Eric Goldhagen

• Actions and Triggers - ways of creating automated functions (actions) when a certain condition is met (trigger)
• Without writing code to refine what the trigger was, couldn’t get specific enough
• Rules module gives more fine-grained control through the web interface (e.g. when someone creates a node of type x, send an email with this specific text to users of y role.)
• As with Views, it looks like Rules will be widely adopted because module developers are hooking into Rules or exposing their modules to Rules

Looking at Rules

• You can import and export rules, put rules into a module or features to store it as code under revision control
• “Content is going to be saved” event - when content is being added to or updated, happens in that moment in between hitting save/submit and it actually being updated
• (watched a demo of a rule being set up)
• There is more than just AND logic available for Rules; can configure OR and ELSE as well
• Performance issues are present; best way to avoid them is to put your most important condition at the very top, e.g. if a rule only applies to members of a certain role, put role membership check is happening as early as possible so the other steps don’t have to run

Presented by Joshua Jabbour

Centralized Version Control

• Requires a central server where the repository lives
• In order to interact with the repository, you must have network access and contact the central server
• Actions must be communicated to the central repository in order to be recorded and versioned; can’t commit remotely
• Once a change is committed, it cannot be safely edited; a second commit must be made to undo it
• Once you commit, everyone else can download your changes… even the bad ones
• These issues with centralized version control discourages people from using version control, committing frequently, etc

Decentralized Version Control

• No central server is required. Changes can be sent to or received from any repository at any time, or not sent or received at all.
• Most actions are local; changes only need to be shared with remote repositories as desired and when convenient
• As long as a commit hasn’t been shared with anyone else, you can edit it or undo it at will
• Others have access to your changes only after you share them; your local history is therefore separate from the remote history.
• This is more conducive to using version control heavily, making frequent commits

Git Basics

• Getting Started
  • After installation, introduce yourself to git: git config –global user.name “Your Name”; git config –global user.email “youremail@here.com”
  • Download some GUI helpers like GitX or SmartGit
  • Referring to revisions: “ebc344db0404f0ee3a634d4889c101e869a8b419″ is the full commit number but can be abbreviated to “ebc344″; HEAD is most recent commit in current branch, HEAD^ is commit before most recent one, HEAD^^^ or HEAD-3 are three commits back
• Working on your copy
  • The working copy is the files and folders in your project. It represents your project at a specific point in time.
  • But in Git, your working copy is also a full repository; this is where the magic happens, you have every single change that’s been made right there within the history of your working copy.
  • git init - create your repository in the current directory; creates the .git folder within the current directory where your repository lives.
  • git add . - add all of the files in your working copy to your git repository
  • git commit -a -m “Your message here” - Commit all files to your git repository along with an explanatory message describing the commit.
  • git clone [url] - clone the entire specified repository
• Be committed
  • With Git, it’s best to work in small bits
  • Rule of thumb: if you can’t summarize your changes in a sentence, you’ve gone too long without committing
  • Think of your local git repo as YOURS, you can clean it up before sharing, meticulously document your work in small chunks
  • git status - what’s been changed since your last commit
  • git diff
  • git commit -a - commit all updated files (already being tracked in your repository)
• Your Repository
  • Your local repo is yours and yours alone
  • You decide when and what to push to another repo
  • Commit early and commit often; you can always clean up your commit history before pushing
  • However, once a commit has been shared (especially with a central repository) it should be considered sacrosanct since someone else might have pulled down that commit already
• On Stage
  • The staging area (also referred to as the index) is a temporary holding area for changes
  • When a file or changeset is added to the staging area, it is not yet committed to the repository
  • The staging area allows you to build up your commit file by file or even line by line
  • git add file1 newfile folderA/file3 newfolder8 - fine-grained specification of what you want to add to the git repo for this commit
  • Demonstration of staging changes line by line using GitX; look into git add -p to do that from the command line
• Branching
  • Branching is one of Git’s killer features, not because it’s new but because it’s so easy and cheap
  • Branching is a database, another path that we’re working down
  • When working on features, always create a topical branch for the particular thing you’re working on
  • Always working in your trunk/master branch is not a good idea
  • git branch <branch> - creates the branch
  • git checkout <branch> - switch to that branch
  • git checkout -b <branch> - create and switch to that branch
  • Branches aren’t directories in Git; the working copy always contains the state of the active branch
  • Branches are really just pointers to a commit, as are tags
  • Branches let you separate out your work on a particular issue or feature from the master branch; you can do all of your work there, if it turns out to be worthwhile you merge it back into master, if it’s not worthwhile you can blow it away (git branch -d <branch>) and get rid of all those commits entirely
• Out on a Branch (Remote Branching)
  • Remote branches are similar to local branches, except that they can be shared across repositories
  • Remotes are referred to by [repo]/[branch]
  • Most collaborative open source software uses forked repos and shared branches
• Merging
  • Many merges can be done automagically by Git
  • git merge <branch>
  • Some merges will require human intervention with git mergetool
• Rebasing (All Your Rebase Are Belong To Us)
  • Rebasing is a primary function of Git: “redo my changes using another revision as a new base”
  • git rebase
  • In some ways it’s similar to merging, but instead of adding your changes at the end of the stream, it puts them in place in the midst of a stream
  • Rebasing is done automatically every time you pull changes from another repository
  • Interactive rebasing (git rebase -i) allows you to alter your local commits, squash them into one for merging or pushing, etc
• Fetch and pull
  • When you want to get changes from another repo you fetch - git fetch or git fetch origin or git fetch [repo]
  • After fetching you merge the new commits into your local tree - git merge [repo]/branch
  • Pulling is a shortcut; fetch followed by an automatic merge - git pull or git pull origin or git pull [repo]
  • Pushing sends commits to a remote repo; should only be done with canoncial repos (if you want to share with other users’ repos, usually you’ll have them pull from yours instead - git push or git push [repo] [branch]
• Reset (didn’t get covered)
• Gitify your Subversion
  • Git includes a built-in Subversion client
  • Use Git to control your local commits, then push them to a central SVN repo
  • A couple of things work differently, but you still have the full power of Git within your local repository
  • git svn clone [url] - check out SVN repo and put it in a new git repo on your machine
  • git svn dcommit - effectively a push to the SVN repo
  • git svn fetch - works like normal git fetch
  • git svn rebase - a fetch and then an apply (like git pull)
  • git config –global alias.spull ‘!git-svn rebase’ (handy alias to make life easier)
• Git intermediate
  • Stash away your work for now - git stash or git stash –save “short note” - not a real commit
  • git cherry-pick [revision] - bring one commit from another branch into this one
  • Hashes everywhere - everything in Git is referenced by a SHA1 hash; tags, branch names, etc are really just shortcuts to them
• Git tools and resources displayed very quickly, guessing they’ll be in slides or notes online!

Presented by Frank Carey (frankcarey)

• In the beginning, Drupal was very code centric
• if you wanted to make something you coded a module, relied in hooks API, etc
• Content ruled the land (the database), but modules still stored many settings in the database
• Content in Drupal - nodes, friends, comments, votes, users, messages
• Then came the GUI-la Monsters - Flexinode, Views, CCK, Contemplate, Rules, Context - things you’d normally do with code, but now could do through the UI
• Config settings include variables, CCK, permissions, views, contexts, panels, blocks, and rules
• Why should this stuff be in code and not the DB?
  • How do you track changes within the database?
  • How do you revert back when you make a mistake?
  • How do you reuse configurations?
  • How can you work as a team?
  • How can you update settings across sites?
• If your settings/config are in code, you can use version control to handle those thing
  • take your pick, but pick something! CVS (going out of use though), Subversion, Git, Bazzar, Mercurial
• How do we get stuff into code?
  • Some modules provide their own custom export and import functionality - views migrate rules
  • some are leveraging ctools export api (paenls, context, etc)
  • some are adding exportables to other modules or tables (Input Formats and Strongarm)

Ctools exportables

• Tool attempts to solve the common problem of handling exportables.
  • Defining exportables structure
  • Getting the data from the DB and creating the xportable object
  • importing the data from either db or code
• Ctools exportables
  • Need a persistent, unique identifier in the table that contains the object you want to export (the machine name)
  • Implement a few lines into hook_schema() or hook_schema_alter() to get ctools functionality
• So what the heck is Features?
  • Features is basically an exportables manager
  • It creates “features” modules, which are really just normal modules (features is not a hard dependency
  • allows for a gui interface to choose what things you want to export per feature
  • it provides drush integration to easily update and revert changes from the CLI
• What should a feature consist of?
  • Look for logical sections and atomic functionality
  • Examples: Blog, Gallery, Users, Content Type X - these are features on the site that are comprised of content types, views, blocks, etc that come together to create one complete feature on your site
  • Can be traditional code as well: stuff that used to go in helper modules, additional theming, etc. All of Drupal’s hooks are available to Features.

• In the beginning, Drupal was very code centric
• if you wanted to make something you coded a module, relied in hooks API, etc
• Content ruled the land (the database), but modules still stored many settings in the database
• Content in Drupal - nodes, friends, comments, votes, users, messages
• Then came the GUI-la Monsters - Flexinode, Views, CCK, Contemplate, Rules, Context - things you’d normally do with code, but now could do through the UI
• Config settings include variables, CCK, permissions, views, contexts, panels, blocks, and rules
• Why should this stuff be in code and not the DB?
  • How do you track changes within the database?
  • How do you revert back when you make a mistake?
  • How do you reuse configurations?
  • How can you work as a team?
  • How can you update settings across sites?
• If your settings/config are in code, you can use version control to handle those thing
  • take your pick, but pick something! CVS (going out of use though), Subversion, Git, Bazzar, Mercurial
• How do we get stuff into code?
  • Some modules provide their own custom export and import functionality - views migrate rules
  • some are leveraging ctools export api (paenls, context, etc)
  • some are adding exportables to other modules or tables (Input Formats and Strongarm)

Ctools exportables

• Tool attempts to solve the common problem of handling exportables.
  • Defining exportables structure
  • Getting the data from the DB and creating the xportable object
  • importing the data from either db or code
• Ctools exportables
  • Need a persistent, unique identifier in the table that contains the object you want to export (the machine name)
  • Implement a few lines into hook_schema() or hook_schema_alter() to get ctools functionality
• So what the heck is Features?
  • Features is basically an exportables manager
  • It creates “features” modules, which are really just normal modules (features is not a hard dependency
  • allows for a gui interface to choose what things you want to export per feature
  • it provides drush integration to easily update and revert changes from the CLI
• What should a feature consist of?
  • Look for logical sections and atomic functionality
  • Examples: Blog, Gallery, Users, Content Type X - these are features on the site that are comprised of content types, views, blocks, etc that come together to create one complete feature on your site
  • Can be traditional code as well: stuff that used to go in helper modules, additional theming, etc. All of Drupal’s hooks are available to Features.

Notes from Features Demo

• When you look at your list of features with diff module enabled, you can see how a feature has been overridden within the current configuration
• Turning on Strongarm allows you to export variables (from the variables table) into a feature

Command-line features

• Features exposes many commands to Drush that can then be used from the command line
• features revert - revert a feature from the command line; this reverts changes made within the UI to settings that you’ve configured within a feature

Features/Exportable Gotchas

• Some exportables can’t be exported more than once (e.g. can’t re-export a default view)
• Features-revert-all can be dangerous, blow away work
• Not everything is exportable yet
• Revert-all doesn’t work if there’s no diff (fixed recently in dev)
• Dependencies can be tricky.

Developments to watch out for

• Better core exportability in Drupal 8
• Use of UUIDs as unique IDs
• More end-product modules that implement a fully featured user experience
• hook_features_alter() - allow partial overrides that are exportable as well
• Easy Features = Better Install Profiles

Additional Things to See

• http://drupal.org/project/features
• All features enabled modules

Random/Framing Notes

• Introduction to HTML 5 book is a primary reference during this conversation
• Is it a good ideal to add a bunch more options, fields, and decisions for what to HTML5ize or not throughout Drupal? This might create some big UI/UX problems.
• Might be better to have all Semantic HTML5 settings on one big page, rather than have the configuration distributed throughout Drupal
• Doing all the config in one place will also give us a really easy way to set all the defaults more manageable.
• However, having all the config in one place AWAY from the creation/edit pages for these entities could be cumbersome
• Can we have the same settings in two places? The Semantic HTML5 module settings page AND the individual settings pages for menus, blocks, etc?
• We’re going to start out in Drupal 6, it’ll be difficult and messy, but we’ll learn as we go and then know how to tackle this in Drupal 7
• If we build an API for this and collaborate with creators of Semantic Views, Semantic CCK, Mothership, etc, might be a great way to go for Drupal 7
• Might never be an API because in Drupal 7 this is going to be done by drupal_render
• We’ll need to include JavaScript to include semantic tags on non-HTML5 compliant browsers
• Our goal is to make Drupal work for HTML5, not to make HTML5 work in all web browsers

Forms and Fields

• Form API gives us a big advantage and many abilities to make changes to any form field
• right now we can primarily work with core and CCK fields
• we can provide support moving forward, but we can’t completely anticipate what other fields will be used for; we can’t inspect backwards
• we can also work with modules like Date, Email
• use the Elements allows module developers to use Form API to get HTML5 form elements into their modules; a separate module would be used to transform core and CCK fields to HTML5 elements
• want to be able to switch fields from “text” field to “email” field; Elements module lets you do some of that already
• we’d need a different module that does what Elements does to core fields
• other things to support with the other module - search (core)
• these modules will override the markup for CCK widgets
• we need to figure out how to override markup for all the fields with HTML5 elements; then we need to figure out how to implement that within the module, allow people to specify which fields they want to override, etc.
• Could also consider getting this stuff into modules (CCK, Date, etc) themselves anyhow to avoid having to develop an entirely separate module

$header and DOCTYPE

• DOCTYPE has to be changed but that’s relatively easy
• Header elements are also done differently in HTML5
• In Drupal, $header is spit out by Drupal
• In Drupal 6, $header is populated by both core and by the drupal_set_html_head function - anything can be put into the $header using that function
• We can tackle this on the module level, but would then need to ensure that the module gets executed last (and other modules are already jockeying for that position)
• In Drupal 7 what you’re adding to headers is much more structure
• Other option - handle it at the theme level using a preprocess function - wind up with an amorphous blob of text that we could regex to replace tags with HTML5, but it’s not foolproof
• A module seems like a headache; a starting point in a base theme might be a better way to go
• If an edge case uses the old HTML ways, the page/site will still work
• If this is done with a module, anyone can do their own HTML5 theme, $header is still printed normally, instead what you get out of $header is now HTML5 instead of the old way to do it
• drupal_add_http_header and drupal_add_html_head are used in Drupal 7, so getting stuff into $header will be much more structured
• We could backport that from Drupal 7, but contrib modules might not work with that backport
• We could implement the backport and append on whatever else was set in the header that isn’t handled by the backport at the end, though that could result in double info
• Are there concerns about the order of tags in the header? Probably tags that have to come after everything else will be appended on the theme layer anyway, and if not it would work if we appended things at the end of the D7-backported $header
• Agreement is coming in this discussion that this should be done in the module level; create a wrapper function that overrides drupal_set_html_head and is a backport of what’s in Drupal 7; modules can use our function if they provide needed information that they want in the header; and if any modules are not using our function to set header tags those are just appended at the end of the $header
• possible module names: HTML5 API, HTML5 tools
• might have implications for limitations on script and styles tags (e.g. IE limitation of number of CSS files)
• The syntax has only been simplified in HTML5, but how do we get in there and alter those variables?

Document Layout Tags

• The new HTML5 document layout tags include article, header, footer, nav
• Much of this is a theming layer issue
• A group needs to get together, figure out best practices, and rewrite node.tpl.php and page.tpl.php for a base D6 theme
• However, some tags come out of core, CCK, and Views
• Some of the HTML that core spits out has theme functions, some doesn’t (e.g. comments)
• We can create a theme function that rewrites and fixes core HTML that doesn’t already have a theme function
• Mothership theme might be a good place to look for existing fixes or a list of possible problems to look at
• Views and CCK - do we fix Views and CCK, or do we tell people to use Semantic Views and Semantic CCK instead?
• Can we wrap our solutions up as Features, perhaps including Semantic Views and Semantic CCK
• One possibility - require Semantic Views and Semantic CCK modules as part of this feature, add a lot of HTML5 documentation to the top of the Semantic CCK form (and Semantic Views too?). We should also prepopulate as many predictable HTML5 settings in Semantic CCK and Views as possible, just like what happens in Semantic Views and Semantic CCK already; in both we’ll be using HTML5 markup.

Menus and other Drupal entities

• there’s a nav tag in HTML5
• Not every menu is a nav, but there are some we know are navs, e.g. primary links and secondary links
• Stuff that only shows up for administrators are second-tier issues for us
• there is some debate about what menus might qualify as navs and what might not
• consider creating a Semantic Menus module
• Though we’re not sure of the way we’ll do it, we do have a goal of altering the menu creation form so that a user can choose to make a menu HTML5 or not
• Other Drupal entities that we need to tackle similarly: blocks, comments
• Config page for the module(s) we create could turn HTML5ing on for particular entities; turning HTML5 on for those entities will turn on

Presented by Robert Holmes (robbiethegeek)

(Got here a bit late, but caught the very beginning of drush command overview)

Handy drush commands

• drush - listing of all the drush commands available to you
• drush status - basic info on your site
• drush sqlc (drush sql-cli) - takes you into MySQL console using the credentials of the site you’re accessing with drush right now
• drush dl <projectname> - downloads code for module (project) into sites/all/<projectname>; can list multiple projects at once
• drush dl <projectname>-<version> - download a specific version of a module, e.g. drush dl filefield-6.x-3.x-dev
• drush en <projectname> - enable <projectname>
• drush up - upgrade code and database for Drupal core and third-party modules
• drush sql-dump - Performs a dump of the current Drupal site’s database. This will vomit it all over the screen, so instead you’ll want to direct the SQL dump to a file using drush sql-dump –result-file=filename.sql or drush sql-dump > filename.sql (and then
• drush cc - clear the cache that you then specify from the menu, or specify within the command as drush cc theme or drush cc all etc
• drush help <command> - get help on the given drush command

Random Notes

• You can use drush in conjunction with other shell commands, wrap drush commands in shell scripts, etc
• Other modules can also expose functionality and add commands to drush, e.g. devel module
• Drush supports the ability to remotely connect to a server - open an ssh connection, run a drush command, and bring it locally
• http://dgo.to/ - Drupal URL shortener AND smartener with quick paths to projects, issue queues, nodes by number, users, etc

Presented by Alex Urevick-Ackelsberg, Zivtech (12-person Drupal shop based in Philly)

Starting Out

• look to other existing shops to get insights into the business of selling Drupal
• Define the type of Drupal/web shop you are. Are you just a Drupal firm? Do you provide other services/products? What are you selling?
• Good to write up a mission statement, followed by a business plan - take the time to look at the market, the other players in the market, assess the cost and payout of the business
• Small Business Association - many resources that you can tap into when starting out, even just as a freelancer
• Cash flow is a tricky thing to handle; need to know how much money you need to get started. Do you need investors? Loans? Are you going to bootstrap it?
• Money comes in through accounts receivable; goes out through payroll, accounts payable, and taxes. Need to have it coming in faster than it’s going out.

Partners

• Who are you looking to partner with? Why? Do you want to stop doing certain parts of the work? Does your shop need skills that you don’t have?
• Define roles for each partner
• Split tasks and responsibilities up
• Keep partners accountable
• Seth - the perfect partner is someone who you don’t agree with all the time, to be challenged

Management

• Remote vs office
  • Being in the same room can help facilitate quick communication
• Managing teams of developers
  • can be like herding cats
  • if your shop sells hours
  • who ends up being a project manager? is that a separate role or can other people take on that role in addition to development?
  • Sometimes developers don’t have good project management skills; sometimes it’s based on scale and you just get to a size where it won’t work
• Fixed bids vs retainers/hourly
  • “If you want a good way to bankrupt your company, do a fixed bid.”
  • Zivtech either sells buckets of time (e.g. 100 hours to be used within a certain amount of time) or estimated costs (here’s the top of what we think it’s gonna cost, if it gets to where we think it’s going to be 10% over that we come back and check in)
  • push back from others in the audience (Liza, Seth) about fixed bids working if projects are managed well, clients not being willing to go for non-fixed bids
  • Zivtech bills based on who’s working on the project; different levels of skill
  • Liza - can be important to have a client manager (not necessarily the same as the project manager)
  • someone else in the room - gives clients deadlines for giving feedback
  • Zivtech uses unfuddle for ticketing, time tracking, etc - has git and svn repositories
  • suggestion: multiply the number of hours you think a task will take by three and you’re more likely to be on target!
• Juggling more and longer term engagements
  • Tricky to figure out how to juggle how many projects you’re taking on at once
  • A key thing is to overbook yourself
• Balancing contribution and business development with client work
  • balance the non-billable hours well
  • make sure you’re charging enough to withstand the time that folks are doing non-billable work
  • Drupal is something of a publish or perish business; you’ve got to put yourself out there, contribute to the community
• Outsourcing
  • a more flexible way to pay people for work than payroll; accounts payable is “pay when you can” whereas payroll happens every two weeks no matter what

Sales and Marketing

• Sales cycles
  • understand how long clients will take to make decisions, sign contracts, send initial deposit and later payments
  • understand how clients’ fiscal years work and how that will affect the work you’re getting
• RFP, estimates, and proposals - understand how your internal cycle works
• MeetUps, Camps, Local community sites and conferences - good sources for new clients
• Contribute!!! in open source! Publish or Perish!
• Develop or claim modules in desired verticals (e.g. mapping, media, mobile, etc) - focus your contributions in the area you’re trying to work with

Basic Roadblocks to Growth

• Cash flow is king!
  • you can demand a certain amount up front from many clients, though some clients will tell you how they’re going to pay; they generally ask for 40-50% up front
• Taxes
• Accounts Receivable/Collections
  • gently but consistently remind clients to pay you
  • make sure you get into your clients payment system ASAP - contact billing right away
  • do regular billing, biweekly or monthly
  • try to avoid being a hard-ass to collect; you’re building relationships, so you want to communicate the need to pay as gently as possible
• Talent
  • can be a huge impediment to Drupal shops
  • you need to aggressively train smart people, not just expect to find all the highly-developed talent you need

Get Help!

• SCORE (Service Corp of Retired Executives), SBA, Business Schools
  • some business schools have programs where they place interns with you for a period of time to assist you in the startup stage
• Collaborate with other shops
• Consultants email list

Questions

• is client acquisition a “hard marketing” expense? As in, something that can be written off?

Presented by Roger López (zroger)

Admin Themes

• clients/users appreciate a clear visual division between the public front-end view of the site and the admin view
• Garland: out-of-the-box theme that can be used to easily create that visual separation; it’s the easy choice, but there are others that are specifically tailored to be admin themes
• Root Candy: specifically focused on being used on the administrative side; creates tabs at the tops for “root-level” admin items, emphasis on readibility, good table structures
• comes with built-in slide-out control panel that you can drop any block on the site into
• Rubik: another admin theme designed for clear, clean admin with a keen eye to styling messaging, help text

Tools, Toolbars

• Admin module; little wrench in the corner that expands out into an administration
• admin_menu module: gives you a nice dropdown menu across the top of your site (front-end and back-end), a number of functions under the Druplicon dropdown menu

Administrator != Developer

• A menu of quick-links specially created for client administrator can be very helpful
• Modules to build an admin interface:
• Views bulk operations - lets you build a view of content (eg nodes, files, comments) and provide checkbox-style operations on all of the nodes
• Draggable Views - lets users drag and drop lists of content into a completely arbitrary sort
• Nodequeue - one step beyond Draggable Views, does the drag and drop sorting but also controls specific pinpointing of what content is included in what queue, e.g. take ten completely unrelated nodes and put them into one queue
• Panels - you can use it to create a dashboard view of content for your administrators, e.g. a dashboard just for users who are comment moderators

Developer tools & APIs

• Ctools - suite of modules that exist to support other modules
  • includes AJAX library - ideas behind it are foundation for AJAX libraries in Drupal 7
  • Wizard - multi-step forms
  • Non-volatile Object Caching
• Dialog API - merges jQuery UI Dialog widget with Ctools AJAX - do simple form submissions through a dialog
• Features - bundle up all the views for admin interfaces, just like with the front-end stuff

WYSIWYG

• they’ve gotten better at outputting valid (if not entirely efficient) output
• WYSIWYG API is the way to go now; editor specific modules are deprecated
• input_formats - new module that allows you to export input formats as Features code (!!!)
• better_formats - module that attempts to improve the input format specifications of Drupal, default input formats per role (!!!)
• Insert - works in conjunction with imagefields and filefields - get an insert button next to each imagefield, throws it into the body of the node, works with all major Imagefields (!!!)

Random

• Check out http://www.sequelpro.com/ - MySQL management for Mac OS X

Presented by Theresa Summa (theresaanna) and Seth Cohn (sethcohn)

• Looked at a non-Drupal site, cnn.com - cramming as much information on one page as possible - they throw as much on the page as possible to appeal to as many different people as possible
• observer.com - a Drupal site that does something very similar
• How do you standardize the display of each piece of content on your site (e.g. pictures in proper sizes, providing all essential data, formatting it)
• economist.com and globalpost.com - more content-rich sites built in Drupal

Imagefield

• let users upload images in a CCK node
• lets users upload multiple images, sort the list to select which is going to be featured on the front page, the others get inserted into the content appropriately and in a consistent way by Drupal
• bulk uploader available

Imagecache

• resizes/crops images on the fly according to your preset dimensions
• helps standardize image sizes across the site
• Imagecache is included in Drupal 7 core, hurrah!
• Imagecache presets stop large images from breaking your layout

Quicktabs

• allows you to combine multiple items into one Quicktabs block with tabs on the top
• Nice jQuery action to allow users to switch from one section to the next, loaded all at once, or via Ajax on the fly
• Plays nicely with Views, individual Nodes, and multiple Blocks

Views Slideshow

• the recommended solution (”best of the breed” according to Seth) for rotating carousel type things

Panels

• Provides a drag and drop interface for units of content on the site to be added, deleted, and arranged in a layout on the fly
• “is all sorts of insane magic”
• pros for Panels - great Views integration, user friendly for non-techie users
• Negative - spans between modules and theme layer, so it’s slower, performance hit on your site, takes a lot of liberties
• If you’re a themer, you might be able to do without panels

Composite Layout

• could be called Panels Light
• gives you the Panels approach but does it on a node by node basis - you can choose predesigned layouts on a node by node basis, e.g. a different layout for each individual blog entry, on the fly.
• Display Suite is another alternative

Vertical Tabs

• for the content adding and editing side of the site - much easier
• divide your node add/edit forms into sections with vertical tabs on the side, collapsed along with a summary of the collapsed settings.
• Makes large content types easier for content producers to maintain
• Drupal 7 includes this in core, Drupal 6 module mostly works well

Arrange Fields

• http://drupal.org/project/arrange_fields
• First commit was 5 weeks ago as of 7/24/10 so is early on, but lots of potential
• “This module lets you drag-and-drop the fields of any CCK content type, Webform, or almost any other form in Drupal into the positions you would like for editing. This makes it super simple to have forms with inline fields, which you can change at any point. Tab indexing is also updated, so no matter how you arrange the fields, the users can still tab through them easily. And, you can now add arbitrary bits of HTML markup– labels, images, HR’s, etc.”

CCK Fieldgroup Tabs

• separate CCK fields onto a completely separate tab to break down long node creation forms

Random Notes

• check out Nodequeue again for arbitrary lists of nodes, drag and drop
• you can feed Nodequeues through views
• Imagefield Insert module
• get good at Views theming - so much can be done!
• My question: what’s the best practices approach to fine-grain tuning of everything via node-whatever.tpl.php files vs doing as much as possible within the CSS. Answer: there are a lot of different philosophies; have to consider how custom and how specific this content type needs to be displayed. If it can be done through CSS fairly easily, go for it; there’s a performance hit to loading bunches of node-whatever.tpl.php vs using already loaded & cached CSS. Theresa says her philosophy is to keep the number of files down as much as possible.
• Omega theme (Theresa: “If Zen and 960gs had a baby, it would be Omega”

Civi Updates & Announcements:

• first public alpha this Friday, code is pretty stable
• good changes in UI, features, functions
• CiviCRM book is “officially” coming out after book sprint in April, though it’s already up on en.flossmanuals.net - it’s bigger than Harry Potter! Includes broken out sections with step-by-step guides for everyday tasks
• Check out http://civicrm.org/groups/nyc for more info on the meetup group
• DrupalCampNYC 8 - coming up in July, already 2/3 sold out after one day! http://groups.drupal.org/nyc

Case Study: Phillip Bien - NYS Coalition of Social Workers

• NYS Coalition of Social Workers - formed by a handful of social workers to work directly at teh legislative level
• needed a new website to support advocacy costs, needed raise cash to do effective work to change the laws
• needed powerful professional website, membership benefits & incentives to join - all on a shoestring budget
• CiviCRM 3.1.3, Drupal 6, Dreamhost Private Server (LAMP) with PayPal
• wanted to build a longterm solution
• needed lower fees than a managed SaaS
• open source, strong track record
• Drupal ACL based on membership, abundant Drupal modules, CiviCRM better & better
• current site features: public site, memberships join and create site login, permissioned content types, downloads & docs archive, register for events, self-service contact info updating
• using entirely out of the box solutions for membership, events, etc
• Drupal modules in use: CiviCRM, CiviMember Roles Sync, CCk, content permissions, filefield, text, color, help, taxonomy, pathauto, string overrides, google analytics, views, views UI
• You could do this all without Terminal/CLI, cash, php, html, css, but you should get some help if you can!
• Future: want classified ads, membership cards, CiviMail, member and nonmember pricing for events and purchases, find someone else to work on the site, expire memberships on the first of the month instead of 365 days after join date
• Accomplishments: their legislation is on the Gov’s desk for signature, got lots of new paid members, love the new site for aesthetics, ease of use for site visitors, org members, and administrators
• “NYC CiviCRM meetup provided critical direction to pull this off”

CiviCase Overview and Demo

• track interactions between your organization and constituents
• related to activities built into CiviCRM constituents
• CiviCase ties activities together to create work flows for activities related to constituents
• can create rigorous workflows with requirements for what needs to be done by whom in order to close a case
• good example of a feature developed for a particular group’s needs and contributed back to the larger Civi community
• Right now there is no UI; need to configure an XML file to set up CiviCase, though there’s good documentation online
• You can write import/export interfaces to import anything into CiviCRM, so case information can probably be imported (e.g. from Act) though entire cases can’t be exported from Civi
• Rayogram created email inbox processing script to parse and create new cases in CiviCase via email
• Cases are made up of individual activities in relation to a CiviCRM contact
• When you open a case for a contact, you can describe the details of the case, assign a subject, select a case type, set a status, and create a start date and duration
• opening and closing a case is an activity; you then create new activities within the case
• Jack’s thoughts about specific use cases for clients: CiviCase for grant application processes? safe space cultivation? pen pals?

CiviRelate

• created by FatherShawn
• Drupal module that allows logged-in users to create relationships to a new Civi contacts when they enter that new contact’s information through a profile
• First using CiviRegister, another Drupal module which allows someone to fill out a Civi profile and create a Drupal login at the same time
• Does a dupe check and merge for the contact being entered
• Shawn used Coder to check his code
• module is currently in the Drupal.org CVS queue, but in the meantime you can find it on the CiviCRM wiki

Random Notes

• Check out Boost module for sending an entire Drupal site to static pages that are presented to anonymous users