moving the website out of CMSMS
jhung.utoronto at gmail.com
Tue Nov 17 19:52:14 UTC 2009
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
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 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?
> 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:
>> 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
>> 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:
>> 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.
>> 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
> 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...
More information about the fluid-work