moving the website out of CMSMS

Nate Angell nate.angell at rsmart.com
Tue Nov 17 19:59:09 UTC 2009


One possible advantage to Drupal is it includes jQuery by default.

It's also easy to include custom js/css in Drupal on a per page (what  
Drupal calls a "node") basis.

On Nov 17, 2009, at 11:52 AM, Jonathan Hung wrote:

> I think what we choose will depend largely on what we want to  
> accomplish.
>
> If we're looking to build custom features, deliver a lot of content,  
> and desire a lot of control over the presentation, then Drupal may  
> be a good choice.  (If we're ambitious and have the resources,  
> Drupal would be an excellent choice to bring together the Wiki, and  
> Jira into a cohesive location.)
>
> If we're looking for collaboration, then MediaWiki may be a good  
> route?
>
> But if we're wanting something simple to get the message across,  
> then a slightly modified Wordpress is effective.
>
>
> But my question is: What are we trying to accomplish through the  
> website? The answer may help us decide what we do next.
>
> - Jonathan.
>
> ---
> Jonathan Hung / jhung.utoronto at gmail.com
> Fluid Project - ATRC at University of Toronto
> Tel: (416) 946-3002
>
>
> On Tue, Nov 17, 2009 at 2:32 PM, Jacob Farber <jacob.farber at utoronto.ca 
> > 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 utoronto.ca 
> > 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: http://issues.fluidproject.org/browse/FLUID-3355
>
> 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 fluidproject.org
> To unsubscribe, change settings or access archives,
> see http://fluidproject.org/mailman/listinfo/fluid-work
>
>
>
>
> -- 
> Jacob Farber
> University of Toronto - ATRC
> Tel: (416) 946-3002
> www.fluidproject.org
>
> _______________________________________________________
> fluid-work mailing list - fluid-work at fluidproject.org
> To unsubscribe, change settings or access archives,
> see http://fluidproject.org/mailman/listinfo/fluid-work
>
>
> _______________________________________________________
> fluid-work mailing list - fluid-work at fluidproject.org
> To unsubscribe, change settings or access archives,
> see http://fluidproject.org/mailman/listinfo/fluid-work

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20091117/7ef9aee9/attachment.html>


More information about the fluid-work mailing list