[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On Saturday 06 September 2008 21:39, Simon Williams wrote: > Simon Avery wrote: > > I don't know of a guide, but I've found the same problem you have. Too > > bloggy and difficult to make it look like anything else. > > > > Drupal sites are intrinsically drupally, I think. Not > > nececessarily a bad thing unless you're trying not to look like a drupal > > site and if you're doing that, you have to wonder why you're using > > drupal... > > > > One tip when considering - are there tools to convert your CMS data to > > another CMS? Can end up quite important if you decide after a few months > > that it's not what you wanted after all. > > Considering that all the CMSes have very different database structures I > highly doubt that it is possible to convert any of them to anything else > unless you write your own (or do it by hand). > > I've actually started writing my own filebased system. Maybe it's a bit > pointless, as there are other filebased systems around, but I don't like > those either. nanoCMS, microCMS and razorCMS looked promising (I think > they're all forks of each other actually), but they're still too much > code for my liking. For some reason, when it comes to web coding I just > don't trust anyone. I think there are 2 reasons for this: > 1. They are usually difficult to read monolithic lumps of code with no > API or other documentation. > 2. They have to stand up to more attacks, and yet have a reputation for > not being secure. > > The irony is that my own system will probably be worse on both counts > above! Though that's given me an idea- maybe I should write it like a > software library with a good API and get the web designer to make use of it > like a library rather than control everything like most CMSes. > > That's mainly the reason I'm writing my own I guess- I want something > that is a simple as possible and stays out of the way of the web > developer, requiring very simple function calls, whilst allowing > less-savvy users to edit the content. > > One slight issue I haven't decided how to fix is extra parameters. Do I > embed the parameters in the html file in some way, hoping that wysiwig > editors are smart enough to leave them alone (maybe this is what the > META tag is for?)? Or do I store them somewhere else (this somewhat > defeats the object)? > > Any thoughts? Now you've done it... API ise it as much as possible. Security API so you can change security method: ie at 'development' level you have a simple set of ACL's that provide you with Create Read Edit Delete capabilities for files/directory structures so people can 'upgrade' to LDAP or whatever without having to rebuild their whole web. API for the CMS allowing external program to do the same, and to scan contents looking for links/images running tidy etc - oh and for putting into an external VCS like subversion as for the editor I've always thought http://www.fckeditor.net/ was cool - you can configure the menubar and styles to stop people getting too pointlessly complicated and you can simply check whether a user is allowed to edit a file and if so pop up an edit button for them- no messing with other HTML editors just a web front end. And make sure you've got a push through for those with permission on 'select a bit of text' make link to a new page. I'd better stop now... though if your going php I might get involved - but I'm bloody minded.... Tom te tom te tom -- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/linux_adm/list-faq.html