moving the website out of CMSMS

nate.angell at rsmart.com nate.angell at rsmart.com
Thu Nov 19 05:20:20 UTC 2009


FYI: One of the best spam-protection, comment moderation tools out  
there is Mollom, which integrates with wordpress and drupal, among  
others.

On Nov 18, 2009, at 9:08 PM, Eli Cochran <eli at media.berkeley.edu> wrote:

> I don't know how useful this information is, but... I learned this  
> afternoon that the jQuery web site is going to move from a MediaWiki  
> based site to Word Press. The jQuery team claims the primary reason  
> is to manage comment spam while allowing for a greater level of  
> community involvement in their documentation. Apparently they felt  
> that the moderation tools in WordPress provided them what they need.
>
> - Eli
>
> 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
>
> . . 
>  .  
> . . 
>  .  
> . . 
>  .  
> . . 
>   .  .   .    .      .         .              .                     .
>
> Eli Cochran
> user interaction developer
> ETS, UC Berkeley
>
>
> _______________________________________________________
> 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/20091118/adb25bdd/attachment.html>


More information about the fluid-work mailing list