I've been on the road a lot lately, touting the opportunities that Drupal offers to workforce and economic development efforts of regions and states. Thing is, before we can get to all the advantages for regions to develop a Drupal-talented workforce, we have to educate a lot of government leaders, commissions and committees on what Drupal is and does.  In short, they need to "get it." This means understanding not just what Drupal is used for, but why it is growing as quickly as it is.  Decision makers in many of our forums do not know what a content management system is, nor what open source means. That's a lot of ground to cover before we can even get to the whole training component!

So, in our usual DrupalEasy approach to making things more efficient, we created an under-three minute video that seems to meet our needs.  No audio as yet, but we are open to suggestions as to a voice over, or some open source diddy that might make it a bit more engaging.  Give it a look, and let us know what you think, what we can do to improve it, and how you might be able to use it.  Also, if you need to explain Drupal to anyone, feel free to pass it along.  DrupalEasy proudly presents... V1 of: What is Drupal?

I recently ran into an issue on one of our projects with a Git repository that stumped me for a few days. It was a small project: only three developers committing to a single repository hosted on Pantheon. I kept on running into an issue where I (or any of the other developers) could ever get my local repository to a “clean” state.

That is, I’d run “git status” and see 

$ git status
# On branch master
#
# Changes not staged for commit:
#   (use "git add/rm <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: image.JPG
#
# no changes added to commit (use "git add" and/or "git commit -a")

Hmmm, that’s odd, as I didn’t modify image.JPG. No worries, let me just do a “git checkout” on it...

$ git checkout image.JPG
$ git status
# On branch master
#
# Changes not staged for commit:
#   (use "git add/rm <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: image.JPG
#
# no changes added to commit (use "git add" and/or "git commit -a")

Whaaa? But I just checked it out? How can it be modified?

Well, as you may be guessing by the capitalized “.JPG” extension, the root of this problem was with case-sensitivity.

I called upon my Git mentor, David Rogers to help me figure out where the problem was and how to remedy it. David explained to me that the issue was that due to the fact that the three of us developers were on case-insensitive machines (Macs), and some of the commits were being made on a case-sensitive server. Pantheon has a feature where files SFTP’d up to the server are automatically committed, and our client-developer was making his commits this way. 

 The problem was caused because one of our developers committed the same file with two different (according to case-sensitive Linux) filenames to the repo, “image.jpg” and “image.JPG”. So, as David eloquently explained:

 So Linux sees "FOO.JPG" and "foo.jpg" as two separate files... But Mac / Win see them as the SAME file... And Git, being a Linux tool, sees them as different, because it includes the name of the file in the hashing algorithm. If the hashes don't match, there's a difference. If the name is not the exact same, the hashes won’t match.

 Brilliant - we had our cause, so what was the solution? It was actually a two-parter. 

 First, we needed to correct the repo on a case-sensitive machine so that there was only one copy of the (lowercase-named) image. We did this by using “git rm” to remove the duplicate, upper-cased file, then committed the change, then had our developers pull the commit. 

If their local repos were still “dirty”, all that needed to be done was to locally drop the offending file, then check it back out using “git checkout”. 

The key step here is fixing the upstream repository on a case-sensitive machine, without doing this, we’d never fix the core issue. Or, as David explained, we’d have a classic “who’s on first” routine on all of our case-insensitive machines:

user: git, what's our status?
git: the file named FOO has changed...
user: what's changed about FOO?
git: it looks different.
user: uh, okay... mac, delete FOO.
mac: (silently) deleted "foo"
user: okay, git, what's our status?
git: you're missing two files: "foo" and "FOO"...
user: wait, what? Okay, check out "foo" for me...
git: (silently) checked out "foo"
user: okay, great now what's our status?
git: the file named FOO has changed...
user: this again!? mac, what files are in this directory?
mac: there's a file called "foo"
user: git, what's the status of file "foo"...?
git: the file named FOO has changed...
user: MUST KILL ROBOT!!!!

So, the moral of the story - always keep your filenames lowercase to avoid issues like this, and if you do encounter an issue, fix it on a case-sensitive machine.

David Rogers is a professional software developer, speaker, trainer, and organizer of the OrlandoPHP user group. If you’d like more git-based comedy routines or at least an entertaining solution to your development problems, you can find him on the internets.

Jennifer Lampton (jenlampton) of Jeneration Web Development joins Ryan Price and Mike Anello to talk about the most-excellent new theme engine forthcoming in Drupal 8: twig. Jen tells us everything that’s wrong with theming in Drupal 7, and how twig in Drupal 8 will be like riding a pure white unicorn on candy-coated road across an aqua-blue sky so much better. WYSIWYG in core, microcopy, documentation, and some really good picks of the week are also covered in the last ever 2-digit DrupalEasy podcast!

Four Stories

1. DrupalCon Sydney Twig presentation, Pixelmord’s twig sandbox.
2. WYSIWYG in core.
3. Big Trouble in Little Content: Planning for Reusable Microcopy blog post by Jeff Eaton (eaton).
4. New Drupal Documentation leader: Lee Hunter. Dries’s announcement, Lee’s blog post.

DrupalEasy News

DrupalEasy is proud to be a sponsor of Florida DrupalCamp 2013, to be held April 20, 2013 at Florida Technical College in Orlando.

Picks of the Week

• Mike - Admin Views module by Daniel F. Kudwien (sun), Daniel Wehner (dawehner), Damian Lee (damiankloip), and Yonas Yanfa (fizk).
• Ryan - Discover L.A. - about the site.
• Jen - Honeypot module by Jeff Geerling (geerlingguy).

Sponsor

WebEnabled.com

Listener Homework

Donate to Aaron Winborn’s Special Needs Trust

Follow us on Twitter

• @drupaleasy
• @andrewmriley
• @liberatr
• @ultimike
• @webenabled
• @jenlampton

Subscribe

Subscribe to our podcast on iTunes or Miro. Listen to our podcast on Stitcher.

If you'd like to leave us a voicemail, call 321-441-3964. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or scheduling tips for Andrew. If you'd rather just send us an email, please use our contact page at http://DrupalEasy.com/contact

Doug Hercules (dhercjr on drupal.org) is a graduate of the 2012 class of the DrupalEasy Career Starter Program and currently working as an intern with DrupalEasy.

This week I was tasked with learning how to automatically close comments on a node two weeks after the node is created. We initially looked into a couple modules that did this well, Comment closer and Comment commander, but since neither is quite ready for Drupal 7, we decided this would be a good opportunity for me to learn more about the Rules module. Maintained by Wolfgang Ziegler (fago) and Klaus Purer (klausi), this module allows you to define actions that are triggered automatically on various Drupal events as they occur. This blog post will walk you through how I accomplished this task.

Drupalize.me has a great video in their “Learning the Rules Framework Series” called Introducing Rules Scheduler (currently free!) that provided the basic framework for this task. This video was invaluable in getting me up to speed with basic rules functionality.

The first thing I needed to do was download and install Rules. I enabled the Rules, Rules UI and Rules Scheduler module, which required me to also download and enable the Entity tokens and Entity API modules.

Rules Scheduler works with Rules components only, and allows us to schedule an evaluation of rules components; not executing them instantly, but later at a predetermined time. So I began by creating a rules component, which is an individual set of Rules configuration that can be implemented by a Rule, as well as other modules on your site. To get started, on the main Rules Component page (admin/config/workflow/rules/components), I clicked to “+ Add new component”. I wanted my component to actually remove the comment ability to the node (an “action”), so in the “Component plugin” box I chose “Action set” and Clicked “Continue”. In the next screen, in the “Name” box, I typed “Close comments on a node”. The Variables section at the bottom of the page then looked like this,

I entered the following; DATA TYPE: Node, LABEL: Node, MACHINE NAME: node, USAGE: Parameter, and clicked “Continue”. I wanted this component to perform on a certain node, so I chose Parameter. A parameter is a variable that is given a specific value when the Rule is performed, it receives the specific node parameters as input and then sets the variables as an output to the component.

Next, I needed to create an action that would close comments. I did this by clicking “+ Add action”, and then in the “Select the action to add” box, I chose “set a data value”. Then in the DATA section “Data selector”’ box, I selected “node:comment” because that’s what I wanted my action to impact and clicked “Continue”. To enter a VALUE, I typed “1” in the Value box (This is just a integer; 0 meaning hidden, 1 meaning it’s closed and 2 it’s open), and clicked “Save” to save my new component. On its own, the component does nothing. It is only once I create a rule that utilizes the component will anything actually happen.

The next step is to create a rule to wait 2 weeks after my node is created, and then run the component. To do this I went to - admin/config/workflow/rules and Clicked “+ Add new rule”. In the “Name” box, I typed “actions when new articles are posted” and in the ‘React on event’ box I chose “After saving new content” and Clicked “Save”. There are many options that look similar so be sure to select this one.

I then realized I wanted this to occur not only to new stuff, but whenever I modify existing stuff as well, so I Clicked “+ Add event”, and in the “React on event” box I chose “After updating existing content” and Clicked “Add”. The key is, that in either case (new or existing content), I only want the component to be scheduled if the article is published. I’ll set this up in a later step.

In the Conditions section I Clicked “+ Add condition” and in the “Select the condition to add” box, I chose “content is of type”. Then in the CONTENT section “Data selector” box, I selected “node”. In the CONTENT TYPES section you can select all of the types that you want the comments to close after 2 weeks, in the “Value” box and I Clicked “Save”. For this exercise, I just selected “article”.

To ensure the article is published before the 2 week countdown starts, in the Conditions section, again I Clicked “+ Add condition” and in the “Select the condition to add” box, I chose “content is published”. Then in the CONTENT section “Data selector” box, I selected “node” and Clicked “Save”.

Now to schedule the component to run. In the Actions section, I Clicked “+ Add action” and in the “Select the action to add” box, I chose “schedule component evaluation”. In the COMPONENT section I chose “Close comments on a node” in the “Value” box and Clicked “Continue”. In the SCHEDULED EVALUATION DATE section, I typed “+2 weeks” in the “Value” box (For a good test to make sure you’ve done everything right, you can type “+2 minutes” to make sure it works).

The identifier is what differentiates one task from the other, so in the IDENTIFIER section, I typed “ close comments for node [node:nid] “ in the “Value” box so we only have one comment closing for each mode, and lastly, in the NODE section Data selector box, I chose “node” to send the node variable of the node being saved to the rules component and Clicked “Save”. Therefore, the Rule takes this node and passes it into the component as the node parameter, these nodes and parameters gets saved, and are then loaded when the component is executed. 

Now if you did the “+2 minutes” test, you can add an article to your site, and verify the comment capability on the new node. Wait for 2 minutes, refresh your screen and see that the comment capability is gone. Once confirmed, don’t forget to go back in and edit your rule to “+2 weeks” or you won’t be getting too many comments on your site!

I’ve gone ahead and exported both the rule component and the rule for you to check out. First to import the component, go to admin/config/workflow/rules/components and paste the following rule component export into your import page.

{ "rules_close_comments_on_a_node" : {
    "LABEL" : "Close comments on a node",
    "PLUGIN" : "action set",
    "REQUIRES" : [ "rules" ],
    "USES VARIABLES" : { "node" : { "label" : "Node", "type" : "node" } },
    "ACTION SET" : [ { "data_set" : { "data" : [ "node:comment" ], 
      "value" : "1" } } ]
  }
}

Similarly for the rule, from admin/config/workflow/rules, import the following:

{ "rules_actions_when_new_articles_are_posted1" : {
    "LABEL" : "actions when new articles are posted",
    "PLUGIN" : "reaction rule",
    "REQUIRES" : [ "rules", "rules_scheduler" ],
    "ON" : [ "node_insert" ],
    "IF" : [
      { "node_is_of_type" : { "node" : [ "node" ], 
        "type" : { "value" : { "article" : "article" } } } },
      { "node_is_published" : { "node" : [ "node" ] } }
    ],
    "DO" : [
      { "schedule" : {
          "component" : "rules_close_comments_on_a_node",
          "date" : "+2 weeks",
          "identifier" : "close comments for node {node:nid}",
          "param_node" : [ "node" ]
        }
      }
    ]
  }
}

and there ya go, a new component and rule in under a minute! I hope that at least sparks your curiosity into Rules.