Site for internal use at magazine - simple example

I've just put together a simple Drupal site for internal use at our popular science magazine. I can't share the site with you, but I've written a brief description of its functions and how it was built. I hope it may be useful for some other people.

The purpose of the site was to provide myself and interested colleagues with comfortable means of:

• collecting, sharing and rating press items suggestions;
• collecting, sharing and rating suggestions for our page with scientific happenings; and
• collecting and sharing contact information to researchers and press assistants.

Brief background

Our magazine has five editors, plus a managing editor and an editor-in-chief. We print eight issues per year. The time to work with reports and full-scale articles is plenty, while the time to work with press items is short. The site's intention is to facilitate work with press items.

Installing and configuring the site

• The site was built on a server at a Scandinavian budget web-host company (one.com) which is quite sufficient for a low-traffic internal site, but probably won't manage a medium-traffic official site. (I had to comment out the options lines in the .htaccess file to make the site work on the server - the host had these options set already, and wont't accept attempts to change them. Also, Poormanscron had to be installed, since the host doesn't support the standard cron.php.)
• The latest Drupal version (5.2) was downloaded along with a number of modules I knew I would use. They were all extracted, modules placed in the sites/all/modules folder, and a /files folder was created and given writing permissions. A theme (Aurora) was also downloaded, extracted, and placed in the sites/all/themes folder. (This might not be the prettiest of all themes, but it is not the ugliest, has a certain editorial style, and is space-efficient.)
• Finally I ran through the installer - added a sensible prefix to the database table - and created the first Superadmin account. I then created an admin role and my personal login, and used the Admin Role module to ensure that my own account would have all permissions. Standard site settings were changed, including theme and logo.

Creating content types

To gather and share the intended information, three new node types were created. Two vocabularies of taxonomies (categories) were also created, to make the nodes more useful/searchable.

• Apart from standard CCK fields, I also downloaded sub-modules Date (plus Javascript Tools), E-mail field, Fivestar (plus Voting API) and Link.
• Content type contact included the following fields: name (title field), organization (text field), title (text field), notes (body field), phone number (text field, not CCK phone), e-mail address (e-mail field), link (link field).
• Content type press item suggestions included the following fields: title (title field), magazine section (text selection list), source (text field), release date (date field), intended issue (text selection list), description (body field), link (multiple link field), contacts (multiple links to contact nodes).
• Content type science happenings included following fields: title (title field), intended issue (text selection list), link (link field), date (date field), place (text field, not location field), notes (body field).
• The taxonomy module was enabled, and two vocabularies were created. The first contained broad science fields, such as physics, medicine and humanities. A few sub-categories I thought would be useful were also added - such as astronomy and history. The second vocabulary was put to free-tagging, to describe fine-grained research fields (for example cancer research, water pollution, etc). The first vocabulary was tied to press item suggestions, and both were tied to contacts.

Press item suggestions and science happenings both had Fivestar rating turned on, to facilitate prioritizing news items.

Creating views for content types
Four views were created, in order to make the information accessible and searcharble. (Only standard Views was used.)

• The view/list search contacs lists contacts. Both vocabularies are used as exposed fields, allowing filtering on "physics" as well as "high-energy particle physics". That the free-tagging field automatically suggests existing terms was crucial to make the search userful. Both filter terms are optional.
• Te list Science happenings uses only intended issue as exposed filter. I had some trouble using dates as exposed filters - at first the expose (or even delete) buttons were missing, and when I finally got them exposed the filter didn't seem to work. I finally gave it up, deciding that this site is a simple beta-test in any case. (I suspect that the problem comes from using two exposed date-fields with different operations - "greater than" and "less than" locked on them. Time will tell.) Discarding time as exposed filter, I changed "intended issue" into a required field.
• The list All press item suggestions also uses only intended issue as filter exposed to the user. The list is mainly used by the editor coordinating all press items.
• The list My press item suggestions uses intended issue as exposed filter, and has a fixed filter to show only press item suggestions created by the user.

All lists are represented in a menu, and all listed items have links to the full nodes. I also put links to creating new nodes in the header of all lists.

Improving user interface

To make it easier to create new contacts, science happenings and press item suggestions, I installed Nodeformpopup and Nodeformtemplate. The former provides bookmarklets that creates a popup "create new node" window with content passed on as arguments, and the latter allows customizing how these arguments should be pasted into a content type.
The result is that an active web page can quickly be submitted as a new node. URL and title is used as links, and marked selection is used as description. It does not work perfectly (selection appears to be cut after one line and there are issues with non-english characters), but it makes it much more convenient to add content.

I also made a custom easy-to-navigate menu block for non-admin editors. The standard navigation block was hidden using Menu per Role module. (Later, I realize that the Menu per Role module wasn't necessary to hide the navigation menu block, so the module isn't actually used on the site.)

Configuring access

To make sure that only editorial staff access content I made some changes in the access control - particularly de-selecting "access content" for anonymous users. Site settings were also changed so that admin approval is required to become an authenicated user.

Possible extended use

There's a number of functions that could be added to the web site in the future:

• collecting RSS feeds from sites our magazine is watching;
• collecting some documents on editorial policies;
• using contact form to e-mail all editors (or other staff) at the magazine;
• integrate site content further into the workflow - for example by adding fields for status "will be published/won't be published/publishing undecided" and text lengths;
• adding support for writing short texts directly on the site, using tinyMCE;
• creating startpages with link collections - inlcuding customized links for each editor;
• ...