Are you ready?
| urlkiller |
|
|---|---|
|
i dont really understand why you are arguing with me about it... did you missed the: YOU CAN CHOOSE FOR YOURSELF?
- you can keep your 100k posts with bbcode - yes bbcodes are good as i said! - yes you can color and embed youtube videos, cool thing, huh? wjhat i said was that you should split the html editor, if there is any sometime, and make it into a plugin. thats because i was talking about SIZE and not the meaning behind the bbcodes 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. i bet that it is possible to hook the plugin in the main system that the parser can handle such plugin solution... but an example where the html parser would be awsome could be a page like apple. they dont have some fixed layout all over the page they switching layout blocks here and there and every page look a bit different. ok its still a page.php?al= thing . i dont like to have 100 different templates with different layouts i wish a bit more freedon when designing pages. so much for good reason number one URL shortener: <a href="http://bbm.li/!7AD5C7">http://bbm.li/!7AD5C7</a>
|
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 SED.by - создание сайтов, разработка плагинов и тем для Котонти
|
| 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!  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...Why all these problems for only a 500kb addiction?  urlkiller: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... in [color=#729FCF][b]BLUES[/b][/color] I trust
|
| urlkiller |
|
|---|---|
|
@kort
if not maybe you can explain me how would you manage this problem? URL shortener: <a href="http://bbm.li/!7AD5C7">http://bbm.li/!7AD5C7</a>
|
| foxhound |
|
|---|---|
|
@Kort
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. <img src="http://www.armaholic.com/datas/thumbs/green-sea-battalion-uniforms-version-03-preview_4.jpg" alt="green-sea-battalion-uniforms-version-03-" />
|
|
Kort
|
|
|---|---|
|
What I am trying to say here is: it is not a wishlist. As of today, there are 3 (!!!) people contributing to the project. Others "officially quit" or became observers or both. On top of that we got here opinions mainly based on personal requirements. 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.
SED.by - создание сайтов, разработка плагинов и тем для Котонти
|
| 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. <img src="http://www.armaholic.com/datas/thumbs/green-sea-battalion-uniforms-version-03-preview_4.jpg" alt="green-sea-battalion-uniforms-version-03-" />
|
| Trustmaster |
|
|---|---|
|
Thanks for your opinion, 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. May the Source be with you!
|
| ez |
|
|---|---|
|
I must say I have to revise my opinion.. I voted for HTML, but heaving read all arguments, I must say I feel for keeping both..
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. ==- I say: Keep it EZ -==
|
| donP |
|
|---|---|
Trustmaster: ez: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"  in [color=#729FCF][b]BLUES[/b][/color] I trust
|
| GHengeveld |
|
|---|---|
|
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. |
| Trustmaster |
|
|---|---|
# Koradhil : Considering all opinions and preferences, I'm convinced we should go for a multi-parser solution. My design would include the following: 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:
May the Source be with you!
|
| donP |
|
|---|---|
Trustmaster:This was my ghost fear... now we'll have got a database growing continuously and dramatically Trustmaster:this was an important reason to switch to HTML. Trustmaster:Actual PFS is already an Achilles heel even without these new complications... Trustmaster:This last consideration make me finally hoping for two Cotonti versions: HTML Cotonti / BBCode Cotonti. in [color=#729FCF][b]BLUES[/b][/color] I trust
|
| tensh |
|
|---|---|
|
Cotonti database is really small compared to other CMSes, so I would not be worried here.
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(). |
| Kilandor |
|
|---|---|
# donP : This was my ghost fear... now we'll have got a database growing continuously and dramatically The field will be there, but it doesn't mean it will have any data in it. |
