Speaking of cotonti.com in particular and similar sites, I would prefer Markdown over HTML as it is more simple than bbcode and not so junky as HTML. We can start using markItUp with Markdown for new pages on this site at any time, but all our existing pages are in HTML and cannot be converted to markdown. The same is true for forum posts, except for the bigger problem: we cannot use several types of markup in forums at the same time, all posts must be in the same format. So we can't use markdown on forums.

In forum software like SMF, a registered user is able to choose his prefered editor for composing new messages. This is something I definitely miss in cotonti from the beginning. In most cases I personally don't need a blowed message editor with all possible features, aspecially in forums and comment forms. If I need formating features, bbcode buttons like in the old markitup are good enough or even simple html. And as a blind user, simple text boxes are more accessible to my screen-reading software than complex browser apps, even if ckeditor is accessible in most parts.

As a matter of course this is only my personal opinion, but other users also might have special needs. So instead of one side wide editor I'd like to have my favorite editor selectable in user profile.

Steffen

No, it's different from polls. Polls actually have several templates mixed in 1 file. What we propose here is having 1 template (1 MAIN block) for both adding and editing. Which is less work for coders.

@Macik

Yes, support for pade.add.tpl still should be there if the template exists. But by default it would fall back to page.edit.tpl otherwise.

As for hooks, I think they still should be different because some actions are done when a page is added for the first time but not when editing, and vice versa. But e.g. page.add.tags and page.edit.tags can be merged. In other words, each hook needs individual consideration.

Is there ability to use one function with different TPLs?  I speak about using 2 tpl - one for add and one for edit.

Or some compromise solution to pass TPL path as a parameter, so (when we adding a page) first we can check is there separate «add» template, otherwise use standart «edit» one.

By the way, is this merge consider any «add/edit.first/tags» hooks? Would it be backwards compatible so old plugins still works?

Pros:

• Maintain just page.edit.tpl instead of page.add.tpl and page.edit.tpl.
• Reduces code redundancy.

Cons:

• If you need different sets of fields for adding and editing a page, you need to use IFs in the template or still make 2 different templates for add and edit.

What do you think?

Looks cool anyway, if I decide to buy the commercial licence, I'll try to make a plugin for it :)

I propose to make localization of names of the plugins, as in the description of plugins.

Example (eng → rus)

"Forums" → "Форумы",
"Whos online" → "Кто онлайн?",
"Pages" → "Страницы" / "Стуктура".

If name is not localized, using default name (english). Sort plugins list in the admin by field "code".

If can't translate plugin name, localization may be based on transliteration.

Example (eng → rus)

"PhotoShop" → "Фотошоп",

"Windows" → "Виндовс".

Please vote! ;-)

http://redactorjs.com/

In general : Any request that can change data on the server which can be either GET or POST should have the XSS protection. Developers should be aware of this.

So everybody who uses GETs to alter data should add a protection.

nice article for the interested people: http://teamtreehouse.com/blog/the-definitive-guide-to-get-vs-post

If you still want to check every GET request for x, use cot_check_xg(). You can achieve this using a plugin that hooks into common.php.

I can add the x parameter using something like:

jsMainSettings.xfactor='theXtoken';
$(document).ajaxSend(function(evt, request, settings){
    var x=$.getUrlParameter(settings.url,'x');
    if (!x) { settings.url+='&x='+jsMainSettings.xfactor };
});

This was a small test I made in the console, I have made $.getUrlParameter and I have a global named jsMainSettings where I can put the $sys['xk'] thing in.
I think with this little coding i have covered ALL my ajax requests... :D
This example is not ready yet.. but it is just to show the idea

BIG Question:

There should be a piece in common.php like :

//======== Anti XSS addition =============
if ($_SERVER['REQUEST_METHOD'] == 'GET')
{
	if (empty($x)) {
		$x = sed_import('x', 'G', 'ALP');
	}
	if (!empty($x) && !defined('SED_NO_ANTIXSS') && !defined('SED_AUTH') && $x != $sys['xk'] && (empty($sys['xk_prev']) || $x != $sys['xk_prev'])) {
		sed_redirect(sed_url('message', 'msg=950', '', true));
	}
}
//===================================

where sed_redirect for AJAX - JSON should be something else i think... but you get my point !!

Thinking about this reminds me of the GOD (Good Old Days) of Usenet, back when you would find posts by DMR and everyone knew that was Dennis Ritchie. A common competition was to find the lightest tool to do a job. It might start with someone's C program to do something. You would then have someone show how to do it with awk, then sed, ... It was fun to play the game but, also, you learned a lot about the capabilities of those tools.

Learning to do "fancy things" with Cotonti could be equally enlightening.

And, a bit later ...

I tried to figure out how to implement your suggestion. Adding the field is easy but I then realized it would need to be in the template, ... So, time for less talking and more research.

A similar capability but a bit more free-form is CEDI in ocportal. It could best be described as more like a Wiki but with a tree structure as well. If you have ever used Zim (http://zim-wiki.org) you probably grok this right away. The web site itself was actually created using Zim by building the tree in Zim and then exporting the pages in HTML.

• 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.

«strict reference checks» is interesting too, but if it will not be «heavyweight» code.

As for PFS it more actual for me is checking files not used (has no active links on it) in CMS. So I can purge unused ones.

Toplist - Should be a plugin, it doesn't belong in the main package.

Responsive page size - Depends on the theme. I'm working on one that supports it. Actually it's not really hard to retrofit this to an existing theme.

Widgetizing - Interesting feature, but it would take a lot of work. Probably requires a custom theme and plugin (admin tool). Not something for core I think.

I don't know what you mean by your last two suggestions.

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

Thnx


All core improvements that CAN be backported should be backported maybe... ? The really nice once's anyway
 

Big things such as installer and new admin layout cannot be ported. But smaller things probably could.

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