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