Feature: Markdown support as a Markdown-specific Gutenberg Block #9357
This PR will need code from a corresponding PR WordPress/gutenberg#6491.
The reasoning behind this feature addition is to add the ability to save and edit Markdown in posts when using Gutenberg. This would restore the spirit of the classic editor Markdown implementation.
Additional reasons are:
Changes proposed in this Pull Request:
Run the following:
Proposed changelog entry for your changes:
The idea here is to reuse the existing original Markdown, on the second post for Meta Boxes following a `Save Draft` event. This way when the markdown parser runs a second time it does not parse the rendered markup in `post_content` and overwrite the original Markdown in `post_content_filtered`.
I note the issue: "Footnotes do not render properly." What is the intended location for the footnotes?
End of the block is probably the easiest to implement. End of the post might be what most people expect. An arbitrary location would provide more flexibility, and as long as it was optional with the default being one of the prior two choices, wouldn't be any harder to use.
I'm excited to see this being worked on.
My initial thinking was that since the Markdown processing is happening on the whole post every time we could try to take the best aspects of both experiences.
ehg left a comment
I get the general impression that using regex parsing isn't going to serve us well.
I'm not sure how we could get rid of these, maybe another parser, leveraging Gutenberg's parser?
I think an option is thinking of Markdown for Gutenberg support more separated from the classic editor. This could open up more appropriate places to store the markdown/rendered HTML — which may obviate the need for regex/post_content_filtered. Do you have any ideas here? Maybe some more Gutenberg specific storage structures?
@ehg I think I would consider the first iteration complete for the most part at this point. I still think testing could be improved and JS testing needs to be implemented when the Gutenberg components are published independently for testing. That can be done in the final solution.
I don't normally have an issue with well commented regex used appropriately, we have 3 regex instances introduced and they function as follows:
I would like a cleaner solution as well. Can you help me understand your concerns with regex?
Yes, I agree that this is the ideal scenario. This was the vision of the 2nd and 3rd iterations in the original issue #9201.
I remember we spoke of the calypso support using a tinymce plugin. My intention had been to look into the possibility of using the same plugin and modifying the RichText component to become a Markdown editor.
That would address the editing/preview experience and browser based parsing. Persistence of the Markdown data is another matter. I'll be looking at this today and post my thoughts a little later.