Suggestions for a Markdown/BBCode Switcher?

Wilson29thID

Hey guys, I've just migrated my community of a few hundred members from SMF to Vanilla. I'd like to have Markdown as the default editor but with a toggle button (like "Advanced") that switches the editor to BBCode or CLEditor.

I've a good deal of experience with PHP and JavaScript and have played around with very basic Vanilla plugins (mostly fixing buggy ones). Can someone point me in the right direction of the best way to make an editor toggle plugin? It's one thing to switch the editor but I think I'll also have to switch the Format field in the post's database record.

Has anyone seen a similar plugin I could look at the source code of?

R_J

You can take the Simple Pages plugin as a start: http://vanillaforums.org/addon/simplepages-plugin

Look at the functions postController_afterDiscussionFormOptions_handler and discussionModel_beforeSaveDiscussion_handler in order to see how to add a field to the new discussion page and how to change the Format field before the Save happens.

If you create a DropDown and name it "Format" you theoretically wouldn't have to do anything in the BeforeSave function, but I'd advice you to do a sanity check that the value really is either Markdown or BBcode so that no vicious user garbles your database.
In case someone corrupted that field, you can either use a default or add a validation error. You can see how that can be done in Simple Pages, too. Look for "AddValidationResult". Something like "Your spoofing attempt has been registered. You will be banned shortly"

R_J

You can take the Simple Pages plugin as a start: http://vanillaforums.org/addon/simplepages-plugin

Look at the functions postController_afterDiscussionFormOptions_handler and discussionModel_beforeSaveDiscussion_handler in order to see how to add a field to the new discussion page and how to change the Format field before the Save happens.

If you create a DropDown and name it "Format" you theoretically wouldn't have to do anything in the BeforeSave function, but I'd advice you to do a sanity check that the value really is either Markdown or BBcode so that no vicious user garbles your database.
In case someone corrupted that field, you can either use a default or add a validation error. You can see how that can be done in Simple Pages, too. Look for "AddValidationResult". Something like "Your spoofing attempt has been registered. You will be banned shortly"

R_J

By the way: if you seriously want to get into plugin development, you should download as much plugins as you can get hold of (and also some applications) and work with a text editor that can search across files.
In the source of Vanilla, look for "FireEvent" in order to find the places where you can get influence on the program flow. Use the plugin Eventi for additional help to find the right events visually.
After you've got the name of the event, simply do a full text search in your forum directory and in most cases you'll get some useful examples.

That's the way I found my way into writing plugins. What I found most confusing is that there are very few conventions in all those plugins.
I've set up Sublime Text to work with Vanillas coding standard https://github.com/vanilla/addons/tree/master/standards/Vanilla/Sniffs which is a great help if you do not want to use a full blown IDE.
That standard is not "live" in the current stable branch, but @Linc already uses it for his plugins (as you can see in Simple Pages) and so it wouldn't hurt to use it right from the start

x00

R_J is correct , but it already strips Raw for non admins

x00

I notice that 2.2 version works a bit differently.

R_J

Oh yes, seems like you'll have to ensure that you set Garden.ForceInputFormatter to false in the config (do that in your function setup()).

Something you might want to take into consideration before using such a plugin: if someone using Markdown quotes a BBCode post or the other way around, the quoted text will not be parsed correct. That's why I think mixing the parser is a bad idea.

x00

I agree mixed parser nice in theory, bad in practice. Except as a webmaster's tool.

R_J

If postings where saved as html a cross markup plugin would be no problem because there are converters that can convert markdown/bbcode to html and vice versa.

My first impression when I saw the combination of the original text and the format column was that I was wondering why Vanilla doesn't serve a pre-rendered text but instead always has to format each posting again and again and again.
I understood the usefulness for plugins to be able to change the output whenever it is needed, but always felt that having the content already rendered as html could speed up things significantly.

Sometimes I think that I would set up some things differently than they are realized in Vanilla but in this very case I would only prefer to have a pre-rendered html post but I couldn't think of a way to keep the flexibility you now have with plugins being able to influence the code.

What if you add a RenderedAt column to Discussion and Comment and force plugins that like to influence the content of discussions/comments to identify themselves and keep track of their activation date? Maybe by using a standardized Plugins config called FormatterEnabledAt:

public function setup() {
    SaveToConfig('Plugins.MyPlugin.FormatterEnabledAt', date('Y-m-d'));
    // or a little bit more pretty:
    // SaveToConfig('Plugins.MyPlugin.IsFormatter', true);
    // SaveToConfig('Plugins.MyPlugin.EnabledAt', date('Y-m-d'));
}

The format function must accept the posts RenderedAt column as an additional parameter and has to check if RenderedAt <= each activation date. If true, text has to be formatted again (and updated in db) and if not, text can be passed without further actions taken.

What's your opinion?

hgtonight

Don't use BBCode as the advanced parser. Use HTML.

It is supported in the MarkDown spec, and you don't have to mess with the format column at all (keep it as MarkDown). Use the switcher to change what button bar (or whatever editor you use) actually does.

Keep this UI crap on the frontend.

Wilson29thID

@hgtonight said:
Don't use BBCode as the advanced parser. Use HTML.

It is supported in the MarkDown spec, and you don't have to mess with the format column at all (keep it as MarkDown). Use the switcher to change what button bar (or whatever editor you use) actually does.

Keep this UI crap on the frontend.

You make an interesting point. We started with the bootstrap markdown editor, but people complained at its inflexibility (they've come from heavily customized BB code). But I suppose if I had a toggle button between the markdown editor and the CLEditor (which saves HTML), that would be sufficient...especially since it would add a <br> for line breaks.

So in that case I'll have to figure out how to switch the editor on the fly. Hopefully that's just JS

Wilson29thID

I've played around with plugins enough now to build this plugin (thanks for the tips to get me here) but am now realizing that what I really need is some kind of tag to stop Markdown processing (and only allow HTML). This way Markdown could be the default but if you want to do something more advanced you can just use HTML. At the moment you can use HTML inside of Markdown but sometimes they get in each other's way, like when you have HTML inside a Markdown tag or Markdown inside an HTML tag (but really you just wanted to use < brackets or asterisks). Has anyone ever seen something like this before? I'd hate to recreate the wheel if there's already a standard.

R_J

To my understanding it should be quite simple: just set Format to "Html"

See here for reference: https://github.com/vanilla/vanilla/blob/master/conf/config-defaults.php#L92

Wilson29thID

@R_J Yes but I'm asking about switching mid post, ie.

This is some **Markdown**
[nomarkdown]
This is plain <i>HTML that **won't** be parsed for Markdown</i>
[/nomarkdown]

R_J

You would have to write your own custom formatter for that.

If you enjoy doing stuff like that, go on, but I'd say it's such a special use case that it is not worth the effort of maintaining a special parser on your own.

x00

That would be a pain becuase you would have to separate each format and join them post processing, then you would need to still run it through htmLawed one more time as otherwise it is an exploiters wet dream.

I have to wonder why you are going to such effort? people aren't as adverse to change as you think, they like to give that impression but in reality they get over it.

x00

What it sound what you need is a better markdown parser. That is in the running I heard from core team, you might search on github, I believe one other guy wanted to get involved.

This parser is slightly broken and there are different flavours of markdown.