Blogs

From MacRumors:

Google is phasing out the use of Windows company-wide due to security concerns. The move comes after news in January that Google was hacked in an attack originating in China. Those attacks used a security vulnerability in Internet Explorer for Windows. News of the report comes from FT.com who cites several Google employees.

"We're not doing any more Windows. It is a security effort," said one Google employee.

The majority of those moving away from Windows PCs are moving to Mac OS according to another Google employee. New hires are given the option to run Mac OS or a Linux-based machine.

Google employs over 10,000 individuals worldwide.

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!

Recently, I was troubleshooting performance issues on a few different websites, and was stymied by the fact that YSlow repeatedly reported an F for "Compress components with gzip," even though online sites like GIDNetwork's Gzip test were reporting successful Gzipping of text components on the site.

Yslow results - not very happy.

After scratching my head for a while, I finally figured out the problem, hinted at by a comment on a question on Stack Overflow. Our work's proxy server was blocking the 'Accept-Encoding' http header that is sent along with every file request; this prevented a gzipped transfer of any file, thus Yslow gave an F.

I set up a secure tunnel (using SSH) from my computer to the web server directly, and then reloaded the page in FireFox, and re-ran YSlow:

Much happier now. I've contacted our IT department to see if it's possible to allow the proxy server to pass through the Accept-Encoding headers, but for now, I'll know to watch out for false positives on the YSlow test, and check from multiple locations.

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>

Many of the sites I design don't require a user login form on every page, especially if there are only a few people that will ever need to login. Instead, I like to simply provide a "User Login" link somewhere on the page (most often in the footer), so it's unobtrusive but there for those who might not remember to type in /user after the URL.

This presents a new problem, though: if you put a link to "example.com/user," then the person who clicks the link will be taken away from the page he was viewing to login, then he'll be directed to his user account page.

Luckily, Drupal lets you set a login destination in the URL, so you can redirect the user back to the page he was viewing after he logged in.

To do so, create a block with PHP as the input format (or insert this snippet somewhere in your .tpl.php template files), and use the code below:

<a href="/user?destination=<?php echo $_GET['q']; ?>">User Login</a>

Now you have a handy little link that will redirect a user back to the page he was viewing before he logged in.

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.