moving the website out of CMSMS

Jacob Farber jacob.farber at
Tue Nov 17 19:32:38 UTC 2009

Is there a reason we're only thinking in terms of CMSMS or not CMSMS? What
about other, more powerful cms's?

On Tue, Nov 17, 2009 at 2:11 PM, Laurel A. Williams <
laurel.williams at> wrote:

> Hi all,
> For some time now, we've been discussing moving the website out of CMSMS.
> I'd like to start a discussion of the pros and cons of doing this and also
> talk about some techniques we could use for accomplishing the task if we
> decide to do it. Here is the jira task:
> Advantages that CMSMS gives us:
> 1) The ability to allow various community members to post to the website
> with specific roles such as editor, administrator, and designer. We do not
> take advantage of this ability right now. The only people who edit the
> website all have admin access and there are very few accounts.
> 2) CMSMS allows us to use fixed templates for the header, footer and other
> common code blocks so we don't have to edit and maintain common code blocks
> on each page.
> 3) CMSMS provides some add ons, such as the news pages, breadcrumbs, menu
> generation and rss feeds with very little work. It also provides a
> maintenance mode for when we are doing upgrades (a site down message is
> displayed.
> Disadvantages:
> 1) Being constrained by CMSMS has made editing somewhat onerous for
> experienced web app developers. The CSS is stored in the DB in one place,
> the common code chunks in another, the content for individual pages in
> another place. The interface for editing the pages is not very user friendly
> for people who are used to tweaking html in text editors or using their
> favourite html editing environment.
> 2) CMSMS continues to evolve and updates are tricky. There is always a
> danger of breaking the site when we upgrade and not upgrading puts the
> website at risk for security flaws.
> 3) Having the website in CMSMS does not allow us to version the site or
> revert changes easily.
> So, if we are merely using CMSMS because of advantages 2 and 3, we should
> think about alternative techniques.
> Some thoughts:
> a) We are a javascript focused project - maybe we should use javascript to
> tackle these problems. This could have the advantage of allowing us to
> showcase the Fluid framework on our own website. Colin suggested using
> something like Kettle to manage various includes. Jess also suggested I
> develop a 'menu component'.
> b) I've been doing a lot of PHP lately for the builder. PHP is another
> option. I think its main advantage is that it would be quick to swap over
> the current CMSMS site to PHP.
> I am sure the community has lots of ideas to contribute on this subject, so
> looking forward to your thoughts.
> Laurel
> _______________________________________________________
> fluid-work mailing list - fluid-work at
> To unsubscribe, change settings or access archives,
> see

Jacob Farber
University of Toronto - ATRC
Tel: (416) 946-3002
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the fluid-work mailing list