Content Management system in STAR

Introduction

This project started in 2005 as a service task aimed to provide a seamless port of the online Web server for document self-maintenance and easy access. The initial description follows. It was motivated by the poor maintenance and log term support of the pages available online and the need for quick page creation for keeping help, instructions and procedures up to date in a multiple user and group environment context. Also, we imagined that shift crew could drop comments on existing pages and hoped for the documentation of our operation to be more interactive and iterative with immediate feedback process. Plone was envisioned at the time but the task was opened to an evaluation based on requirements provided below.

Initial service task

This task would include the evaluation and deployment of the a content management system (CMS) on the online Web server. While most CMS uses a virtual file system, its ability to manage web content through a database is of particular interest. Especially, the approach would allow for a Web automatic mirroring and recovery. We propose the task to include

  • A smooth port of the main page available at http://online.star.bnl.gov/ to the CMS base system. This may include look and feel, color scheme etc ... at minimum, content. For example, the main tools should appear as left menu for easy navigation as a general web template.
  • The evaluation of the database approach should be made and in place before a transition from the old style to a CMS based online web server.
  • The CMS system layout should provide accessible branches for detector sub-systems, each sub-system may manage their branch separately. The branches will be most helpful to keep documentation on the diverse subsystem and provide a remote editable mechanism allowing easy management and modification.
  • Depending on time and experience, the development could be applied to the offline Web server to some extend. An area where it could benefit best is the tutorial area and the QA area. Within the plone system, users would be able to leave comments, add new tutorials etc ... a manager would then organize or make available to the public (flexibility of access to be discussed).

Project timelines and project facts

Facts:

  • We wanted a framework rather than a tool
  • There were more than 762 main stream CMS at the start of the project
  • "best" of today is not the best tomorrow
  • We therefore decided to start the project with a focus on requirements rather than a specific solutions

 Timelines:

  • 2005 – Dmitry Arkhipkin took this & Communicated with Dan Magestro from the beginning
    • The project evolved toward a offline Web server scope rather than a online Web server. The goal was to similarly address the obsolescence of the offline Web server
      • more than 1/2 of the links were dead (65%)
      • most documents were obsolete
      • AFS tree became inextricable and not scaling (strategy to "hold" it together included the creation of separate (AFS volumes for load balancing reasons / ACL became had to maintain)
  • 2006 – Beta (was rapidly used by STAR users) – Version 4.6
  • 2007 – Zbigniew Chajecki (development & integration)

Project requirements

The following requirements were set for the project:

Technical requirements

  • ¡Database storage support
    • Preferably MySQL or  Postgres
    • Any other with a ”driver”
  • Replication
  • Flexible
    • Can be extended by modules or plug-in
    • Programmatic language
  • Modul(ar) design
    • Can reshape look-and-feel Granularity
    • Layout
      • Trees, collaborative work
    • Individual accounts
    • Authorization
      • Privileges and/or ACLs based system
      • Group management (virtual or group based privs)
  • Self-maintained
    • Layouts by sections
    • Link auto-update (page move should auto-update cross-reference)

STAR requirements

  • Easy page creation
    • Web based editor – accessibility from anywhere
    • WYSIWYG editor, What You See Is What You Get - help novice and advanced users. Feature not a mandate (plain HTML allowed)
    • Assisted Help to layout & design
      • i.e. no special html, xhtml, xml knowledge required
  • Support for
    • Attachments, images,  …
    • Auto-update search (i.e. search index and is self maintained withoit the need for external scripts or program)
  • Community (popular) tools supported - may trends corresond to real modern world needs
    • Blogs, Comments
    • Polls, Calendar, Conferences, Meetings …
    • ... many more via modules (a-la-perl extension)
  • Group management
    • PWG, Sub-systems, Activities, …
  • Powerful search (feature rich selector as far as possible)
  • Common visual theme for all pages (auto)
  • Community support (leverage development from a wider base support)

Functional requirements

The following functional requirements were either requested or desired for a smooth (sup)port of previous deployment.

  • Page content must be allowed to be public or require an authentication
  • Meetings/agenda should allow for a non-public sections. Public content should remain to the strict minimal "advertisement" level and not reveal information internal to STAR.
    • (comments? summary? section support?)
  • Talks provided as attachments should not be public (PWG requested)
  • Groups should extent beyond sub-systems and PWG (technical groups, sub-groups)

Related presentation

  • You do not have access to view this node