Will’s Similiblog

Didn’t find this documented (probably missed it in an obvious place), so here’s How to Do It, if you want.
(I’ve dabbled with this, but it is not implemented on my production site, due to the RSS feeds glitch noted below)

at Administer > content management > categories, for the Vocabulary “Category”, click “edit vocabulary.”

Under “Hierarchy”, tick the “Single” radiobutton; and save.

Back to Administer > content management > categories; for the Vocabulary “Category”, click “add terms”

add a subcategory term, and from the “Parent” drop down menu at the top of the page, select the Primary category that this will be a subcategory of.  Save.

The ordering of both Primary and Secondary categories can be set using the “weight” drop-down menu on the term creation/editing page.

When a Category containing sub-categories is selected, the sub-categories will show up in a horizontal menu directly below the horizontal Categories menu.

I do notice a problem with sub-categories, regarding RSS feeds - the feeds for a Category do not presently appear to include items listed in its sub-categories; and the Categories block does not list subcategories or include RSS feed links for subcategories.

As part of my featuritis dilemma, I deliberated about having this site aggregate selected feeds, or not - and decided on not.  The intention of this site, is to permit users in an academic community to identify and submit web-based items of interest, and to socially rate and discuss this content.  I considered having it aggregate some feeds that might contain a decent concentration of items of potential interest (e.g., the BBC Health News Feed), so that these would all show up in the Health News | Upcoming items section of the site, waiting for user promotion - but it feels that this would sidestep an important social component of this project, which is user exploration and identification of items of potential interest on the ‘web.  I’d rather have users aggregate feeds of potential interest elsewhere (individually, or on a separate group platform), and submit items that they discover to be of potential interest to this project.  More on that later.

But to set up feeds aggregation on Drigg, if this is desired, is a pretty easy matter.

See the tutorial here: http://www.drigg-code.org/node/149

First - at Administer > Modules,

activate the Aggregation module (part of the core Drupal distribution) and the Drigg RSS Feeder module (part of the core Drigg distribution).

Visit Administer > site configuration > Drigg module; and under the “RSS Import” tab, set the configurations for RSS import (the default settings are a reasonable place to start).

Feeds are set up at Administer > content management > news aggregator.

If you wish authenticated users to be able to add feeds (kindof a scary notion, unless your user base is well educated & disciplined), go to Administer > user management > access control, and check “administer news feeds” for authenticated users.

I installed the stringoverrides module, to permit customization of (some of the) text on the site without needing to hack this in the distribution files.

After installation & activiation, string overrides are configured at
administer > site configuration > string overrides
& this permits me, e.g., to easily replace the main-page text “Published scoops” with “Published items”, &c.

I’m using the default promotion strategy built in to the Drigg distribution for this site; but I have installed, and am playing with on a test installation, the “promotion on multiple factors” hack developed by Cedric Fontaine
(see here:)
http://drupal.org/node/214354

This involves hacking the Drigg promotion sub-module with the patch provided in the forum discussion above, and installation of the node radioactivity module.

The hack permits the choice of several methods of item promotion, which may be used individually or in combination.  These are set at
administer > site configuration > drigg module; under the Promotion tab.

[1] the default method based on total of points from vote and karma;
[2] total number of positive or negative votes received;
[3] sum of positive votes (negative votes have no effect)
[4] sum of negative votes
[5] radioactivity, based on settings for the node_radioactivity module, at
administer > site configuration > radioactivity
here a decay profile needs to be specified,
and a radioactivity profile needs to be defined - including setting decay half-life, cut-off energy, and incident energies from one or more sources, including Votes, Comments, and Node views.  Rating for a node will then be based on any combination of these incident energies, and will decay as defined over time.  Note that stories will not be demoted from the front page as their ratings decay over time; they’ll be promoted when they pass the defined threshold value, and beyond this, their ratings will determine where they fall on the page when sorted by rating with “top” sortings.  I think this is a very interesting promotion strategy, and may decide to implement it in the future on my production site, after I’ve given it a good spin in trial mode.

The built-in navigation, with categories, links and the sorting/filtering offered by the Drigg module, provide good navigation of submitted and published articles; to add to this, I added the contributed Drupal relatedlinks module.

After installing, at
Administer > site configuration > related links,
I enabled Manual, Parsed and Discovered links, all in a single block (only the first Block checkbox checked), for content type Scoops.

Manual links are created specifically when an item is submitted.
Parsed links are retrieved from the body of each node, from the description text entered by the submitter.
Discovered links are based on the Category and Tags vocabularies and by search terms.

Under Discovered Links preferences, I enabled taxonomy terms, search module, prefer same content type, and prefer newer results; for Taxonomy options, Tags (and not Categories).

The Related Links block is enabled at
Administer > site building > blocks,
at the top of the right sidebar, and named “Related items”.  It will show up by default only on node pages (pages displaying a single item), for which related items exist based on the setup criteria.

The most excellent tagadelic module comes as part of the core Drigg/Drupal release, to provide block- and page-views of tags for items.  Tags are created in the “tag” vocabulary of the taxonomy module, by freetagging when items are submitted.

The default configuration in Drigg, is to have tags link only to Promoted items (and not to Upcoming or Archived items).  I understand why some might want this (and it makes sense for search engine optimization, an issue which is irrelevant for my site, but might be significant for others) - but I chose to have tags link to items regardless of promotion status.

At
Adminster > site configuration > tagadelic configuration
untick the checkbox for “Only consider tags of promoted stories”

I’ve added 2 contributed Drupal modules to tweak taxonomy for tags on the site:

edit_term
taxonomy_similar

The edit_term module requires no configuration; it provides a handy interface for the site administrator to easily edit existing taxonomy terms, assign related terms and synonyms.

Taxonomy_similar also requires no configuration.  I’m playing with this, and not yet sure that I want to keep it in my installation.  After submitting an item, it displays a page with the tags used, and suggests any “similar” tags as alternatives to those used.  It does add an additional step to the submission process; but it might be useful to help consolidate tags and avoid “tag scatter” with the accumulation of related terms.  We’ll see.

I’m experimenting with the taxonomy_hide module.  Currently the Categories vocabulary shows up along with the Tag vocabulary in the “tags” for items; this module offers a way to hide display of these Category terms.  I’ll post my comments on this shortly in a comment to this post.

I’m also considering adding the community_tags module, to permit users (in addition to the individual who submitted the item) to feetag submitted items.  Again, I’ll post my comments on this after I’ve given it a spin on this platform.

addendum - I’ve decided to use both the taxonomy_hide and community_tags modules - see the comments appended to this post.

Since this is site is intended to facilitate social conversation on the submitted items, it would be best if the contributors were clearly identified.  It can be entertaining to see that an item was submitted by xenawarrierprinces531, but this doesn’t help as much with social dialog as it would to see the contributor’s real name associated with the item.

The contributed Authorship module can substitute a real name for the username in the “Submitted by ” line.

First -
Activate the Profile module, part of the core installation; and install & activate the Authorship module.
At
Administration > user management > profiles
create a user profile field to hold the user’s real name:
create a single-line text field
Category - personal information
Title - full name
Form name - profile_fullname
Explanation - your full name, as you would like it to read on items you submit
check the radiobutton, for “Public field, content shown on profile page and on membership list pages”
check the checkboxes for
user must enter a value
visible in user registration form

This will  add a tab “Personal information” on the user profile page, under which a field will appear for the user’s full name; this full-name field will also appear as a required field on the user registration form.

Now, at
Administration > content management > content types; Scoop
near the bottom of the page,
check the radiobutton for “Enable authorship module functionality”
enter “profile_fullname” (without the quotes) in the field labeled “The profile variable name used to store the real name”

The user’s full name (rather than their username) will now appear in the “Submitted by ” line of each submitted item.

I’ve added a few contributed Drupal modules, to add some bells & whistles to my site - to date,

authorship
edit_term
radioactivity
relatedlinks
stringoverrides
taxonomy_similar

Note that (as of this writing), Drigg is built on Drupal v. 5.10 - so all of these modules need to be the 5.x versions.

I’ll post short notes on configuration & use of each of these in subsequent posts.

This site is intended to be world-readable, but editable only by members of a closed user community (the students & faculty of a medical college); only these users will be able to submit items, and to vote on or comment on submitted items.

As all legitimate users have email addresses issued by the institution on its own domain, the easiest - and lowest-overhead - way of doing this, is to restrict registration to users with valid email addresses from our domain. Drupal permits us to do this easily using the built-in access rules and user settings modules.

At
administration > user management > access rules
deny email %@%.% (i.e., deny all email addresses, except those overruled by the rules below; % is the wildcard for any number of characters)
allow email %@institutionsdomain

At
administration > user management > user settings,
be sure to check “Require e-mail verification when a visitor creates an account” -
so that outsiders cannot register with a fictitious address based on the institution’s domain.

Note that if we wished to open registration to students/faculty of allied schools, we could add additional access rules,
allow email %@institution#2sdomain
allow email %@institution#3sdomain
&c.

It might be nice to add some text to the user registration form, to inform registrants of the need to use the correct email address.  The text below the email entry field on the user registration page is in the file user.module, in /modules/user/, at line 1332.  I changed the first sentence of this text to:

Your valid NCNM-issued e-mail address (addresses on other domains will be rejected by the system).

I wanted to provide users with a simple bookmarked script for submission of pages.  See the discussion re this in the Drigg Forums.

I ended up using

javascript:q=(document.location.href);t=(document.title);s=(document.getSelection());void(open(’http://YOUR DRIGG SITE URL/node/add/drigg?url=’+escape(q)+’&title=’+escape(t)+’&body=’+escape(s),”,”));

The actual code entered (I placed this on my “about” page) is

<a href=”javascript:q=(document.location.href);t=(document.title);s=(document.getSelection());void(open(’http://YOUR DRIGG SITE URL/node/add/drigg?url=’+escape(q)+’&title=’+escape(t)+’&body=’+escape(s),”,”));”> Submit to Drigg</a>

(replace “YOUR DRIGG SITE URL” with .. well … and replace “Submit to Drigg” with whatever descriptive text you’d like)

note - the Input Format on the page in which this is embedded (see link below the Body field) will need to be “Full HTML” in order for this to work.

Users can bookmark this using a right-click (on a Mac, ctrl-click) and “save bookmark as”; or can drag this link into their bookmarks toolbar.

Clicking this bookmarked script when vising a webpage, will open your Drigg site in a new window, directly to a “submit scoop” page; if any text is selected on the webpage to be submitted, this is picked up & entered automatically in the Description field of your Drigg site.  The page’s URL and Title are also automatically entered in their respective fields.  If the item has already been submitted to the site, this will re-direct instead to the node on your site for the already-submitted item.

This only works if the user is already logged in to your Drigg site.  If they are not already logged in, they receive an “Access denied” error, and will need to log in at that point.  Since Drigg opened in a new window, the page-to-be-submitted is still open, and when that window is made active again, the bookmarklet can be used to successfully submit the page.