use Perl

• Hackability (Score:1)

  by Juerd (1796)

  Hackability (includes documentation)
  
  Ease of use (includes documentation)
  
  Scalability (efficient programming. No needless complex and large OO structures for simple templating, for example)
  
  Image management (javascripts to insert the images in the html after uploading)
  
  Almost everything disabled by default (options enabled only when needed, so simple things can stay simple)
  
  Comment fields for internal use (at least one for every type of storage)
  
  Integrated version control and easy backups
  
  A good way to sepa
  • Re:Hackability (Score:1)

    by Juerd (1796)

    I forgot:
    
    Mailinglist interface. If the CMS supports news items, it should also support sending the news to a mailing list.
  • Re:Hackability (Score:1)

    by Beatnik (493)

    What if I provide a very easy way to add both front end handlers (preprocessing certain tags) as back end handlers (adding admin sections) by just allowing module drop-in? :)
    
    Documentation is always a hard part but I already included POD everywhere.
    
    Obscure URL bits.. I use mod_perl handlers, for example to fake real HTML files.
    
    Alternative Interfaces shouldn't be a problem, I barely have any layout data hardcode (except for some form generating).
    
    I'm not sure what you mean by Image Management...
    
    Version C
    • Re:Hackability (Score:1)

      by Juerd (1796)

      Image management ::= the ability for the user to upload an image and have it inserted in the page that is currently being edited, at the location of the text cursor, combined with means of removing images from the server
      
      Comments for internal use ::= comments attached to pages, images, forms, etcetera, used by the people who maintain the site. I include these things with every project, and people always seem to find a use for them :)
• Weelllll..... (Score:1)

  by madprof (4497)

  Flexibility. Power. Simplicity. Think of it like Lego and you'll not go far wrong. Lots of simple building blocks that I can use creatively to make something more complex. No CMS can cope with all situations well though so decide what situation you wish to aim for and stick with it.
• How about what not to do? (Score:1)

  by neuroball (3260)

  Don't do anything that the following three (in reality two) products do: Microsoft CMS, Vignette, Epicentric (now owned by Vignette).

  Don't try to box the developer's / Content Editor's (if existing) in. I.e. Don't allow Content Editor's to write HTML. And if they have to write HTML don't offer any edit boxes that write HTML for them.

  Keep the structure dynamic and allow for a sudden change in design concepts.

  Btw. The above is almost impossible... I konw this because I had to work with all the evil CMSs
• Less is More (Score:2)

  by samtregar (2699)

  Less code, less features, less screens, less stuff users don't need. Just about every CMS I've seen is just too big to ever work right. I say figure out what your users really need, build just that and then stop. If some other users need something a little different, build a plugin interface but for heaven's sake don't just add it to the CMS.

  -sam