Download our free how-to guide for setting up your new Drupal site and using our themes

SocialistWorker - a stellar Drupal-based news site

Front page Panel of SocialistWorker.org
Story node on SocialistWorker.org
Print version of a story on SocialistWorker.org
Send-to-a-friend feature on SocialistWorker.org

Yesterday we attended the Berkeley Drupal User Group meeting and saw a fantastic showcase by Derek Wright (dww) on the recently re-launched SocialistWorker.org.

This is a classic newspaper-on-Drupal site. As far as I understand it, this magazine has existed in print form for years, and was looking to overhaul their online presence with a CMS backing it. They also wanted to go from a weekly to a daily edition. This site makes extensive use of Panels 2, Views, ImageCache, and CCK content types/fields to create a highly functional site without much custom development.

Front page

Several custom Panels were defined, that the editors can choose from when laying out their home page each day, with subtle variations on the size of the leading story, column widths, etc.

  • Front page is entirely drag-and-drop, using Panels 2
  • Editors can select combinations of headers (with configurable sizes), teaser images, story teasers, related links
  • A draft Panel for tomorrow’s front page exists, so the editors can lay it out in advance

With the swift press of one very large red button:

  • The existing home page gets archived to an archive/currentdate path (only the display settings for the panel need to be saved in the database, Derek explained, so there’s very little overhead for storing all these historical front pages)
  • The new panel for the home page replaces the previous one
  • Any unpublished nodes used on that front page are automatically published

Stories

Derek spent the bulk of the showcase just discussing the elaborate Story content type. Stories are mainly sent via email, and also editors entered historical issues of the paper.

Numerous fields here drive the content behind the site, including:

  • Categorization (taxonomy) by department — more extensive use of this will come later with a rigid, hierarchical taxonomy that will be used for related stories
  • Several fields (with custom theming defined) for things like the introduction and byline are set up so editors can finely tune how the lead-in of the story will be shown
  • Since stories have multiple authors, an autocomplete nodereference field is used for a "Person" content type, which has the person’s name (first and last name fields, then the Automatic Nodetitles module is used to join them together as the node title), and a short bio/list of any affiliations — this started out as a simple taxonomy field, but it left them unable to adjust the order of authors
  • Freetagging field for additional contributors which shows up at the bottom of a story
  • The Drupal Markup Engine module is used for editors to place a particular image (as nodes) preset anywhere in the content and adjust alignment — Derek had set up a handy searchable view so editors can easily lookup the nodes for images, related content, and inline boxes, which adds a column in the view’s theme with copy-and-paste markup already generated for the DME tag
  • A little bit of jQuery on the story node add page is used to show/hide fields specific to only certain classifications of nodes (ie. column vs interview)
  • Some custom code is also used to ensure that the pathauto-generated date path and story publication date always match
  • They are also using a path redirect module so that editors can enter the historical .html paths from the previous site and get a 301 redirect to prevent linkrot
  • Other fields exist for story weighting (used to order stories when they are not manually laid out)
  • Some initial location fields have been added, but SocialistWorker isn’t yet using this — it will be so that location-dependent content can be displayed to users
  • A very well thought-out printable version has been set up, which hides the header, sidebars, and re-formats the story’s content for printing
  • Derek made extensive modifications to the Send module (contributed back as patches), which added new features, including formatting the article in ASCII text below

Other

The site currently gets several thousand visitors a day, the vast majority of them anonymous users. They have not encountered any performance issues yet, but are planning to add new features which will put more load on the site. Most of the rest of the site is built with simple views.

Derek identified the search as a current weakness. Given that stories are made up of multiple nodes and text fields, Drupal’s core search engine does not do a very good job of searching for this site. For example, since authors are separate nodes, they do not show up at all in the search engine as related to stories. He made a good point here, that what really needs to happen is stories should be indexed in the format as they are displayed, with node references and other embedded content intact — not as just the base node in the database. In the meantime, they added a Google search link to the search page for better searching.

All this talk about Drupal newspaper sites lately! SocialistWorker is a fantastic example of this category. Kudos to Derek and the rest of the SW team! 

 

nice writeup.

"What really needs to happen is stories should be indexed in the format as they are displayed, with node references and other embedded content intact"

thats exactly what drupal core search does.

Thanks for writing and sharing this.
BTW, SocialistWorker is really nice Drupal site.

Thanks for the nice write-up! I gotta finish the one I started and post it on d.o -- when I do, I'll link here. ;)

One minor point -- you linked to http://drupal.org/project/print but I'm not using that module at all. Our print-friendly pages are all generated by a little custom code: a custom menu callback at http://socialistworker.org/print, and a menu callback function that does the magic to render the page with the correct CSS, no sidebars, move the inline content to the bottom of the page, etc.

thats exactly what drupal core search does.

That might be what you expect, but it's not what's happening. :( I'm 100% positive that the output of the node-story.tpl.php file for a given node is NOT what's getting indexed by the core search index. It's completely obvious from the sample snippets of text displayed with each story, and by the results themselves, that the raw DB fields for the node are the things being indexed, not the finished page as rendered by the theme and output to the end-user.

I haven't actually debugged it closely enough to see exactly where things are going wrong, but I'm sure it's broken. And, although I've got lots of custom code for this site, I haven't (yet) hacked core's search functionality at all. ;)

hello, thanks for the write up, the site looks and works really good, -i was wondering that how did you set the 'Issue/Edition' in this paper's case is 'Weekly' in paper.

I presume it is presented on the site with the week.module or with a view type with date/week. that is presentation,

but ny question is about setting an Edition' is there a taxonomy or a CCK field for 'Edition' (similar to what you describe a 'Person' ... so the Editor sets up edition issues and the writers select -what issue he/she is publishing than selects the articles posted to publish in that EDITION.. are editions a vocabulary/Term? a CCK type with and you setup a Content type called 'Edition' than use node_clone.module for each issue?

thanks

Is that theme available on any site or is it a custom one? It's amazing!