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 <[email protected]> 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 / [email protected]
Fluid Project - ATRC at University of Toronto
Tel: (416) 946-3002
On Tue, Nov 17, 2009 at 2:32 PM, Jacob Farber <[email protected]
> 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 <[email protected]
> 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 - [email protected]
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 - [email protected]
To unsubscribe, change settings or access archives,
see http://fluidproject.org/mailman/listinfo/fluid-work
_______________________________________________________
fluid-work mailing list - [email protected]
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 - [email protected]
To unsubscribe, change settings or access archives,
see http://fluidproject.org/mailman/listinfo/fluid-work
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://fluidproject.org/mailman/listinfo/fluid-work
