Integrating home grown and feed content with the #drupal aggregator module

Posted by Craig Aschbrenner

 
 
On a project that I'm working on, a situation has arose where the client wants to display content that is both generated directly on their site and sourced from external sites (i.e. feeds).  To the end user this should be a fairly seamless experience and there are a couple of solutions that should satisfy this requirement.

Concepts to keep in mind.
  • Integration of home grown content and content from external sources.
  • Provide as seamless a user experience as possible.
  • Some sourced content (via feeds) may only contain titles and / or teasers.
Part I will discuss using the Aggregator module.  Part II will focus on using the up-and-coming Feeds module.

Aggregator
(core module) (linkage)

Drupal core provides the Aggregator module for optional use.  This module basically accepts feed streams and displays the individual pieces of content.  Each feed can be categorized if desired.  

Thinking back to our requirements above, how do we provide a seamless integrated experience with home grown and feed content?  The trick to this is creating a feed of home grown content and then using the Aggregator module to pull it all together.  

If you are familiar with the Views (contrib) then you will find it fairly simple to create a feed of the home grown content.  I won't get into the specifics of the Views modules, however I'll point out a few details on how to create a feed. 

Creating the Feed
  1. A view feed is a type of display just like a page or block display.  Simply select feed from the drop-down and then click on 'add display'.

  2. You'll notice that the 'Style' setting is set to RSS Feed.  If you have various style plug-ins available, go ahead and select one.  If not, simply select the 'Row style' of 'Node'.

  3. Scroll a bit further down and you'll find the 'Path' setting.  This is simply the relative URL to get to the feed.  Based on the setting in the image below, the feed would be found at mysite.com/feed.  You could give the 'Path' setting a value of 'news/rss.xml' to make the feed available at mysite.com/news/rss.xml.  


Setting up Aggregator
  1. After enabling the Aggregator module head on over to Administer -> Content Management -> Feed Aggregator and select the settings tab (admin/content/aggregator/settings).  On this tab take notice of the allowed HTML tags.  If any of the external feeds contain tags not in this list then they will be stripped out.

    Determine how many to display and how long until they expire.


  2. Now that are basic aggregator settings are configured, select the 'Add Feed' tab and let's start adding feeds.  Simply add a title for the feed, the URL of the feed, and how often to pull updates.  Make sure you have cron correctly configured.

    We will want to add the home grown feed (mysite.com/feed) that we created above and any external feeds that we're interested in.


Using the Aggregated Feed

Now that we've added all of our feeds and cron has successfully run, we can head on over to mysite.com/aggregator to view the content.  I believe there is also a syndicate block provided.

That's it!

The solution isn't perfect but it does the job.  I've listed some pros / cons of this solution below.

Pros
  • Fewer nodes are created which should help performance in the long run.
  • Simpler to setup, at least compared to future examples.
  • Clicking on a title takes the user to the source of the content.  There isn't duplicate content.
Cons
  • External content are not searchable within the main site.
  • External content expires.  (this may or may not be a con)
  • External content cannot be used elsewhere (i.e. other views) on the site.
  • Aggregator page displays full body text and not teasers.

Comments [0]

Twitter widget using the Computed Field CCK module

Posted by Craig Aschbrenner

 
 
In an earlier article I described how we can create a drupal block to display a twitter profile widget.  This earlier method would use PHP in the block to evaluate the node each time and check if a twitter account existed.  It works great but there are other alternatives I wanted to explore.

Yesterday I started using the computed field module.  This is a CCK add-on module that executes PHP code during a node insert/update and (optionally) stores that value in the database.  I say optionally because I believe you can also set it to evaluate PHP on the fly, however for something like a twitter widget we don't need to do this dynamically.  Once the widget information is stored in the database we only need to display it.

So the objective here is to use the computed field to check if the node contains a twitter account.  If it does then we simply compute the widget code and save it.  If not, we leave it blank.  So let's get started.

Note: I'm going to assume some basic knowledge of installing and enabling modules.

Step 1 - Create our content type

Head on over to Administer > Content management > Content types > Add content type (admin/content/types/add).  For now let's keep this simple and give this content type a name of "Company" and a type of "company".  Save the content type.

Step 2 - Add a twitter account field

Next we want to select the "Manage Fields" tab of the company content type.  Scroll down and we see that we can add a new field.  Let's give this new field a label of "Twitter Account", a field of "field_twitter_account", and then select "Text" for the field type and "Text Field" for the field element.

After clicking Save we're taken to the CCK Text field options.  We don't have to change anything here, but since a twitter account has a max of 20 characters, let's set those parameters and then Save the field.

Step 3 - Add the twitter widget field

Let's head back to the "Manage Fields" tab and add another field.  This time we're going to create the twitter widget computed field.  Let's give this field a label of "Twitter Profile Widget", a field of "field_twitter_profile_widget", and then select "Computed Field" for the field type.  The form element will auto populate with Computed.

After clicking Save we're taken to the CCK Computed Field options.  Add the following code in the "Computed Field" section.

$node_field[0]['value'] = '';  // Set empty initially

// If twitter account provided then create widget info
if (isset($node->field_twitter_account[0]['value'])) {
  $node_field[0]['value'] = '<script src="http://widgets.twimg.com/j/2/widget.js"></script>
    <script>
    new TWTR.Widget({
      version: 2,
      type: \'profile\',
      rpp: 6,
      interval: 6000,
      width: \'auto\',
      height: 200,
      theme: {
        shell: {
          background: \'#333333\',
          color: \'#ffffff\'
        },
        tweets: {
          background: \'#000000\',
          color: \'#ffffff\',
          links: \'#4aed05\'
        }
      },
      features: {
        scrollbar: true,
        loop: false,
        live: true,
        hashtags: true,
        timestamp: true,
        avatars: false,
        behavior: \'default\'
      }
    }).render().setUser(\''.$node->field_twitter_account[0]['value'].'\').start();
    </script>';
}

Now scroll down to towards the end of the page and set to store this value in the database as a "Text" field.  In addition make sure the "sortable" option is not checked.

Step 4 - Set the field Display Settings

Now that we have the fields available in the content type we need to configure how we want them to display.  Head on over to the Display Settings tab of the content type.  Set the twitter account and twitter profile widgets as follows.

What we have done is hide the twitter account from displaying on the node.  There is no need to display that if we have the widget.  The profile widget is set to display the computed value (what we set above) on the node page and hide the label.  Both values are also set to hide on the teaser.

Step 5 - Create the content

Now that are content types are created we can go create our company content.  Go ahead and create a few.  You'll notice that after saving the node the twitter profile widget will display.  If you modify the node and change the twitter account the widget should also update to the proper display.

Step 6 - Drink a Beer!

This is the most important step in the whole tutorial.  Let's not forget to follow it.

Limitations
I do want to point out one limitation of this method.  If the widget code were to change for whatever reason, we'd have to update the content type with the new code.  We'd then have to edit every node and save it so the computed value is recalculated.  There is probably a way to do this in batch (with VBO maybe) but I have not researched that yet.

 

 

 

Comments [0]

A different twitter widget for each #drupal node

Posted by Craig Aschbrenner

 
 

I'm putting together a site that has a content type called Company.  Each company may or may not have a twitter account where they broadcast updates.  The requirement is to display a twitter widget on each company node if one exists.  

My first thought was to search through the list of custom modules instead of trying to reinvent the wheel.  I found several twitter-related modules, however nothing seemed to fit the bill.  The closest module was the twitter module but that connects users accounts to their twitter accounts.  I need something to connect companies (as nodes).

Later through a google search I found that twitter.com offers widgets, and specifically a profile widget.  The profile widget, which you can now see on the right side of this blog, provides the html/script code to place inside of your website to display the twitter feed of any account.  We can use this widget and create a drupal block with some PHP code to pull the twitter account from the company node and display this widget.

I'm going to assume that the reader has some basic knowledge of the CCK module and how to create a drupal block.

Step 1 - Adding twitter account field to the company content type

Head on over to Administer > Content Management > [Content Type] (admin/content/node-type/[content-type]/fields) and select the Manage Fields tab.  Towards the bottom of the screen we'll add a new field.  I gave mine the label of Twitter Account and field_twitter_account.  Use the single line text field/widget type.  Twitter accounts can be up to 20 characters so I set the field to allow a max of 20 characters of plain text.

Step 2 - Creating your content

Now that we have our content type created, let's create some content.  Create a new node and populate the twitter account field.  Go ahead and create several nodes if you like.

Step 3 - Create the Twitter Widget

Head on over to the twitter profile widget and follow the instructions provided to create the twitter profile widget.  When you are done copy the code provided for later use.

Step 4 - Create the Twitter block

Head on over to Administer > Site Building > Blocks (admin/build/block/add) and select to add a new block.  In the body of the block we are going to add the code copied from the twitter profile widget.

<?php
$node = menu_get_object();
$twitter_acct = $node->field_twitter_account[0]['value'];
if (!is_null($twitter_acct)) {
?>

<script src="http://widgets.twimg.com/j/2/widget.js"></script>
<script>
new TWTR.Widget({
version: 2,
type: 'profile',
rpp: 6,
interval: 6000,
width: 'auto',
height: 200,
theme: {
shell: {
background: '#333333',
color: '#ffffff'
},
tweets: {
background: '#000000',
color: '#ffffff',
links: '#4aed05'
}
},
features: {
scrollbar: true,
loop: false,
live: true,
hashtags: true,
timestamp: true,
avatars: false,
behavior: 'default'
}
}).render().setUser('<?php
echo $twitter_acct;
?>').start();
</script>

<?php
}
?>

The code above in blue is PHP code that has been manually added to the code provided by the twitter profile widget.  The PHP code does several things.  It first loads the node object and then the twitter CCK field we created.  If the field is not null then it will display the twitter profile code.  Within the twitter profile code we also add the twitter account value to use.

Note: Make sure to select the input format of PHP code so that the block can evaluate the code.

Step 5 - Add the block to a region in your theme

Now that we have a block created we can add the block to any region within our theme.  Make sure to make the block visibility settings such that it will only display on node pages for the content type we're interested in.  If you are unfamiliar with how to do this, check out some php block visibility snippets or use the excellent Context module.

Step 6 - Drink Beer!

This is the most important step in the whole tutorial.  Let's not forget to follow it.

Comments [0]

DrupalCamp at the SouthEast LinuxFest

Posted by Craig Aschbrenner

 
 

It's been a few months since I've been able to do much with Drupal, but I recently attended the DrupalCamp at the SouthEast LinuxFest (SELF) this past weekend.  This was particular exciting for myself because I had yet to attend a Drupal event.  Being in Charlotte I'm not too aware of many drupal users in the nearby area.  Even many of those in Charlotte are on the opposite side of town.  It was great to finally meet some of these drupal folks and hopefully in the future it won't take heading out of town to catch up with them again.

As far as the DrupalCamp itself, I thought it was a success for my first event.  Some of the sessions I attended were simply a review of what I already knew, while some others gave me insight into more areas of Drupal I need to research.

One bit of feedback I do have for presenters is that a presenter can make or break the session.  There were a few sessions where I could tell the presenter knew what he was talking about, however the presentation itself was lacking and in some cases added more confusion.  Presenting is not an easy task and not everyone receives information the same way, but I would stress that the best content can be lost in a poor presentation.

All in all, it was great to get out and I do plan on hitting some upcoming events.

Comments [0]

An alternative method to role management in #drupal

Posted by Craig Aschbrenner

 
 
I'm putting together a small drupal site for a group of very non-technical users.  There are three departments that together make up the whole team.  Each department has different responsibilities (i.e. roles / permissions) on the site.  I needed to find an easy way for this role management to be handled by department heads and not the site administrator (user #1).  

A couple of modules exist that provide role management capabilities / permissions.  These include the RoleAssign and Roll Delegation modules.  These modules were not ideal however.  

The RollAssign module required the administer users permission which gave too much power.  They would be able to modify users and roles outside of their department.  The Role Delegation module creates a hierarchy (of sorts) where we can configure (by role) what roles can assign other roles.  But then I would have to create a role for each department head just so they could add their department role.  

Luckily one of the other requirements for the site was that each department would have their own group with the department head owner of those groups.  The department heads were already adding / removing users to those groups so let's trigger off of those events to assign roles.  This turned out to be a lot easier than I thought!!

So as it turned out, I used the organic groups module with the rules module to handle role management for these departments. Here's how we accomplished this.

Step 1 - Create each role and assign the permissions
There was nothing out of the ordinary with creating the roles so not much to explain here.

Step 2 - Create each department group
I had already created out department group node type so all we had to do was actually create the groups themselves.  The one thing to note however is that I did write down the node ID for each group.  This will become important later on. 

Step 3 - Setup department heads
This simply was editing the group and changing the authored by field to the username of the department head.  I also manually added their department roles to them.

Step 4 - Create the rules
This isn't as difficult as it may sound but it does make use of the group node IDs we wrote down from step #2.  

Triggered Rule - Add Department Role (repeat this for each department)
  1. Create a rule to trigger off of the event: User approved to group by admin.  The department groups used membership moderation so this event made sense.  

  2. Add the condition: Execute custom PHP code.  We use this condition to check and see if the user is joining a particular department.  In the text box labeled PHP Code I entered the following:

    return (module_exists('og') && og_is_group_member(INSERT_GROUP_NODE_ID_HERE, FALSE, $acount->uid));

    This code first checks to make sure the organic groups module exists.  If we forget this check and the module is removed from the system for some reason, bad things happen.  The second part of the code uses a function provided by the group module to check if a user (based on user ID) is a member of a group (based on node ID).  You'll notice where we need to insert the group node IDs we wrote down from the earlier step.

  3. Add the action: Modify user roles.  For the arguments configuration of this action we want to make sure we select User that subscribed to the group and not the active user.  Select the department role we want to add and save the rule.
Triggered Rule - Remove Department Role (repeat this for each department)
  1. Create a rule to trigger off of the event: User unsubscribes from group.  I tested and verified that this event is triggered when a user manually leaves a group or if the group admin removes them.

  2. Add the condition: Execute custom PHP code and enter the following into the PHP code section:

    return (module_exists('og') && $group->nid == INSERT_GROUP_NODE_ID_HERE);

    This code first checks to make sure the organic groups module exists.  The second part verifies that the group this code is triggering off of is the group we want.  Remember we're removing one role for each rule.

  3. Add the action: Remove user role.  Select the role to remove and also don't forget to set the argument configuration to User that subscribed to the group.  Save the rule.

Step 5 - Drink Beer!
This is the most important step in the whole tutorial.  Let's not forget to follow it.

So what we're left with now are departmental groups that are managed by the department leads.  Simply by managing those groups the group members are assigned the appropriate roles to perform their duties throughout the rest of the site.  After this initial setup, at most the site admin (user #1) will only need to change the group owners should the dept. lead change.  

So there we have it, a nice clean way to manage roles using activities that the users were already doing.  I like that!

Comments [3]

Wishlist: A better way to track discussions on drupal.org

Posted by Craig Aschbrenner

 
 

And so begins my series of wishful posts...

I'm participating in more and more discussions on the drupal.org forums to a) get assistance on questions I have and b) give assistance to other users.  I regularly check my tracked posts (/user/[uid]/track) to see if there are any updates.  This has worked out great to provide continual assistance or follow-up on my own questions.

The problem I'm starting to run into is that if there have not been any updates to the threads where I'm looking for assistance then I tend to lose track of those posts, especially as the number of tracker pages increase.  Granted I can check for posts with zero responses, however there are definitely open questions on threads that have responses.  There isn't an option to search only my tracked posts so I'm left paging through my tracker to open up thread after thread to check the status.

There are also some important discussions where my questions were answered but I would like to refer back to them, but again I'm left paging through looking for which post that was.  

In a similar fashion there are discussions taking place in threads that I have not participated in.  If I want to keep tabs on that thread then I need to post something useless just to keep tabs.  

The groups.drupal.org site has implemented the capability to subscribe to topics and groups to receive email notification.  I imagine on the drupal.org site this may be a burden.  I can only imagine how many people would be subscribing all over the place generating mass amounts of email.  I could see drupal.org ending up on many spam lists.  :)  

I think a good alternative may be to implement the flag module and allow users to bookmark threads.  Just by installing the flag module a bookmark flag is automatically created along with the view to display those bookmarks.  The view may need to be tweaked to provide the "new" / "updated" notification on threads and the permission to use the flag / bookmark would have to be granted to authenticated users, however this sounds like it would be a feature that would greatly reduce the annoying "subscribe" posts and give users some additional usability and tracking capabilities.  

So where do I start the petition to get this added?

Comments [0]

How to create tabs within groups with friendly URLs

Posted by Craig Aschbrenner

 
 
I've had several folks ask about how I created group home pages that included tabbed content.  I had several threads on the Drupal forums that discussed how to accomplish this but I had always intended to follow up with an actual tutorial. 

Modules used in this tutorial
The following are the main modules I'll be discussing, however several of these modules depend on other contrib modules like token.  

Step 1 - Planning

Content Types
Planning is important so let's make note of what we want and what we're expecting to see.  To begin with let's assume that we're going to have two types of groups:

Social - This is a generic group for members to create and socialize with the community.
Team - This is a generic group for members to work together as a team.

Now it's time to decide what type of content can be posted to a group.  For this tutorial we're going to go with two content types (News, Photos).  Assumption is that the reader has basic knowledge of creating photos/images as nodes.  We are going to want a tab for each of these content types.

So what we're going to end up with is three tabs (View, News, Photos).

Context & Friendly URLs
When viewing a group it's possible to have a different layout, theme, blocks, etc.  When viewing content within a group we want to maintain that feeling for the user.  We also want our URLs to be friendly and make sense.  Here are the target URLs we're shooting for:

Social: mysite.com/groups/social/<group name>
Team: mysite.com/groups/team/<team name>
News List: <group url>/news
News Item: <group url>/news/<news title>
Photo Gallery: <group url>/photos
Photo Item: <group url>/photos/<photo title>

Oh... and we want all this to happen without admin intervention.

Step 2 - Basic Installation

Install Drupal and the modules listed above.  I'm assuming some basic knowledge of installing and configuring drupal and modules.  The default configurations for the contrib modules should suffice for now.

Step 3 - Creating Content Types

A default Drupal installation comes with the Story and Page content types.  We will create a few more and at least one content type to act as the group.

Group Content Types
Let's first create our content type that will act as our group.  Head on over to Administer > Content management / Content types > add content type (/admin/content/types/add).  Provide the name and type of the new content type.  Make sure to scroll down to the Organic Groups Usage section and select Group Node.

2860808_d5d5.png

Repeat that step for both the social and team group type.

Posting Content Types
We'll follow the same steps as above to create our News and Photo except that instead we'll select the Organic Group Usage to be Standard Group Post.

2860852_8aca.png

Step 4 - Configuring Automated URL Alias Settings

Head on over to Administer > Site building > URL aliases > Automated URL Settings (/admin/build/path/pathauto) and make sure you're viewing the Automated Alias Settings tab.  Then expand the Node Path Settings section and you'll find where you can configure automated path aliases for each content type.

For each group type enter the following pattern: groups/[type]/[title-raw]
For each of the posting content types enter the following pattern: [ogalias]/[type]/[title-raw]

You can vary those patterns but the key piece is the [ogalias] token.  The way that will work is if content is posted to a group then it will create an alias that beings with the groups alias.  If a piece of content is not posted to a group then that token is left blank.  

Caveat (a big one)
There is one issue with this particular method.  If content is posted to multiple groups then we run into an issue with the [ogalias] token in the path.  Only one alias is created.  If we were to use the Rules module to create multiple aliases I believe the system will still pull the first alias that links to the node.  If the particular group post is marked as publicly viewable then that isn't too big of an issue even though we lose group context.  What will be a bigger issue is if the content is marked private.  In this case we get an access permission error if the user does not belong to the group for which the alias is pulled.

If we remove the [ogalias] from the pattern then this is a non-issue.

This particular issue luckily wasn't a deal breaker for the particular site I was creating so I continued on with the [ogalias] token.  What I ended up with was restricting most content to a single group.  And for the few cases where select users can post to multiple groups, I used the rules module to enforce that the post was publicly viewable.

There are probably other methods around this caveat, however this tutorial will walk through my implementation.  I would love to hear of other solutions.

So on that note... let's continue.

Step 5 - Enabling the Group Details Block

The Group Details Block will provide a list of content that can be posted to a group.  This is the primary starting point for most of my users to create content.

The OG module provides the Group Details Block, however it is not assigned to any region by default.  To enable this block navigate to Administrator > Site Building > Blocks (/admin/build/block).  Locate the block and assign it to a region.  

Step 6 - Moving the Create Content Menu (optional)

The reason this step is optional is due to the Rules module I use later on in this tutorial.

By default the Create Content link appears in the Navigation block.  Most of my users will not need to post content outside of their groups.  So what I did was create a new menu (/admin/build/menu/add) and then move the Create Content tree to the new menu.  

To move the Create Content simply open up the Navigation menu and click edit next to the Create Content item.  Scroll down to the Parent Item drop-down and choose your new menu.  

Now we want to provide this menu as a block to users of a certain profile.  Head on back to your block listing page and you'll find a block for the new menu you created.  Simply assign it to a region and then click on configure.  Scroll on down to the Role Specific Visibility Settings and select the roles that can post content outside of groups.

2861277_ffc9.png

Caveat: This doesn't actually stop a knowledgeable user from manually typing in the URL to the node add pages, however my users are not familiar with Drupal and I've also used the Rules module as noted up top to help catch issues. 

Step 7 - Configuring Organic Groups (optional)

The reason this step is optional is due to the Rules module I use later on in this tutorial.

Most of the OG configuration can be setup however you like, however there is a particular setting I use that restricts users from posting to multiple groups when using the add content links in the Group Details block.  To find this setting navigate to Administer > Organic Groups > Organic Groups Configuration (/admin/og/og) and scroll down to the Group Details section.  Here you'll find the Audience Checkboxes option.  I've unchecked this option so that a user will not have the option to post to multiple groups when using the links in the Group Details block.

2861454_53c4.png

Step 8 - Configuring the Rules Module

The Rules module is a pretty powerful module, however it can be confusing at first.  Without getting too deep into the different aspects of triggered rules, rule sets, etc. I'll just walk through the rule I created.

What we're essentially doing here is creating several triggers, one for each posting content type, that will call a rule-set.

8.1) Enable Rules Modules
The first thing we'll need to do is make sure the proper sub-modules for rules are enabled as shown by this screenshot.

2861856_d661.png

8.2) Identify Forms to Trigger Events
Navigate to Administer > Rules > Form events (/admin/rules/forms) then select the checkbox Enable event activation message on forms and hit save.  This will give us the option to enable triggers on forms but we'll have to choose which forms to handle this on.

2861921_3311.png

8.3) Activate Events on Content Forms
Navigate to each form that we want to trigger off of.  In our case we want to trigger off of the News and Photos create content forms.

News: /node/add/news
Photos: /node/add/photo

There will be a message similar to the one below with a link to activate events for the form.  There may be several messages if multiple forms exist.  Make sure to click only on the link for the content type form we're interested in.  Confirm the activation by clicking the activate button.

2861936_0e15.png

8.4) Create Triggers for each Content Type Form
Navigate to Administer > Rules > Triggered Rules (/admin/rules/trigger) and select to Add a new rule.   Complete the form similar to the image below.  The important piece is the Event field which is outlined in red.  Save the trigger.

2861986_8759.png

After saving your changes you'll be given the option to add conditions and actions.  We will not be doing that part just yet.  Instead, repeat this step for each posting content type (News, Photos).

8.5) Create Rule Set
Navigate to Administer > Rules > Rule Sets > Add a New Rule Set (/admin/rules/rule_sets/add) and complete the form similar to the image below.  The key piece is outlined in red.

2862063_0195.png

8.6) Add Rule to Rule Set
Open up the rule set we just created and select to Add a new rule.  Give it a label and category but do not change the rule set drop-down option. Save your changes.

8.7) Add Condition to Check for Multiple Groups
Select to add a condition for the rule we just created.  The condition we're going to add is Execute custom PHP code.  Select next and complete the form similar to the image below.  The key pieces are outlined in red.  Save the condition.

PHP Code (copy/paste): return (count($form[og_nodeapi]['#post'][og_groups]) > 1);

2862094_8d26.png

8.8) Add Action to Set Form Error
Select to add an action for this same rule.  The action we're going to add is Set a form error.  Select next and complete the form similar to the image below.  The key pieces are outlined in red.  Save the action.

Form element ID (copy/paste): $form[og_nodeapi]['#post'][og_groups]

2862125_f109.png

8.9) Add Rule Set to Triggers
Now that we've created the rule set, we need to return to all of the triggers we created earlier and add the rule set as an action. The resulting trigger rule should like the image below.

2862147_84d7.png

Step 9 - Adding Views Tabs

I'm going to assume some basic knowledge of views for this step, however I will highlight the key components of the view that will bring all of this together to give you tabs on your group nodes.

Navigate to Administer > Site Building > Views (/admin/build/views) and add a new node view.  Within that view create a page display.  Setup that page display similar to the image below.  The key aspects are outlined in red.

2862213_3820.png

Page Settings -> Path
What is important to understand about the path setting is that we begin with node/%.  What follows (e.g. news) can vary based on the content type, however node/% ties us into the group node.

Page Settings -> Menu
Setup the menu similar to the image below.  The key component is outlined in red.

2862235_41d1.png

Arguments
Setup the argument similar to the image below.  The key components are outlined in red.

2862243_6a13.png

Step 10 - Drink a Beer!!
Congrats!  You made it to the end of this tutorial.  Phew... now go get yourself a cold one.

Summary
  • (step 4) - [ogalias] token is powerful but also limiting if content can be posted to multiple groups. 
  • (step 8) - A rule can trigger off of a form and stop it prior to saving if multiple groups are selected and the post is not marked as public.
  • (step 9) - The correct views settings can make just about any page view act as a tab.

I hope you enjoyed my first tutorial.  I need another beer simply for writing this tutorial.  :-)

Comments [2]

1 page of 1

 
 
?