How the new STLIMC Website Was Built

How the new STLIMC site was built using Drupal (drupal.org). The first in what will likely be many drafts...

"Sections" on STLIMC
The "sections" vocabulary on reboot.stlimc.org has the following terms:
newswire
feature

Defining the newswire and feature spaces as taxonomy terms allows the site to use the same content-types (and thus the same content submission forms) for both. This greatly simplifies upgrades (e.g. adding capability to upload images in batch), since the upgrades need only be performed on a single content type to affect both newswire and features.

These terms would normally appear in a "Sections" listbox on the node/add/article* pages, but I've set taxonomy access control so that only editors may post stories with "feature" attached to them. Also, I use the Taxonomy Super Select module to convert the "sections" listbox into radio buttons (more intuitive UI), and I use the prepopulate module to have the "newswire" button selected by default. (Notice how the numerical taxonomy IDs are encoded into the URLs on http://reboot.stlimc.org/publish) This, however, has turned into a clumsy hack, and it makes the content submission forms cluttered, a common complaint from STLIMC users.

Better would be to use the formfilter module to remove unnecessary bits from the forms (as Tampa Bay IMC did)...
http://dejitarob.wordpress.com/2007/11/26/how-i-used-drupal-to-build-tam...

...or to write a custom module to streamline the forms even further. I've actually done the latter to make the "log revisions" textarea only visible to editors/admins, but it's a kludge I'd like to port to formfilter.

Taxonomy
The site at reboot.stlimc.org has the following vocabularies set up for categorizing and filing articles submitted.

Section (newswire, feature)
Subject (Art/Culture, Biking/Transit, Civil Rights, etc)
Categories (News, Announcement, Commentary, etc)
Locale (STL, MO/Midwest, USA, Global)
Free Tagging

The "section" vocabulary is not open for public editing, since that is basically how we distinguish newswire articles from feature articles (using the views module), while still using the same article content-type. The "Free Tagging" vocabulary is kept separate from "Subject," as that allows users to select from generic topics like Crime/Police and then type in keywords relevant to St. Louis issues, e.g. "Civilian Oversight."

We also have other vocabularies set up related to stlimc process, site design, etc which we keep separate from the content-related vocabularies listed above, and which are not attached to the "article" content-type:

Internal (not public)
Workspace
Reboot topics

There is some cruft in this taxonomy that needs trimming, but here is how things stand for stlimc now.

STLIMC Frontpage
The frontpage visible at http://reboot.stlimc.org was constructed using the panels module, which I augmented with a custom 3-row layout. The top row is the "Welcome back to STLIMC" blurb, the middle row is the "published_features" view mentioned below, and the bottom row is the blurb about the archives.

Views on STLIMC
The views module is used to create the following pieces, among others:

http://reboot.stlimc.org/published_features (just a list, no teasers)
http://reboot.stlimc.org/published_features_teasers (teasers, used in front page)
http://reboot.stlimc.org/newswire (teasers)
http://reboot.stlimc.org/otherpress (used with weblinks and CCK modules)
http://reboot.stlimc.org/calendar (used with date, CCK, date API, Calendar, and Calendar iCal modules)
http://reboot.stlimc.org/calendar_ical (ical calendar feed)
http://reboot.stlimc.org/calendar_rss (rss calendar feed)
"newswire - local" block on front page
"newswire - elsewhere" block on front page
"upcoming events" block on frontpage (using date modules listed above)

http://reboot.stlimc.org/newswire_feature_promo_unpublished
http://reboot.stlimc.org/unpublished_features
http://reboot.stlimc.org/unpublished_features_teasers

I attach to this page the code of the actual views. What you will basically see is that feature stories are distinguished from newswire stories based on whether they have the "newswire" or "feature" term attached (which appears in the views' code as ID 44 or 41, respectively). For now, I would recommend removing all references to votingapi in these views (see bugs, below).

Also, the last 3 views with "unpublished" in their name will eventually only be visible to editors, because they represent center column stories that still await editorial consensus.

User Roles
This site has the additional user roles "editor" and "co-op" defined, which you will see as ID's 4 and 5 in the views code mentioned above.

Content-Types
This site uses the CCK modules, et al, to define the following content types:

article
article-audio (using CCK+audiofield)
article-video (using CCK+videofield and emfield)
date (using CCK+date)
otherpress (using CCK+weblink)
blog (no CCK, just Drupal's blog module, may be obsoleted)

The image upload field on the article* types is constructed using the CCK+imagefield+imagecache modules. This is based on the write-up by worcester IMC:
http://www.worcesteractivist.org/wiki/Building_an_Indymedia_site_on_Drup...
This approach quickly became cumbersome, since it requires writing highly customized (and labor-intensive) PHP+CSS templates for each content type (using the contemplate module) to streamline/tighten up layout. I've not done this yet, which is why the site's page layout still looks kinda rough.

An alternative implementation using the upload_preview module is described by Tampa Bay IMC:
http://dejitarob.wordpress.com/2007/11/26/how-i-used-drupal-to-build-tam...

Finally, all content types have "create new revision" turned on by default (via admin->content->types) and only users with admin role have the "administer nodes" permission. This preserves *all* revisions of those content types, which can help collaborative online editing. The drawback is that this causes the "log revisions" textarea to appear on the content submission forms, which can be confusing to newbies. For now, I have a custom module that specifically hides this field, although the formfilter module is probably more elegant.

Caching
Site-wide caching is set to normal mode. To further ease the server load caused by users logged in, I've also set up the blockcache module to created cached versions of all the dynamic blocks (especially free-tagging) in the left and right columns, except Drupal's navigation block.

Clean URLS
Clean URLs are enabled (likewise Apache's mod_rewrite), and I use the pathauto module to create more intuitive URLs:

Node paths...
Default pattern: [title]
Blog path: blog/[author-name]/[title]
Forum path: forum/[title]
Otherpress path: otherpress[yyyy]/[title]
Article path (i.e. feature & newswire): [term][yyyy]/[title]
Article_audio path: [term]_audio[yyyy]/[title]
Article_video path: [term]_video[yyyy]/[title]
Date path: event[field_date-yyyy]/[title]

Translate Block
Raw PHP code to redirect to translate.google.com:

<?php
$translate_desc = 'Translate this page into Spanish (by machine) / Traduzca esta pagina a espa&ntilde;ol (por machina)';
$google_url_prefix = 'http://translate.google.com/translate?u=';
$google_url_suffix = '&langpair=en|es&hl=en&ie=ISO-8859-1&safe=off&prev=/language_tools';
$current_page_url = 'http://'.$_SERVER['SERVER_NAME'].$_SERVER['REQUEST_URI'];
echo '<a href="'.$google_url_prefix.$current_page_url.$google_url_suffix.'">'.$translate_desc.'</a>';
?>

This really needs to be anonymized.

Modules on STLIMC
Here is a list of the Drupal modules used so far.
http://reboot.stlimc.org/drupal-modules-used-stlimc

Bugs, cruft, etc on STLIMC
There is a vocabulary named "workflow" with a single term "draft-editorial." This was originally intended to be used with the taxonomy access control module such that stories with "draft-editorial" term attached would only be visible to editors.

This quickly became problematic, since I also set up an editorial voting function with the actions, voting API, vote up/down, and voting_actions modules. The idea was that only stories with enough positive votes from editors would appear in the center column, like the old dadaimc site. Editors took to voting on newswire stories (as they did on the old dadaimc site), which made those stories inaccessible to everyone else because the voting action attached the "draft-editorial" tag to the story.

I need to revise how editorial voting and/or newswire story promotion is done, hence my hesitance to go into detail how reboot.stlimc.org is currently put together (or for that matter, not together).

Furthermore, there are bugs in the voting API module that screw up views dependent on # of votes. I had to patch the votingapi_views and votingapi modules (both bundled in Voting API tarball) to fix this.
http://drupal.org/node/141439
http://drupal.org/node/168282
http://drupal.org/node/181585
http://drupal.org/node/189311

In general, there is a fair amount of cruft and inelegant kludges that have wormed their into the site, and I'd like to focus on removing them rather than documenting and let others repeat my mistakes. In particular all the business with the prepopulate module and the workflow taxonomy to differentiate published editorial stories from unpublished stories from newswire column really needs to be fixed.

Todo items for this site (i.e. trees for the forest):
http://reboot.stlimc.org/web-tech-todo-reboot.stlimc.org
Other stuff related to Drupal for Indymedia
http://reboot.stlimc.org/drupal-development-indymedia