moving the website out of CMSMS
Laurel A. Williams
laurel.williams at utoronto.ca
Wed Nov 18 15:57:33 UTC 2009
One of the key reasons to use a CMS is because it allows us to permit
greater numbers of people to contribute to the website, and provides
control access for users based on roles. It allows people who aren't all
that familiar with HTML, css, etc. to contribute to the website without
a huge learning curve. At the moment, we do not have numerous people
contributing to our website and we do not take advantage of the roles
available in CMSMS at all. Basically we just use the CMS as a website
framework to provide the elements I mentioned in my email - common code
blocks, rss feed, menu display, news, etc. Previously, we may have had
community members who kept the website text up to date, etc. who weren't
all that html saavy, but that isn't the case right now.
It isn't clear to me that we need the capabilities of a CMS for the
fluidproject website, based on its current use. Allowing lots of people
to edit the website doesn't seem to be one of our requirements at this
time. It would be nice, however, if the people who do edit the website,
could do so without the constraints of using a CMS, unless there is a
good reason to do so. I haven't thought of one yet, but others may have
I'll address some of Colin's points inline tomorrow.
> * Laurel, can you elaborate more on this problem with CMSMS requiring
> CSS to live inside the database? Are you saying that we can't just
> link to static CSS files on the Web server?
Yes, you can link to static css elsewhere. CMSMS has a technique for
editing "templates" (basic html common to each page) and attaching css
which stores the html markup and the css in the database. You can
minimize the use of these techniques using tactics like linking to
static css, but then, why would you bother using the CMS if you wanted
to do this? Why not just use something else?!
> * Custom content types and feeds: it seems to me that we don't have
> much need for strongly typed notions of content. Many content
> management systems enable custom types to have first-class status
> within the system, for example articles or calendar events. So far,
> our site is generally simpler and more Webbish. Most of our content
> consists of HTML, CSS, and media such as video, audio, and images. We
> want to be able to more easily link in dynamic content as needed, and
> ensure that we don't ever have to cut and paste markup, CSS, or code.
Exactly my point. We aren't really using the tools. Is this because our
website requirements do not include these tools, or is it because CMSMS
doesn't do it well? I suspect it is the first option.
> * In the past, we had one RSS feed consisting of news articles managed
> by CMSMS. An upgrade to their News module caused the feed's URL to
> break permanently, something that is unacceptable for any incremental
> version update. Upon reflection, we realized that we are probably
> better off to use our WordPress blog for RSS feeds anyway, rather than
> to have multiple feeds. So that simplifies things a bit.
> management system really comes down to what we need and how we use it.
> If we don't need access controls, news feeds, or other custom types,
> what sorts of advantages might CMSMS or Drupal or other system provide
> for us? Is it really the case that we just need something that can
> attach headers and footers to our pages for us? Or do we need more?
> * Performance and simplicity are probably essentials for a public Web
> site. If we see a surge of interest or popularity, it would be great
> to withstand a Slashdotting if necessary. Our community should be able
> to easily and naturally update content. Static HTML, PHP, or
> (arguably) super-simple JS are advantageous in this respect. That
> said, if we find ourselves having to roll custom code that we could
> otherwise reuse in a CMS, then we need something more robust.
> What do you think? Let's keep this conversation going!
I guess I don't want to repeat myself much more but I would love to hear
what others think!
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 269 bytes
Desc: not available
More information about the fluid-work