Why not become a lifetime supporting member of the site with a one-time donation of any amount? Your donation entitles you to a ton of additional benefits, including access to exclusive discounts and downloads, the ability to enter monthly free software drawings, and a single non-expiring license key for all of our programs.

You must sign up here before you can post and access some areas of the site. Registration is totally free and confidential.

Abstract:Available content management systems don't quite deserve the name, I think. They manage the styling of a site. They manage a database of articles. They can adorn a site with cool little widgets like menus, polls, galleries, banners, trackbacks, blogrolls, tabs, sliders and carts... that is, all the stuff that happens around the content, and in addition to it. They manage the layout, too - but again, only of those outer encrustations, not the layout of individual pieces of content. In fact, CMS-es seem to manage all aspects of a site *except* for the content. So what do you do when it is your content that needs some management?

I have changed the title of this post by Mouser's entirely reasonable request. So here's how to...

I can't believe I'm so different from everyone else on the planet that there is no CMS made just for my needs. And yet there isn't, which makes me think there's a big, BIG niche to fill, because I cannot possibly be the only one. (One would hope!) Before I say why I think this would fly and why it would sell, here's what the Better CMS would be like: modular. Modular on the level of text.

Most CMS-es are modular in the sense they let you pick and choose from available modules (the terms vary) that provide some functionality: a calendar, an ad banner, a photo gallery, a poll, etc. You can typically place these modules on sidebars, headers, footers etc., i.e. all around the core content of the site. But the content itself is not modular. And there's the rub.

I may be wrong, but CMS-es seem to have grown out of blogs. In some cases (WordPress) the demarcation between a blog and a CMS has become quite fuzzy. And at the risk of being totally wrong again, many of the big names in CMS world today (Joomla) may have actually started out as blogs. (Except TextPattern, which claims to be a CMS even before it has become a proper blog.) In any case, almost every CMS I have tried seems to be a "blog plus" - start with a blog, then add stuff to it. If you read the support forums, invariably one of the FAQs is How do I create a static page? Ah, because static pages were usually added as an afterthought, and don't necessarily fit in the overall scheme of things.(1)

If CMS-es are indeed bloggy by nature, this would explain why their "modularity" happens all around the content - the posts, the articles - but does not touch the content at all. It's the "blog plus" mentality: you write the blog, and we'll provide oodles of little gizmos you can put all around it.

And while I'm sure there are orders of magnitude more bloggers that software authors on the planet, that's still a huge population. And they need something completely different. Something you cannot quite do with a gizmo-encrusted blog. I'd say they need modularity of content.

If you are selling (or giving away) only one product, you worry little about consistency. Just use a nice theme to make sure all pages have the same background color. But the moment you have two products or more, consistency in layout and design becomes a concern. Each product is going to have roughly the same set of pages: one for description, one for feature list, one for screenshots, another for download links, for support options, and maybe for payment. You want all these pages to have the same look and the same structure.

Try to achieve that by typing, or even pasting text in a WYSIWYG editor. Or even in a code editor. Not recommended, especially if your temper runs short. And certainly not recommended if you have other pressing priorities, like adding features to your software, fixing bugs, responding to support email or finding nicer-looking icons for the toolbar. (Or, God forbid, dealing with chargebacks.)

So a Better CMS should be based on templates, understood as forms to fill out with content. That way every page looks the same, and you can change the structure of all your "Download" pages just by editing a single template. That's one level of modularity, but we've barely scratched the surface.

A lot of your product pages will contain the same content. Maybe you want to put a warning, This app requires Windows 13, on every page. Or a link to support, or a Buy one, get one free button. That's text, or an image, plus some formatting. A block of content that you want to reuse on multiple pages - that is, in multiple templates.

A template, thus, should consist of blocks. Named pieces of text that you could arrange. This is nothing new - every site design allows for things like {header} {body} and {footer}. The problem with today's CMS-es is that they don't let you do that inside the {body}. Also, {header} and {footer} are not granular enough. These sections will consist of reusable blocks, too. So that's another level of modularity.

There is one more level to cover: that of text itself. It's easy to imagine what happens when you release a new version of your app: you have to update the documentation. All of it. Consistently. Change the version number in the app, in the readme file, in the help file, in the PAD file, in your DonationCoder thread, and everywhere on your website. It's not all easily automated (there are partial solutions), but it should be completely automatic on the web-side at least.

Ideally, things like the version number and release date should be placed on every page for your product, so that they're easy to find. In Joomla or WordPress, that pretty much means revisiting all those pages and changing the number and date in each article, making sure you don't screw up the surrounding content. And what happens if you decide to change your copyright string, or the name of a product? Isn't this one reason computers were invented in the first place?

What we need then is text substitution. The site is built from templates to ensure all pages look the same, but all pages do not have the same content. They differ: one page says "Download SuperFreeEditor 2.0", another says "Download SuperFreeEditor Pro 3.5". We have to have a dictionary, one for each product, that basically says "app-name=SuperFreeEditor", "app-ver=2.0" for one product, and for another product a dictionary that says "app-name=SuperFreeEditor Pro", "app-ver=3.5". Then your template for the download page contains simply "Download {app-name} {app-version}".

There would be a "product" manager, where you would add the information specific to each product. That information would then be used to fill out the templates and generate pages. And presto, a CMS based on the time-tested DRY principle. You only enter the app name once, in one place. Likewise the version number. And if you have a specific important note that you want to plaster on every page for that app you simply add {BIG-HONKING-WARNING} to a section of a template. It's not complex or strange or anything. It should be the fundamental concept of a CMS, as long as you really want to manage content, rather than just manage the links on the page.

Oh, and let's not forget links. Take Joomla. Every article lives in a database and has a unique ID. But if, in the editor, you want to put a link to another article on the same site, you can either manually look up the article's URL, or use the awkward selector (where it's always easy to pick the wrong article by mistake). And if you ever move pages around, all your existing links will be dead. If you are using "clean" URLs, and one day change the title of an article, all your existing links to the article will be dead. Or, and this is particularly amusing, if you have two articles named "Screenshots" on your site (for two different apps, right?), links in the menu will all point to only one of the two. Unless you manually fix it, giving each article a unique slug.

So there should be two ways of linking. One, by the database ID of an article. It will never change. The link can only go dead if you delete the page. But a better solution is to borrow from wikis and add some smarts. Say you are on the main description page, and want to link to a "Features" page. With all the information the CMS already has, it should be enough to type {link:Features}. Not even {link:SuperFreeEditor:Features}, no. Because the CMS already knows the current page is part of the "SuperFreeEditor" section of the site. And as long as you have a page with the internal name "Features" (this might be the name of the template on which the page is based), the CMS has enough information to construct the right link. OMG, it's so simple! Where can I get it?

Nowhere. Nowhere I've looked, at least.(2)

Now, if you still want all the gizmos, knock yourself out. And there should certainly be a blog. And in the blog, I should still be able to say "Hey, I've just released a fantastic new version of {app-name}! {link:Download}Go get it!{/link}" See my point?

A nagging feeling is telling me all I've written above is trite. Captain Obvious stuff. The more puzzling to me is that this thing doesn't seem to exist.

Now, why would this thing sell? Two reasons: because programmers already have their hands full doing all the stuff I mentioned above and more. And if they can spend thousands of dollars on the latest compilers and libraries, they will happily buy a $99 CMS if it saves them weeks and months of grief. A shareware vendor building their own website from scratch is like a shopkeeper doing their own masonry. Some do, but it's not for everyone.

Reason number two, this could work for almost anyone distributing almost any kind of product, not just software. Just make sure the fields in the database are user-defined, not hard-coded to be "app-name" and "app-version" only. Sure, Amazon won't buy it from you, but plenty of one-man, one-woman shops will. I will!

To be continued, I'm afraid.

(1) To put in a good word for Joomla, they got the static page part right.

(2) TextPattern has "forms", which are a little like my "blocks", but that's far from enough.

Seriously now, how hard would it be to write a skeleton implementation of this in php/mysql, or php with flat files? Maybe even it could piggyback on an existing CMS - after all, it only deals with what's inside of the articles, while CMS-es only deal with what outside of them.

Once again, tranglos, you touch upon a subject I have come across without actually bringing it up for discussion. I went through this thing when I was first setting up my website here at DC. i am not a programmer, so I wanted a way to do exactly what you have said above: a pre-packaged template that i can tweak a little for my own needs. From the start, I absolutely did NOT want the website to be a blog, and if you go through my thread, you will see how I struggled with that for quite a while:http://www.donationcoder....m/index.php?topic=14095.0

Eventually, I used wordpress and a special theme (the style is called "magazine-style" themes) so that it wouldn't look like a blog. I didn't want a blog because the chronology of my content was of no concern to me. So, eventually, I had to use a blog platform (wordpress) and do it in a way where even though it is technically a blog, it doesn't feel like one. however, the problem of chronology still remains, there is no escaping it without a lot of tricks and workarounds, which inevitably break the wordpress backbone eventually. So, in the end, I gave in somewhat to the chronological aspect, but tried to mask it as much as possible visually.

I completely agree with everything you said. you're right, something like this does not exist, at least not when I tried to find it. My situation is the same as yours, except instead of software, my content is made up of articles.

I completely agree with everything you said. you're right, something like this does not exist, at least not when I tried to find it. My situation is the same as yours, except instead of software, my content is made up of articles.

I'm seriously hoping for some takers for the community project. (Wasn't there an idea like that floated around when Mouser posted the DC questionnaire?) I'd put all my heart into it, I would learn PHP to contribute (takers beware: newbie php-er), and I would certainly use it from day one.

I was happy enough with just plain old html, but now I've had it with updating little bits of data scattered around the site all the time. And with the copy/paste process when I want to add a new page. Forget about a redesign! I no longer have that kind of eager patience

CMS-es are great for adding new pages. Problems begin when you want the content of the pages to be structured in some way.

I may have misunderstood completely and if so it is my fault completely as well. But a lot of what I read here can be and is achieved by using smarty and is implemented by some CMSes, may be not as thoroughly as described but not too far off either.For example reusing and controlling content is one of the strengths of smarty.

I may have misunderstood completely and if so it is my fault completely as well. But a lot of what I read here can be and is achieved by using smarty and is implemented by some CMSes, may be not as thoroughly as described but not too far off either.For example reusing and controlling content is one of the strengths of smarty.

I think smarty does what I've described - at least much of it. But I can only read PHP code, up to a point. I cannot write PHP, and I am thoroughly scared of security issues at every step, so I haven't really considered writing such a framework myself. And not every CMS lets you put php in posts. TextPattern does; Joomla - I don't think so. (I'll have to find out, but haven't seen an indication that it does.)

My hypothetial project would be a fully-fledged CMS, rather than just a templating framework. But you are right, smarty could be a good starting point for writing a custom solution.

In the flow of writing the verbiage at the top I forgot to add that I have actually implemented all of the ideas - in Delphi Now, this doesn't make a lot of sense, since I would have to generate the complete site on the desktop side, then upload the static html pages, and repeat the process for every update. But as a framework it certainly works.

It actually does more than what I described, because I wanted to use it not just for websites, but to generate content like readme files and xml files as well. It has variable substitution everywhere, and definitions can be nested. It has functions, e.g. to return and format dates, where all function parameters (like the format for the date or the date value) are also string variables, so that you can define the date or its format once, and use it everywhere you call a date function. (Think of displaying release date for a program in several places on a site, and having all dates use the same format, which you have to specify only once.)

You can put the result of a function in a variable and reuse it. Practically everything can be "expanded" in this way, i.e. every piece of generated text can be a dictionary term, with nested expansions inside it.

It has smart entities dependent on output format, so that an "&" will produce an html entity &amp; if you're outputting html, or just the ampersand character if you're outputting text. It has namespaces to implement the concept of separate "projects" that share the same templates but yield different productions. And the templating code can be put in any text format, be it html, php, xml or html,etc. It has includes, which can be recursively parsed or passed through raw. I loved writing it.

One thing it does not have is conditionals and loops, because I'm not smart enough to write a compiler. But it can pretty much do without.

In the flow of writing the verbiage at the top I forgot to add that I have actually implemented all of the ideas - in Delphi Now, this doesn't make a lot of sense, since I would have to generate the complete site on the desktop side, then upload the static html pages, and repeat the process for every update. But as a framework it certainly works.

What about writing the CMS in Delphi, as ASP or ASP.net? Then you wouldn't have to run it on your desktop to generate static pages. All you'd need is a server running Windows.

As a sort of reference to perhaps look at CMS made simple does a good job at PHP use in content, uses smarty and has some of the other advantages, but yes I understand what you mean as far as making a fully fledged CMS and dealing with security issues.What are the chances of being able to look at your Delphi implementation?

What are the chances of being able to look at your Delphi implementation?

Right now, not much, since it's all a bunch of tests to make sure the logic works. There's no UI, and I have yet to write an interpreter for the project files, which will pull together all the content. So there isn't much to look at yet, but this is the result of a successful test:

And this is an example dictionary, using term definitions (t), expansions (x), a function (f) with parameters (p) , includes (i) - and entities too, but they're not in this clip:

The syntax is verbose, but nesting gives it flexibility, and Verbosity is my middle name, I'm sure

The biggest problem I can see with that is that it might not be "blog" enough. (No post to e-mail like Posterous, no tags for articles, too much clutter to make the article be the focus)and still not be CMS enough. (supports template but you're still restricted to a lack of choice outside of default, more flexible but still doesn't focus on content management.)

Logged

<reserve space for the day DC can auto-generate your signature from your personal PopUp Wisdom quotes>

I think that is probably as far away from what he is talking about as you can get. That's for social networking, not e-commerce. Quite unsuitable for anyone that wants to set up a website to showcase and sell their products.

That works if what you are publishing is conceptually a blog. It may be a serious and well-designed news site, but it's still a blog by heart. (Apparently most of my favorites run on Drupal, and there are some great-looking ones based on WordPress.) Recognize them by the URLs like www.site.com/2009/9/23/why-things-suck-the-way-they-are. That's a blog.

Wordpress doesn't do that by default. The site owner has to set it that way. All my pages in my book directory do not indicate anything hinting at the date in which they were posted. Not in the url or on the pages themselves. This is something I didn't want, so I never changed it from the default and I don't have any code in my template to insert the date onto the pages themselves. (my template didn't come with it and if it did I would have ripped it out)

True, app. You can have the link addresses however you want. But it doesn't change the fact that wordpress is fundamentally structered around a chronological system. And to do otherwise means you have utilize a lot of tweaks and workarounds that essentially fight against the nature of wordpress (e.g. using static pages as your main content vs. using posts). So while wordpress is flexible enough where these things can be accomplished to some degree, it's not in the nature of the application.

And that's what tranglos is talking about (I think). He's asking for a platform which is INTENDED for creating a website to organize a bunch of 'things' in a flexible, yet facilitated manner like wordpress does for blogs. I'm onboard with the idea, in case you couldn't tell.

Are these examples of the type of site you are looking to build?They are all using the same CMS.

Hi App! The links to the /wp-content folder are dead giveaways Yes, these sites are good examples, just like most shareware sites are. I know you can do that in WordPress. The fledgling site for my wife's company has just been done in WordPress, too. (There's still a bug preventing the menu on the right sidebar from working properly. Another phonecall to make, sigh!).

I wonder what the admin interface looks like at the sites you mention, though. How much fun (or how much of the opposite experience) they have updating the product info. WordPress is very flexible in what it is designed for, but when used to make a site like my wife's, suddenly there's a lot of things we can't touch or else they will break. There are four sections on the English version of the front page, one for each type of service (i.e., a product) - but their ordering is wrong. And there is no way to change the order other than (a) copy and paste between posts, or (b) go into the database directly and change the dates on the posts, which will affect the way they sort. That's a good example of something that works, but isn't the best tool for the job.

One other thing I've noticed is how many of the fanastically popular shareware sites (e.g. TocalCommander, but a great number of them really) are not CMS-based. Some are, and very professionally done (Ultraedit), but these are likely 100% custom jobs that must have cost a good deal. Most are plain html, with all the attendant inconveniences.

What about writing the CMS in Delphi, as ASP or ASP.net? Then you wouldn't have to run it on your desktop to generate static pages. All you'd need is a server running Windows.

Yeah, that's an option too, but I don't know any more about asp than about php. I'd rather stick to apache/php/mysql, even though my provider (Dreamhost) does support asp in some way although they're a linux shop. it's all black magic to me either way

Thanks for the link SKA, i have used treepad in the past (though not for website generation), and it's an impression program. It's doing a similar thing to what I want, but I'd be interested in something a little more scriptable and that working by analyzing different files in a directory tree that might have all kind of extra information to guide how the site is constructed and what menus are shown.

My interest has always been on a tool that would take a directory tree of flat files and make a website out of them.

Mouse, isn't this pretty much what DokuWiki does? It uses flat files, and when you arrange files in a folder structure, the folders are known as "namespaces" - but the difference is in name only.

One thing missing is that DokuWiki won't automagically generate a (sidebar) menu for the files. There is a sidebar plugin, but you have to code the menu manually, so it's time-consuming and the menu will not, for example, highlight the currently active item. (On the plus side, the plugin can display a different sidebar for each namespace). I don't have a clear understanding of the domain (not just php syntax, but how you use it to pull and display pages), so I can't say how much work it would be to add a dynamic menu to Doku, but maybe not that much.

I considered Doku, because it's very neatly structured and well documented. The lack of a dynamic menu is a showstopper for me though. Plus it would be a chore to convert all my html content into wiki-ese, especially that Doku's internal formatting capabilities are limited. So much so there are plugins for everything - there's even a plugin to produce a non-breaking space, because Doku can't do that natively. (You *can* include raw html and php though if you want; it's just that having to type <html>&nbsp;</html> is a little nasty.)

but it isn't quite what i had in mind for the task we are talking about, mainly for the reasons you mention.

my interest in the discussion on the other page, and related to what you are talking about here, was a way to make a website out of a tree of flat files, where subdirectories and files might have hints about how to treat them when building the site. things like automatic site navigation menus would be essential, as would building a kind of download page with thumbnail images, etc. being able to do wiki-like editing online was not something i considered.

ps. i understand the topic of the thread was meant to emphasize a point, but this is one of these cases where it makes it harder for people to find things when searching -- how about renaming the thread to something more relevant to the discussion?