moving the website out of CMSMS

E.J. Zufelt everett at
Tue Nov 17 19:51:29 UTC 2009

Good afternoon,

I've been out of the Fluid loop for a little while, but wanted to  
chime in on this issue.  I am hoping that the criteria for assessing  
any particular CMS for the site will include an assessment of the  
accessibility of the CMS.  This is not only important from a content  
consumption, but also from a content creation perspective.  It would  
be disappointing if a CMS were selected with poorly accessible  
authoring capabilities, as it may make it more difficult for persons  
with certain disabilities to contribute to the project.


Follow me on Twitter

View my LinkedIn Profile

On 17-Nov-09, at 2:32 PM, Jacob Farber wrote:

> Is there a reason we're only thinking in terms of CMSMS or not  
> CMSMS? What about other, more powerful cms's?
> Jacob
> 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
> _______________________________________________________
> fluid-work mailing list - fluid-work at
> To unsubscribe, change settings or access archives,
> see

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the fluid-work mailing list