Welcome to the Question2Answer Q&A. There's also a demo if you just want to try it out.
+1 vote
in Q2A Core by
I'm looking at creating a Markdown editor for Q2A. Would it work better to store the HTML in the database or the plain Markdown. With the first method, we need to convert the HTML back to markdown for editing. For the latter, we need to convert markdown to HTML on the fly when the page is loading. Which is easier?

1 Answer

0 votes

I think this is a job for an editor and viewer module combined into one plugin. You should store the plain markdown in the database, and give it a new format value like 'markdown'. You can then render this format into text or HTML as requested, using your viewer module. Hopefully by the end of today the documentation about viewer and editor modules will be online.

OK, the first version of the documentation for editor and viewer modules is online. Bear in mind that the names of functions in viewer modules have changed since 1.3 beta 2, so you'll need to make a small adjustment.
Thanks for the answer, I think I'm understanding the plugin architecture now. A couple of questions though:

1. Should I simply return $content from the get_text function in my viewer module? Markdown is being stored as plain text in the database.

2. I don't really understand the return values for get_field and read_post in the editor module. Can you explain the arrays? And I don't fully get how to add extra elements, e.g. a toolbar (your example uses Javascript; I'd output straight HTML).
Sounds like you're making good progress! To answer your questions:

1. Your get_text() function should return the markdown as text, with formatting removed. The result of get_text() is primarily used in notification emails (which don't currently support HTML) and for search indexing. To preserve newlines and the like, you might actually find it easiest to take your HTML rendered version in $html, and convert it to $text like so:

$viewer=qa_load_module('viewer', '');
$text=$viewer->get_text($html, 'html', array());

(This uses Q2A's default viewer to perform the conversion - it takes care of things like mapping <LI> to a newline.)

2a. If you want to output any sort of structured HTML (say in $html) for the field, you should return an array of this form from get_field():

array('type' => 'custom', 'html' => $html)

BTW, you can also add a 'note' element to the field if you want to display a short explanation of how to use Markdown below the field. Or you might choose to include that within $html itself - see how it looks.

2b. Your read_post() function should return whatever it is you want stored in the database, to enable your viewer module to work correctly. Based on what you've said, I think something like this is probably right:

array('format' => 'markdown', 'content' => qa_post_text($fieldname))

where your editor used $fieldname for the name of its HTML field.

Let me know if any other questions pop up - this is also very helpful for me to understand how to improve the plugin documentation.
Thanks for the info gid, that was spot on. The only extra thing I added was qa_sanitize_html on editor->read_post and viewer->get_html. The basic Markdown editor, sans toolbar, is working perfectly :)
OK regarding 2a: if we're outputting custom HTML, is there a function to get the textarea for you, with all the correct attributes? Obviously there are custom classes/sizes on there that maybe shouldn't be specified by my plugin.
First of all, just a hint: if your user is not providing HTML themselves, there is no need to use qa_sanitize_html(), since there's no way for the user to inject Javascript or other nasties. Certainly you shouldn't need it for HTML that you build yourself in your viewer.

As for your question about the textarea, I'm afraid it's not currently possible. You do of course have the option of returning a Q2A form element that describes a textarea, but this won't allow you to fully customize the HTML around it.

So for practical purposes I think you're fairly safe just hard-coding CLASS="qa-form-tall-text" (and whatever else is appropriate) in your HTML. It's true that someone's custom theme could render that CSS class meaningless, but in practice it's not very likely to happen.
Actually with Markdown you can use HTML, although the Markdown PHP library takes care of script tags and other nasty code. The main reason I'm using Q2A's sanitize function is to add nofollow to the links.

Everything seems OK in Firefox. Currently struggling with a weird bug in the WMD Javascript editor that only pops up in Chrome/Opera...