<!-- Some styling for better description lists --><style type='text/css'>dt { font-weight: bold;float: left;display:inline;margin-right: 1em} dd { display:block; margin-left: 2em}</style>

   robertokir: joined #tikiwiki
   gour: joined #tikiwiki
   luciash: <u>gour</u>: html escaping is needed for security or vandalism reasons unless the plugin would need approval on each edit
   gour: <u>luciash</u>: is it possible to disable plugin for anon. users?
   luciash: <u>gour</u>: s/unless/otherwise/
   <br> <u>gour</u>: nope
   gour: <u>luciash</u>: that sucks a bit...well, i can try to add https://github.com/webuni/commonmark-attributes-extension to get what i want/need
   <br> i'd prefer to keep my (offline) content in 'pure' markdown markup without too much fiddling with wiki-plugins like DIV/IMG etc.
   luciash: <u>gour</u>: "maybe, the plugin can have options to enable/disable html_input ..." &lt;- that would be possible
   <br> but we can add such enhancements later... now it is not much time and we need to decide mainly if we stick with the current phpleague/commonmark or change to the other one before 20.x is released
   gour: <u>luciash</u>: that would be good...i envision the scenario to write the content offline and then copy&amp;paste within Tiki, add links for the images etc. and then-only I can enable html-input
   <br> <u>luciash</u>: based on the feedback i got that the commonmark parser is an example of well-written code, i do vote to stay with your original choice
   <br> michelf/php-markdown seems to lack those html-input/unsafe-links option, while the erusev/parsedown is in a flux (awaiting for 2.0 release) and 'extra' part is not in sync with the dev version
   luciash: i see, I read what you wrote above now
   <br> sounds good to me
   gour: privately, however, i'll try to make that 'attibutes' extension working with the plugin
   luciash: we can stick with what we have and allow for some ůextra" features later
   <br> "extra"
   -: gour nods
   gour: :thumbs-up:
   <br> i must admit that without your plugin i'd not migrate to Tiki and would either stay with static-site-generators which are problematic when one tries to plumb the holes (search feature, forms etc.) or i'd have to use something like Grav where one have to fight with plugin incompatibilities  (https://pluginproblems.com/Modules-Extensions)
   <br> besides 'attributes' extension, now i'll try to tackle things like https://dev.tiki.org/tiki-view_tracker_item.php?trackerId=5&amp;itemId=7088
   <br> <u>luciash</u>: btw, the danger of html_input is for comments only or in general?
   luciash: <u>gour</u>: for comments?
   gour: <u>luciash</u>: blog comments
   <br> or anyone can do damage to the Tiki instance?
   luciash: <u>gour</u>: nope, in general for every Tiki textarea input where wiki syntax and plugins can be used
   gour: i see
   luciash: it is to prevent breaking your site layout for example, imagine someone would put unclosed html tag in there and you will have hard time to edit the page then to repair it
   <br> not impossible to edit that but would be a PITA
   gour: ok...ability to enable params in plugin, will be good-enough
   luciash: not mentioning JS attempts to damage your site/users
   Jyhem: polom
   <br> html input looks nice because the possibilities are infinite. BUT there are so many issues :-(
   <br> <u>First</u>: it goes against the whole point of markdown. If you know html, theoretically you don't even need markdown. (Note that we already have a HTML plugin)
   <br> <u>Second</u>: site could be defaced like luciash mentioned
   <br> <u>Third</u>: people can embed malware in the page.
   <br> <u>Fourth</u>: it leads to people trying to allow "safe" subsets of html and "filter" the rest which makes the whole thing overcomplicated, impossible to maintain, not intuitive to users (some stuff works, other doesn't), with ugly side effects. Like we have &lt;x&gt;s popping up and destroying content in seemingly random places now
   gour: <u>Jyhem</u>: i've got it...however, will try to make that 'attributes' extension work
   Jyhem: I think the way this is going is, we will end up having two plugins. One safe one starting with one mardown flavor and ending with a selection of markdown flavors, which can be used by anyone
   <br> Another one which is unsafe which requires content validation and which will allow dangerous stuf.
   <br> That's what was done for pluginR and pluginRR
   <br> One is safe and the other just wraps the other but it allows dangerous and powerful R commands and requires validation
   <br> Some people tried having option-level validation and I think it was confusing users.
   <br> Anyway, +1 to luciash's strategy: get something useful in Tiki20 which can be extended later on.
   <br> bbl
   gour: interesting...
   jonnyb: joined #tikiwiki
   gour: joined #tikiwiki
   gour_: joined #tikiwiki
   gour: joined #tikiwiki
   Jyhem_laptop: joined #tikiwiki