Between one issue and the next a bimonthly printed magazine leaves sixty days of silence, and a web portal is the cheapest way to fill them without reprinting anything. This constraint settles everything else: the site should not copy the magazine, it should stitch together two layouts that ship every two months.

Context

The concrete case is the portal for a magazine on start-ups and innovation, published by a science and technology park. The magazine ships on paper, the PDF is a free download, and between one issue and the next the site carries short articles, event listings, reader comments and syndication feeds. The editorial team is not made of developers: whoever writes must publish without touching HTML, and that alone steers almost every technical decision.

The editorial constraint is tighter than the technical one. A journalist who lays out the magazine has no wish to learn a templating language to publish a two-hundred-word note, and every manual hand-off between the newsroom and the live site is a point where something breaks. The design question, then, is how much of the workflow can be left to the editors on their own without handing them a system nobody can later keep running.

Architecture

The engine is a mature open-source CMS. In February 2009 the sensible options for an editorial portal of this scale are essentially two: Drupal, whose version 6.0 shipped on 13 February 2008 (drupal.org), and WordPress, which reached 2.7 on 11 December 2008 (wordpress.org). At this date the practical difference between the two lies in the content model.

WordPress 2.7 is built around posts and pages, with an admin panel rewritten not long before — the left-hand navigation bar arrives in exactly that version. A newsroom used to writing prose learns it in a few hours. Drupal 6, instead, thinks in content types and taxonomies: an “article”, an “event”, a “featured start-up” are distinct entities with their own fields, and the menu system rewritten from scratch in 6.0 keeps them in order. For a portal that mixes editorial genres — long pieces, fact sheets, a calendar — Drupal’s entity model reduces the structural work, at the price of a steeper curve for whoever publishes.

On top of the CMS sit three components that do not depend on the engine choice.

The first is syndication. A trade portal lives off readers who do not drop by every day: feeds are the channel that reaches them. The choice is between RSS 2.0, very widely deployed, and Atom 1.0, standardised by the IETF as RFC 4287 in December 2005 (ietf.org). Atom closes some of RSS’s historical ambiguities — the explicit distinction between content and summary, dates in RFC 3339 format, mandatory stable identifiers for each entry — but in 2009 feed readers handle both formats without trouble, so the decision is pragmatic rather than doctrinal. Publishing both costs almost nothing and covers both sides of the ecosystem.

The second is PDF distribution. The printed magazine already exists as a print-ready file; putting it online as a free download closes the loop between paper and web in the most direct way. The technical question is which PDF to serve. A PDF generated for print drags along partially embedded fonts and prepress dependencies; for preservation the PDF/A-1 profile is preferable, standardised as ISO 19005-1:2005, which mandates full font embedding and forbids the elements that make a file unreadable a few years later (iso.org). For an archive that must stay consultable issue after issue, that is the guarantee that today’s PDF will still open in ten years.

The third is the interaction layer: article comments, a contact form to the newsroom, moderation. The risk here is not technical but operational: open comments on a trade site attract automated spam from the first indexed day. Without pre-moderation or an approval queue the comment section becomes unreadable within weeks.

The hard part

The hardest problem lies in none of the three components, it lies in cadence. A bimonthly magazine has a slow, predictable publishing rhythm; a portal meant to keep the conversation alive between issues needs a fast, steady one. The two rhythms are in tension, and technology alone does not bring them into agreement.

An easy-to-use CMS lowers the friction of daily publishing, but it does not generate the content. If the print newsroom has neither the time nor the mandate to write for the web as well, the best-designed portal empties out after a few weeks and the RSS feed stops updating — the most visible sign of an abandoned site. The technical part of the project consists in pushing that friction down to the point where publishing on the web costs less than not publishing; everything else is an editorial decision that no stack choice can make on the newsroom’s behalf.

Implications

It follows that the portal’s success metric is not the number of features, it is the update frequency the real newsroom can sustain. The design priorities turn over. It is better to ship fewer features with a publishing flow a non-developer journalist walks through in two minutes than a rich system that asks for a technical step at every issue.

The same holds for the open-source choice. A CMS like Drupal or WordPress is chosen for the widespread skill that surrounds it, not for its zero licence cost: anyone, even another agency, can step in without rebuilding from scratch. For a client that is a public-private body, the portability of maintenance is worth more than any bespoke feature. A portal built on these constraints for the Innov’azione magazine of the Polo Tecnologico di Navacchio is described in the insight published by noze: https://www.noze.it/en/insights/innovation-portal-online/.

Limits

The above describes a portal from 2009 and should be read at that date. The CMSes named are at their then-current versions — Drupal 6, WordPress 2.7 — and many integrations now taken for granted (delegated authentication, public APIs, CDN distribution) are here out of scale or not yet common practice for a site of this size. The syndication and archival choices, by contrast, rest on published standards — RFC 4287, ISO 19005-1 — and outlive the software that serves them. The fragile part of the architecture is not the stack, it is the editorial premise: that there is someone, every week, with something to say between one issue and the next.

https://www.drupal.org/forum/general/news-and-announcements/2008-02-13/drupal-60-released https://wordpress.org/news/2008/12/coltrane/ https://www.ietf.org/rfc/rfc4287.txt https://www.iso.org/standard/38920.html

Cover image: Matt Mullenweg, co-founder of WordPress, speaking at WordCamp Jena (2009) — photo by Sebastian Wallroth, public domain — https://commons.wikimedia.org/wiki/File:MattMullenwegWordCampJena2009_001.jpg