drupal

After having seen DrupliBacon and DrupliCake (there are other great adaptations of the Druplicon as well!), I decided I wanted to get some creative juices flowing this weekend. I present, DrupliGolf!

Drupligolf is the result of a round of golf, an addiction to Drupal, and a love for the best OSS mascot in existence. (The latter reason will definitely strike a chord with anybody who's shared a drink with the Druplicon in #drupal... and actually drank).

Here are a few articles that might be helpful to those following the Planet:

• Resetting Files Table after Drupal 4.7.x -> 6.x Upgrade
• Franciscan Monks Involved in Drupal Core Development!
• Speeding Up a Site: Quicker 404 Errors in Drupal
• Drupal: Switching Content Types the Easy Way

Help get OSC added to the Drupal Planet! :-)

Below is the full-size image mockup I made for webchick to highlight the awesomeness of Drupal's (relatively) new stark theme, as seen in Drupal 7. You can download Stark for Drupal 6 as well, but it will be a nice way to quickly expose the underpinnings of Drupal's core HTML output.

(click on the image to view a larger copy)

I'll be working on at least one CSS-only theme for Drupal 7 over the next couple of months, and will hopefully release it to drupal.org by summertime. The transition from 6->7 is going to be awesome for themers!

One requirement of the Archdiocese of St. Louis' website is that group administrators are able to publish and unpublish the content inside their groups, and they should also be able to schedule posts for automated publishing and unpublishing at a later time.

To do this, I used the following modules:

• OG User Roles
• Scheduler
• Publish Content
• [EDIT: I'm now using the Override Node Options module rather than Publish Content - it gives more fine-grained control over visibility of node form options.]

After enabling these modules, I spent a while in the Permissions page, and also created a new user role, "administer nodes." Ironically, I didn't assign the 'administer nodes' permission to this role, because doing so causes a huge mess ('administer nodes' gives waaay too much power to anyone except the site admin—it's best to leave that beast unchecked in most cases).

For the 'administer nodes' role, I checked the box next to 'schedule (un)publishing of nodes', which allows users with this role to schedule the publish/unpublish time of a given node. I also checked boxes next to 'publish <content type>' and 'unpublish <content type>' for each of the content types I wanted users to be able to publish or unpublish (these permissions are under the "publishcontent module" permissions section).

Then I went into the OG User Roles module's configuration page (at admin/og/og_user_roles), and checked the box to allow the 'administer nodes' role to be set per group, and also set that as the default role to be added to any user in a group that is made an admin of that group.

The OG User Roles module basically assigns all the permissions you assign to a given role within a user's group only. So you can give some permissions that you'd be very cautious giving out otherwise, because those permissions only affect the user's group, rather than all sections of the website. (However, there are still some permissions that can wreak havoc on your access control, like 'administer nodes'—always test!).

Now, users can schedule content to be posted whenever they'd like, and they can publish or unpublish any content inside their own group(s)!

Put this in one of your theme's stylesheets - it'll change a clunky, large, and unweildy comment form into a more compact and user-friendly form:

I have been hitting my head against a wall for a few weeks now, trying to get a few different Views-created pages to appear as if they were normal pages inside an Organic Group (meaning they would appear inside og-menu-enabled menus for that particular group, and group blocks would also appear on the pages.

After reading up on the thread "Organic Groups and Views 2", I found that I could use an argument to help solve my dilemma. Here's how I set up an argument for a particular view:

On the page display (I could've also done this as a default), I added an argument ("Organic groups: Groups") with the following properties:

• Title: <none>
• Breadcrumb: <none>
• Action to take if argument is not present: Provide default argument
  • Default argument type: Fixed entry
    • Default Argument: 6116 (this is the node ID for the organic group under which this view is posted)
  • Validator options
    • Validator: Group nodes
      • Argument type: Node ID
      • Validate current user: <unchecked>
    • Action to take if argument is not present: Hide view / Page not found (404)
• Allow multiple terms per argument: <unchecked>
• Exclude the argument: <unchecked>

Doing this allows Organic Groups to treat the Views page display as if it is actually a page within that particular group. Another problem solved! (I'm really beginning to fall in love with Views... and, apparently, Views 3 is going to be even more full of win!

Another Option - Embed in Page

You can also embed a view directly in a page, using the context of that page in your view to grab the items for the group into which the view is embedded.

To do so, create a new page/story/whatever node, with 'PHP Code' as the input format. Inside the node, put in

In the view you wish to embed (name it view_name as you used in the code above), add an argument like the following (with type Organic Groups: Groups):

• Title: <none>
• Breadcrumb: <none>
• Action to take if argument is not present: Provide default argument
  • Default argument type: PHP Code
    • PHP Argument Code:
    • <?php
if ($node = og_get_group_context()) {
$args[0] = $node->nid;
return $args[0];
}
else {
  return NULL;
}
?>
  • Validator options
    • Validator: Group nodes
      • Argument type: Node ID
      • Validate current user: <unchecked>
    • Action to take if argument is not present: Hide view / Page not found (404)
• Allow multiple terms per argument: <unchecked>
• Exclude the argument: <unchecked>

As explained on Drupal.org today, Drupal 7.0 Alpha 1 has been released, and it incorporates (among other things) a revamped user interface, custom fields (CCK) in core, image handling in core, an update manager, and a ton of 'under the hood' improvements.

This is going to be the best Drupal release to date, for two reasons:

1. Drupal has reached critical mass: WhiteHouse.gov, Intel, The Grammy Awards, and heck, even Monty Python are running on Drupal. So is your cousin's Internet startup. Drupal's seen a couple years of great press, and it still hasn't hit the ceiling in potential or mindshare!
2. Theming has gotten a whole lot easier: Disregarding the poor english in that description, it will be easier for themers (like me) to crack into designing for Drupal, which means more small businesses and individuals will use Drupal as an out-of-the-box website building solution. Expect a few people who've outgrown WordPress or Joomla to cross the pond... (link is to a placeholder page for now).

Besides these two points, the administration side of Drupal is much improved, and a lot of ridiculous bugs and weird elements from years past have finally been fixed. A few things will have to wait 'till Drupal 8, but for the next few years, I predict Drupal 7 is going to get a lot of traction, especially with the D7CX pledge. (I'm going to have to update my Drupal 6 theme, Airy Blue... ugh).

Why don't you go download Drupal 7 now, and kick the tires a little. It'll be a nice experience, minus the few critical bugs remaining. Once you're finished testing, dive into the issue queue and help change Drupal 7 from alpha to beta, and soon to release!

I'm going to be writing up a post on Building a Theme for Drupal 7 once I get a little time... it'll be on my other site, lifeisaprayer.com.

A project I'm working on required a user's signature be displayed on the user's blog posts (only on the page—not in blog teaser listings), and after much wrangling, I figured out how to put the 'Biography' (one of the user profile fields) into the nodes when they were viewed individually.

Here's the snippet (to be placed into node.tpl.php or node-blog.tpl.php):

The code basically checks if the user's account has a bio filled out, and if so, it will place it at the end of the node if the node is viewed by itself (if it's not showing the teaser).

See comments below this post for some important security considerations and alternate options.

From time to time, I've had to update my airyblue project in CVS (Airy Blue is a light, airy, Zen subtheme listed on Drupal.org's Themes section). It's always a bother, and I always end up spending about 20 minutes figuring out how to check out the module to my local computer (I use three of them, so even if I have it set up on one, I need to get it going on another sometimes), then another 20 figuring out how to commit my changes, tag a release, etc.

So, this post might be titled "How to Maintain a Theme on Drupal.org if You're Confounded by the CVS Guide for Theme Maintainers, and you are on a computer on which you haven't checked out your module yet."

Logging in, Setting up CVSROOT

1. Open up Terminal (on a Mac) and navigate (cd) to your CVS folder.
2. Enter export CVSROOT=:pserver:<username>@cvs.drupal.org:/cvs/drupal-contrib
   (This will set your CVS 'root' to the right directory. Enter your username where it says <username>).
3. Enter cvs login to login, and type in your CVS password when prompted.
4. Type in cvs checkout -l contributions/themes
5. Type in cvs checkout -d contributions/themes/<themename> contributions/themes/<themename>

After you do this, you should have the latest version of your module checked out into your local folder. Now, edit the files however you'd like, and test them locally to be sure your changes are correct. Next you have to commit your changes (don't do this yet if you've added or removed any files or folders*):

1. In the same Terminal window, type in cvs commit -m "Explanation of changes."
2. Finally, you have to tag your release before you can go to the project page on drupal.org and create a new release of your theme. Type in cvs tag DRUPAL-6--1-1 (or whatever tag you need - in my case, it was DRUPAL-6--1-5 for 6.x-1.5).

Now, go back to your project page on drupal.org, and click the 'Add new release' link under the Download section. In the release notes, you should reference all the issues you addressed in this release cycle, by typing them in as follows: [#552912] (the number should be replaced by issue's number as seen on drupal.org).

*If you added or removed any files, you will need to tell the CVS server what you did:

1. For a new directory, type in cvs add <directory>
2. And to get all the files inside that directory added, type in cvs add <directory>/*
3. To remove a file or directory, type in cvs remove <filename> or cvs remove <directory>

It would seem Google has rolled out a new indexing/display feature that finds breadcrumbs and displays them instead of URLs for certain search results. Drupal's already game, it seems, judging by numerous searches I've taken a glance at today:

I guess since Drupal's built towards this kind of data heirarchy, Google quickly and easily indexes the breadcrumbs... any other sites/CMSs already in the index in this manner?

Also, I wonder what this will do in terms of eye tracking and such - the first time I noticed it, my eye went to the URL immediately - of course, that could just be due to the novelty of the thing.