Hi everybody, thanks for good work. I'be also setup a lot of sites on Drupal, the drush utility is the best out there, from my point of view. I'll try to answer some questions on this e-mail. First of all, sometimes we prefer to call Drupal a framework, rather a CMS, or a Framework-CMS. Out of the box Drupal doesn't do much, but once you start configuring, Views, CCK, drush, everything get amazing. It's so flexible that putting a demo site "configured" will be so specific, but sure, maybe it would show more of their capabilities. Anyway, that's a good suggestion to the Drupal Community.
2010/10/7 Christian Lohmaier <[email protected]<lohmaier%[email protected]> > > Hi *, > > as the question "what cms to choose" now comes up more often, I think > it's best to just setup some demo-sites to compare them. > > I'm currently evaluating silverstripe, and so far it seems to be good > enogh: > > Major points any CMS must fulfill: > > * Create static pages > In the past, on the OpenOffice.org website with SourceCast (now named > CEE) we often had the problem of the site going down because of the > amount of requests. A pure php driven site, even with php-accelerators > very likely will put too much load on the server. > I've never put a site with the expected traffic of LibO new site, if aggressive caching + memcached or something + good apache, php and MySQL optimizations it's not, maybe you need will need boost, check this two links: http://www.bestofdrupal.com/boost-static-page-caching-drupal.html http://drupal.org/project/boost * User-Firendly URLs > People want to be able to guess what a link is about. Pointing someone > to http:://example.com/<randomnumber> is bad, better point to > http://example.com/user-faq > Also important for search-engines and the like > This is called URL-rewrite by Drupal. It's in the core. If not enabled URLs look like domain.com/index.php?q=node/210. If enabled but not set the URLs look like domain.com/node/210. If you set a URL manually (functionality in the core/optional/path) or if you use Pathauto module, you URLs can llok whatever you like, for example domain.org/article/datearticle, even you can use Taxonomy (something like categorization). Those will be absolutely necessary: http://drupal.org/project/pathauto <http://drupal.org/project/pathauto>http://drupal.org/project/globalredirect <http://drupal.org/project/globalredirect> http://drupal.org/project/transliteration (because of the i10n) > * Support for Translations > Key pages should be available in multiple languages, the CMS should > support managing those (without having the editor keep the list of > translations in sync, wihout the editor needing to update all > translations with a new link) > Not sure what complex translations needs LibO have, but almost sure Drupal can cover it, check: http://drupal.org/project/i18n > * Support for subsites > As LO is a huge project, with lots of different areas where work is > being done, the CMS should support multiple subsites. (like for > example on OOo the various native-lang projects, the marketing, > distribution, etc. projects, that have different focus and needs) > No problem, the Drupal installation has sites/ folder on his root. The main site is located (if you want to) in sites/default, any other additional subsites (or totally different sites) are located on sites/sitename. This can be set without problem to subdomains and virtualhost on apache. You can share modules between all sites and have site-specific modules. This is done because you have: sites/all/modules (shared modules) sites/all/themes (shared themes) sites/default/modules sites/default/themes sites/subsite1/modules sites/subsite2/themes ....etc Sites can share database or use another one. Authentication can be done easily, OpenID is built-in the core (core/optional/OpenID) or you can use things like LDAP: http://drupal.org/project/ldap_integration. User database table can be share between subsites but this is an advanced thing. * sufficiently sophisticated user-rights system > Not every user should have the possibility to change every aspect on the > site. > Some parts are reserved to be edited by admins, some areas are free to > be messed-around by community members. > No problem I think, Drupal permission system is one of the most advanced and permit more granularity I've seen. You can create roles and give a lot of permissions to that role, even, with CCK, you can specify who can View or Edit a single field. > Specifically, it should support a review/approval workflow. > You can setup a content type that is by default no published, and user role X can not change that, then, role X can publish it. This could be a rudimentary setup. If not enough, you can try things like this one: http://drupal.org/project/workflow. Check out this video about that: http://www.lullabot.com/videos/drupal-actions-and-workflow-video * user friendly editor > Probably not so much of a concern, as many will use the same tinyMCE, > but nevertheless an important topic > http://drupal.org/project/wysiwyg <http://drupal.org/project/wysiwyg>You can use TinyMCE, I don't like it, I prefer CKEditor http://ckeditor.com/ .All this are supported: Editors: CKEditor, FCKeditor, jWysiwyg, markItUp, NicEdit, openWYSIWYG, TinyMCE, Whizzywig, WYMeditor, YUI editor. Those are the basic requirements that come to my mind, now to stuff it > doesn't need to provide: > > * an own wiki > Specialized wiki-software is always superior > Sure, I agree. You can do interesting thing with MediaWiki and Drupal integration: http://www.mediawiki.org/wiki/Extension:DrupalIntegration http://www.mediawiki.org/wiki/Extension:AuthDrupal * own Forum > See wiki > > * random other addition (blog, whatever) > see wiki / we have dedicated planet > > The only drawback of silverstripe I found sofar is user account > creation/validation. > By default the email is not verified by sending a probe, thus a user > can create an account with an email-address that he/she doesn't own. > Only burden is a captcha. This puts a little burden on the > administrators to double check > Drupal can send e-mail for validation if you want to and configured that way. Didn't understand about the burden, sorry my English, but you can use re-captcha or captcha on Drupal: http://drupal.org/project/recaptcha http://drupal.org/project/captcha > I can provide access to a staging installation soon, to check things out. > I'd be happy if someone else could do this for drupal or whatever > other CMS you think should be in the closer choice. > The static sites requirements is considered a hard requirement, no > "but it is fast without" arguments please. To quickly get an idea how > your site performs, use the apache benchmark utility, request a site > 1000 times with concurrency of 5. That can be used as a measure to > compare cached/static vs dynamic performance. > Cheers CC: Felix Delattre -- Carlos Jenkins http://www.cjenkins.net/ http://csl-tec.softwarelibrecr.org/ -- To unsubscribe, e-mail to [email protected] List archives are available at http://www.libreoffice.org/lists/website/ All messages you send to this list will be publicly archived and cannot be deleted.
