• There are only two Drupal versions supported at a time. As Drupal 7 has been out for some time, Drupal 5 is no longer supported. That means no security updates and potential compatability issues. (For example, Drupal 5 will not run on PHP newer than that version 5.2.x.)
• While there is nothing that says an old custom module cannot be maintained, they tend not to be. Lack of core fixes is part of that and another is that improvements may take advantage of core features or other modules that don't exist in an older version.

My "disaster" was that my Drupal-5 based site was running on shared hosting. One morning, at about 5AM, the hosting company decided it was using too much in the way of resources and turned it off. They didn't tell us until 2 hours later -- after I asked for help trying to figure out why it was down. (I am pretty hacked off about this as the site traffic had been pretty stable for at least the last year.)

In any case, I needed a quick fix. I had another shared hosting account. While I knew it wasn't the right long-term solution, it was the quick fix. I moved it, got DNS pointed, ... Got bit by the default PHP 5.3.x issue. Fixed that. Now, they "automatically" decide if you are using too much in the way of resources and turn off your database connection "for a while". The result is regularly broken tables. It also means attempting to move the site pretty much guarantees it goes down because of all the accesses for the dump.

Right now, all the image galleries are broken as a result of getting automatically shut down during an upgrade. Now, most of this is not a Drupal issue but it's reality. In the mean time, we had been looking at how to get to Drupal 7. Looking for over a year. Ignoring the migration issue (migration tools only handle going up one major release and we need to go two) Drupal 7 has some serious changes which make our current photo gallery approach not work. So, we remain in limbo with a limping site.

I mentioned the "too many choices" issue for modules. Here is an example. There are (at least) two different modules to add WYSIWYG editing to Drupal. One supports a specific editor, the other supports about six editors. For a site I am working on (that will probbly become a Cotonti site instead of Drupal), I picked the first one, figuring it was more likely to "work right". There are problems. So, I need to try out two modules and six editors to find something that works right. A clear issue of too much choice is not a good thing.

Will Drupal 5/6 users find sufficient modules/plugins here?

Some will, some won't. My (now ex-) company and I have used Drupal for lots of things for ages. I have/we have also developed web sites back when you wrote HTML by hand (I even wrote one interactive site using awk) and have friends who seem to think Drupal is the solution for everything. I just wanted to say that up front so you get an idea where I am coming from.

Historically, Drupal 4 didn't do all that much fancy stuff which really started the huge "add a module" campaign. It was not uncommon for multiple modules to be introduced, by different people, to address a need. Some modules were just written to address one user's needs. As a Drupal 7 module is generally very different from a Drupal 4.7/5/6 module, folks in that boat are going to be re-writing anyway.

Those who picked more general-purpose modules (and I fall into the category with a couple of sites) picked wrong. That is, there were multiple choices (photo galleries is one common example) and pretty much whatever you picked was wrong because there is no such animal in Drupal 7 yet and what is getting designed is not a plug-in replacement. (I can explain this case in detail if anyone cares but it is really a significant design change that does more than just break backward compatability.)

There are lots of Drupal sites I know of which consist of some static pages, forums and, maybe, multi-user blogs. And not much more. For others, add photo galleries and tags and you have everything covered. As photo galleries and blogs are the most requested features here, having them should make cotonti a possible new home for people wanting something new.

I have three "more than trivial" sites running Drupal. All need some upgrades and Drupal is probably not the right solution for at least two of them.

• The most active is still running Drupal 5 and we have some serious issues. (It is seriously broken right now because of some hosting issues which has turned a "move when D7 does what we want" into a "gotta fix it now" issue. It is not a candidate for moving to cotonti because it has what Drupal calls books, a hierarchical set of pages which make up a lot of the site. Othen than that feature, cotonti with photo galleries and blogs would be a possible choice. (Today, ocportal feels like the best fit.)
• Another site is little more than a personal blog with comments running on Drupal 6. It also has a (not well maintained) set of web links. While it doesn't need to be updated, it would be an easy fit into cotonti. I did it in Drupal because, at the time, I was doing everything in Drupal. From others I know, this was not an uncommon approach.
• The third site started mostly as an experiment to test out some Drupal 7 features. It has a plan and a bit of content but, based on issues with Drupal 7, I am looking for a better platform. It is/will be a bunch of semi-static pages organized into at least what looks like a few hierarchies, forums and a glossary. Other than the glossary, which should be easy to implement, this would seem to be a good fit for cotonti.

I think what I have described is pretty typical. That is, people used Drupal to do something (which may of may not have needed some fancy stuff) and when they needed another site, they used the same tool. In general, this should have been the right approach. Unfortunately, so many D4/5/6 modules now leading to a dead end has made this an unwise decision.

Note that I a not trying to trash Drupal. Dries has done something pretty amazing and the big changes in Drupal 7 are going to be a good thing. The audience I am suggesting for conversion are those who got caught in this big change.

drupal

...

I just want to toss in that there are a lot of people who are "stuck" with two Drupal-related situations right now:

• There are a lot of sites still running the now unsupported Drupal 5 and there is no direct way to get from Drupal 5 to Drupal 7.
• Drupal 7 is a very different animal. The good news is that it is a serious cleanup of a lot of old ideas patched to come close to working better. Unfortunately for Drupal 5 and 6 users, a move to Drupal 7 is at least painful and, for many, close to impossible. So much Drupal functionality is in modules. In Drupal 7, a popular set of modules has been moved into the core but thousands of users who happened to pick what seemed like a popular module ages ago are finding out they have a huge conversion task in front of them.

That's a long way of saying that a Drupal 5 and 6 importer could get a lot of these folks moving to Cotonti.

@ GHengeveld - of course, I'm very interested :)

ORM
Makes storing data in the database a lot easier by automatically handling the data validation and retrieval.

REST
Helps to create clean URLs for your data resources. Mostly useful if you want to output data in XML or JSON rather than HTML.

MVC
Allows object-oriented module development. Adds structure to your module code and makes implementation of the ORM even more straightforward.

While Factory is still under development (currently as a joint effort by Trustmaster and me), we'd like to have some users to try and test it. Please let us know if you're interested in developing a module using Factory. Note that it's not meant for plugins and it requires PHP5.3 installed on the server (I can help you with that if you really need it).

I'm not sure if it has been mentioned, but I would love the ability to look at, download and use available modules, plugins and themes from the admin section, like Wordpress.

https://github.com/Cotonti/Cotonti/issues/760

I'm not sure if it has been mentioned, but I would love the ability to look at, download and use available modules, plugins and themes from the admin section, like Wordpress.

https://github.com/Cotonti/Cotonti/issues/760

Now in Genoa it's partially solved by a plugin "Blogs" (and it's buggy), but I think it's a neccessity for a CMS/CMF like that to enable creation of categories from frontend.

Every container category would have to have some additional settings, like e.g.
- optional limit of "one subcategory per user",
- optional "user gets administrative rights per category created",

... and a feature that detects duplicate category names would be needed.

Today I've fixed the extension type filter on the extensions page. It's not really useful yet because there aren't any modules in there. I'll add my Find module soon so there will at least be one in there. Hopefully many will follow. It's possible we will put the modules that come with Cotonti by default in there too.

I have a few suggestions; although they are not directly related to the official cotonti package more-so to cotonti.com.

• Seperate extensions/themes for each branch of cotonti (i.e. have a section for Siena extensions, and a section for Geona extensions). It can be quite confusing since there is no direct way to tell until you download the extension/theme.

Very true, a new Cotonti user will have no idea about what is compatible and what is not.

• Seperate extensions/themes for each branch of cotonti (i.e. have a section for Siena extensions, and a section for Geona extensions). It can be quite confusing since there is no direct way to tell until you download the extension/theme.
• Adding a "store" would be ideal for extension developers/theme makers to sell some premium content; although, perhaps a list of willing coders would suffice somewhere? Or something to identify this user sells extensions/themes.

The first one has been bothering me recently. It just seems unnecessary to have two branches of extensions mixed in with eachother; when they aren't compatible with each other.

I need cotonti like Lego Blocks)

For ajax)

Like - I delete post -And It will be deleted on page - and in the botton of posts - will appeared next post

No, "everything is an AJAX block" is impossible to implement with Cotonti, at least in 1.x.

For ajax)

Like - I delete post -And It will be deleted on page - and in the botton of posts - will appeared next post

wordpress

joomla

MODx 

TYPO3

DataLife Engine

Steffen

We have already added some features for developers on the list:

• ORM integration
• Structure-driven Views
• RESTful API for web services and mobile development
• Automated tests support

Here are user features we have in our minds so far:

• Centralized extensions repository and online update.
• Bridges to popular bulletin boards and image galleries.

 Please request major features which are very important to have for a competitive CMS/CMF.

• Improved support for mobile devices.