cotonti.com : A global switch to HTML parsing https://www.cotonti.com Son konu mesajları Cotonti en Sat, 14 Mar 2026 04:56:44 -0000 Kilandor Çrş, 22 Eyl 2010 18:32:57 -0000 donP Çrş, 22 Eyl 2010 05:39:08 -0000 Trustmaster
  1. Default parsing mode will be HTML. BBcodes will be converted to HTML.
  2. Alternatively, there will be an option when migrating to Siena to keep bbcodes and disable HTML.
  3. There will be only one field to store text, no more page_html or fp_html. The actual sequence will be as this (in pseudocode):
    $text = get_post_contents();
$text = apply_html_filters($user_group[, $special_location]); // Filter settings are based on user group, there also will be optional sets for special locations
$text = apply_bbcodes(); // Applies bbcodes over html, if there are any. Good to make shortcuts or special things like [hide]
$t->assign('SOME_VAR', $text);
  4. HTMLPurifier will be present as a plugin (on by default).
  5. CKEditor will be used as default editor.
]]> Çrş, 22 Eyl 2010 00:55:58 -0000 donP Sal, 21 Eyl 2010 20:43:14 -0000 urlkiller
btw. the file thing already published in that ckeditor plugin has a neat function for directly manipulating images... i read somewhere about in the php files of the elFinder that there is a possibility to connect different image manipulating librarys. sounded interessting too.

Added 127 days later:

any news on this topic here?]]> Pzt, 17 Mayıs 2010 07:26:38 -0000 GHengeveld Pzt, 17 Mayıs 2010 02:03:21 -0000 Trustmaster
As for WYSIWYG, HTMLPurifier and Siena, see the latest news on index page.

There is a small problem about HTMLPurifier and CKEditor: as these are LGPL, commercial derivatives will have to exclude them from the package or require commercial licenses. But currently there are no such derivatives and most users shouldn't care about this.]]> Paz, 16 Mayıs 2010 18:25:27 -0000 urlkiller the other editor wont feel so right but the filemanager does. its quite nice looking and has good functionality..

@ Trustmaster: When you think to insert WYSIWYG editor and HTMLPurifier support in Cotonti?... I'm wondering if we can have it in Siena... (Siena development is three month late indeed...).

ditto]]> Paz, 16 Mayıs 2010 17:04:38 -0000 donP
By the way, it hasn't right-click contestual menues (more intuitive and fast to reach and manage objects properties like tables, images etc...).

It doesn't support so many languages as ckeditor...

I personally feel better with ckeditor...

@ Trustmaster: When you think to insert WYSIWYG editor and HTMLPurifier support in Cotonti?... I'm wondering if we can have it in Siena... (Siena development is three month late indeed...).]]> Cmt, 15 Mayıs 2010 15:05:36 -0000 Trustmaster elRTE. Let me know what you think about it.]]> Cmt, 15 Mayıs 2010 14:01:59 -0000 Alex300 http://portal30.ru/User_Files/a-n_Files/file/cotonti_plugins/ckeditor.zip

It is installed on multiple sites and works well.
If an error occurs, I need more information about configuring your server to correct it and take into account in the new version of the plug.]]> Çrş, 12 Mayıs 2010 18:42:08 -0000 donP Alex300 CKeditor+Ajaxfilemanager plugin hosted here on Cotonti when I click "search the Server" button in CKEditor...

Added 4 days later:

I still don't see any ticket in Trac about this argument... :/]]> Per, 06 Mayıs 2010 20:12:59 -0000 GHengeveld Per, 06 Mayıs 2010 19:37:38 -0000 donP 
The requested URL /plugins/ckeditor/ajaxfilemanager/ajaxfilemanager.php was not found on this server.
]]> Per, 06 Mayıs 2010 06:13:42 -0000 Alex300 Try to use Ajax file manager . It's free]]> Per, 06 Mayıs 2010 04:17:04 -0000 donP ]]> Çrş, 05 Mayıs 2010 17:44:04 -0000 urlkiller i got the oem licence for this...]]> Pzt, 26 Nis 2010 04:38:04 -0000 donP ]]> Pzt, 26 Nis 2010 02:30:00 -0000 urlkiller ckfinder implemented?

just a question aside the main topic...]]> Pzt, 26 Nis 2010 02:09:29 -0000 donP ]]> Pzt, 26 Nis 2010 01:51:32 -0000 Trustmaster Paz, 25 Nis 2010 20:13:06 -0000 urlkiller
... whats the reaction of the core devs on this?]]> Paz, 25 Nis 2010 10:56:14 -0000 donP And I don't see any step in Siena tracker about our parser question... :/]]> Cmt, 24 Nis 2010 15:17:12 -0000 tensh # donP : There's already an appropriate field in sed_pages table: it's page_type: 0 = BBcodes parsing; 1 = HTML parsing.

Heh, I was wondering what's this field for. ^^

Koradhil, I think I mentioned page extra fields? But you're right, generally I'm in the second group of Einstein's division (the one who doesn't know).]]> Çrş, 21 Nis 2010 15:14:45 -0000 GHengeveld Trustmaster:
As for permissions, better use appropriate plugin permissions rather than extras. That's the easiest solution, but not very flexible. I intentionally wanted to use extra rights fields, because that will allow you to configure who can use which parser/editor on which area. Allowing for HTML in pages, but only BBcode in forums will be easy that way.

@tensh: I think you're not seeing the entire scope of what's involved here. We're not just talking about page_text or forum_post_text (or whatever), but page_extra123 etc are involved as well (limitless amounts of fields actually, since all custom fields should get the right parser).]]> Sal, 20 Nis 2010 23:47:58 -0000 donP tensh:
The next thing would be adding additional database table - "page_parser", which would tell us how the page was saved - using html or bbcode. There's already an appropriate field in sed_pages table: it's page_type: 0 = BBcodes parsing; 1 = HTML parsing.]]> Sal, 20 Nis 2010 22:01:46 -0000 Kilandor # donP : This was my ghost fear... now we'll have got a database growing continuously and dramatically :(
this was an important reason to switch to HTML.
Actual PFS is already an Achilles heel even without these new complications...

This last consideration make me finally hoping for two Cotonti versions: HTML Cotonti / BBCode Cotonti.

The field will be there, but it doesn't mean it will have any data in it.]]> Sal, 20 Nis 2010 20:15:04 -0000 tensh
I also don't get why multi-parsing is difficult...

As it is now, we have a "Normal parse/HTML" toggle, and in database: the input text field and the field for parsed result.
The only thing is that if I choose "HTML parsing", the HTML isn't filtered but probably put directly into page_html as well.

So why we can't just process the form through HTML Purifier on submit with the HTML turned on?

The next thing would be adding additional database table - "page_parser", which would tell us how the page was saved - using html or bbcode. When switching the BBcode/HTML toggle on page add or page edit, ajax would refresh the page submit form with a different editor - on HTML it could be a WYSIWYG editor, for example. Also, because of "page_parser" remembering which parsing was used, next page edit would display an appropriate editor (either bbcode or html).

As for other fields (description, etc)... they could use a plugin to enable additional parsing using custom-created extra fields for those who would need it. Or the extra fields itself could have a mechanic allowing a parsing method.

I write it just after creating a plugin "page-menu", in which I wanted to place a custom page menu displaying anchors to some headings in a page. As I input a pure html to an extra field, it was just displayed on the page without parsing. I had to create a plugin getting that field and putting it through sed_parse().]]> Sal, 20 Nis 2010 16:40:40 -0000 donP Trustmaster:
we won't drop page_html for bbcodes because it really makes the site faster. This was my ghost fear... now we'll have got a database growing continuously and dramatically :(
Trustmaster:
It's hard to add optional fields to BBcodes, so improving SEO in bbcodes is a tricky thing
this was an important reason to switch to HTML.
Trustmaster:
For such things like PFS it will require to support multiple parsers too, when inserting thumbs, file links, icons, etc.
Actual PFS is already an Achilles heel even without these new complications...
Trustmaster:
There are more fields with parsing potentially enabled rather than just page_text. For pages it could be also page_desc, page_preview. Forum section descriptions would need markup too. Setting different parsers to each of them would be a waste.
This last consideration make me finally hoping for two Cotonti versions: HTML Cotonti / BBCode Cotonti.]]> Sal, 20 Nis 2010 15:16:22 -0000 Trustmaster # Koradhil : Considering all opinions and preferences, I'm convinced we should go for a multi-parser solution. My design would include the following:

- Multi parser, both BBcode and HTML
- BBcode gets smart paragraphs instead of nl2br
- HTML is cleaned using HTMLPurifier (upon submission)
- We use two of the extra rights fields (the hidden ones) to configure which usergroup can use which parser (i.e. both HTML and BBcode for moderators and up) for each site area/plugin. Alternatively we add 2 custom fields.
- We use only one field for the text (BBcode or HTML), but use another to store which parser is applicable. This keeps redundancy to a minimum.
- All editors (Markitup, TinyMCE, CKeditor) are configured as plugins. Which two will be included in the Cotonti package (if any) is yet to be defined.

Good point technically. Though, we won't drop page_html for bbcodes because it really makes the site faster. As for permissions, better use appropriate plugin permissions rather than extras. What I'm worried about is:
  • It's hard to add optional fields to BBcodes, so improving SEO in bbcodes is a tricky thing
  • For such things like PFS it will require to support multiple parsers too, when inserting thumbs, file links, icons, etc.
  • There are more fields with parsing potentially enabled rather than just page_text. For pages it could be also page_desc, page_preview. Forum section descriptions would need markup too. Setting different parsers to each of them would be a waste.
]]> Sal, 20 Nis 2010 12:33:02 -0000 GHengeveld
- Multi parser, both BBcode and HTML
- BBcode gets smart paragraphs instead of nl2br
- HTML is cleaned using HTMLPurifier (upon submission)
- We use two of the extra rights fields (the hidden ones) to configure which usergroup can use which parser (i.e. both HTML and BBcode for moderators and up) for each site area/plugin. Alternatively we add 2 custom fields.
- We use only one field for the text (BBcode or HTML), but use another to store which parser is applicable. This keeps redundancy to a minimum.
- All editors (Markitup, TinyMCE, CKeditor) are configured as plugins. Which two will be included in the Cotonti package (if any) is yet to be defined.]]> Sal, 20 Nis 2010 07:27:00 -0000 donP Trustmaster:
For me it's been enough to see we should not drop bbcodes and multiple parsers completely, but rather focus on HTML and provide more options and choice.
ez:
So keep the choice.
Yes, but it would be a REAL choice, not a solution like:
"you can use pure HTML with WYSIWYG editor but, at the same time, as now is, your Cotonti system must continue storing two tables in your database (page_text and page_html) and its Core must continue doing double work (sorting everytime the appropriate parser) to keep compatibility" :(]]> Sal, 20 Nis 2010 04:42:19 -0000 ez
And honestly BBcode is not that bad and evil :P..
And maybe we can improve it e.g. with alt and title tag questions for seo purposes.
(that is something that isn't that hard to do)

So keep the choice.]]> Sal, 20 Nis 2010 02:14:06 -0000 Trustmaster foxhound. I see you have a large community where members like to post using bbcode. And it makes sense, because you're right I wanted to see different points of view.

For me it's been enough to see we should not drop bbcodes and multiple parsers completely, but rather focus on HTML and provide more options and choice. Next I'm gonna try some experiments to see how hard it will be to implement.]]> Pzt, 19 Nis 2010 23:37:00 -0000 foxhound # Kort : we got here opinions mainly based on personal requirements.
But, isn't a personal requirement also the choice of CMS for the website one wishes to run? I guess it is and so this poll asks for the opion of the user what he/she thinks is best both for the development and the community. Let me quote the first post:

.....now I would like to know if our developers and community are ready for a global move from BBcode to HTML parsing.

I consider my opinion being one of the community. If the community should not vote in the poll this topic should not have been made asking for their opinion.

It is ridiculous to discard development ideas based on the fact that somebody needs freedom or has 10000 pages ready. There has been no objective capability comparison or something: just exchanging "professional opinions" and personal requirements. So, no need for sorries.

Again, in the first posts the community is asked for their opinion. If you don't want to hear it don't ask.
As pointed out before for my community site bbcode really should stay. But if you would ask me for my business site the answer would be "I don't care" cause its me running it and not having troubles with html or my clients posting topics/news pages/whatever.]]> Pzt, 19 Nis 2010 20:24:04 -0000 Kort Pzt, 19 Nis 2010 17:04:27 -0000 foxhound Ah ok............so just cause you feel Cotonti is not made for community sites I should go and leave all my months of hardwork and stick to Seditio, which too was not made for gamming communities?
Not a valid reason to oppose anyone voting differently than your opinion.

Cotonti has been optimized and improved all over to perform better, so as gaming communities have the tendency to grow Cotonti is perfect for such........but well..........thats just my opinion.

Joomla and all others are fun, but so far most people prefer our current Sedito community website over all others as its the best system, the most clear, and the easiest to use. Maybe that are some points for you to reconsider your first thought? Guess not but for me it is enough.


Sorry to have bothered you with my vote and my thoughts.......I thought I was a member here and as such could leave my opinion in a poll. I see now the poll is only for those who want bbcode gone.]]> Pzt, 19 Nis 2010 16:47:05 -0000 urlkiller
if not maybe you can explain me how would you manage this problem?]]> Pzt, 19 Nis 2010 05:02:23 -0000 donP # urlkiller : what about having the editor as an plugin so the user could use regular html if he can do it from scratch but if you want that nice editor you would need to dl the plugin. Module, not plugin.
I'll wonder if one user (maybe also an experienced one) would write pages in HTML from scratch! :O
I think also good webmasters would use WYSIWYG editors and only make corrections to resulting HTML code...

# urlkiller :this way you could get around the additional 500kb so far i voted for a package less than 500 kb...
there should be enough hooks in the header for inserting the plugin the easy an smooth way.
it could be in the release version but maybe also as a additonal plugin.
Why all these problems for only a 500kb addiction? :/

urlkiller:
plus you could choose wich plugin you would like to use.
see if you got already bbcoes in your forum, its ok. install the bbcodes plugin. you wish to use html support, its ok too, install the html plugin.
This would be a pain in the ass! Still more job for Core (understand the appropriate parser used in that area, and eventually reparse content) and more wasted space in database (to store bbcoded text and parsed html content).

And I continue to say that conversion would be very simple, with a one-line script, also for 100k pages or forum posts...]]> Pzt, 19 Nis 2010 04:28:55 -0000 Kort i dont like to have 100 different templates with different layouts i wish a bit more freedon when designing pages.not even close to a good reason]]> Pzt, 19 Nis 2010 04:04:56 -0000