@mekell It's a bug, not properly handling **bold** in Volto. Volto supports limited "markup input", but not "markup rendering". The theory is that a whole Volto Edit page is just one single TinyMCE-equivalent richtext field, so the Volto blocks are actually really powerful editors for complex rich text elements.
Not what you ask for, but if you don't have too much text, maybe my add-on medialog.markdown or some parts of it, could be a workaround. Quite old now, but might still work.
It does not render the markdown, but saves the markdown to another (html) field (so it saves two fields instead of one, taking up more space and slowing things down a bit).
The reason for this is that I could not get portal transform to work properly with all the 'extra markdown stuff I put in',
Feel free to 'take whatever you need' If you manage to make a proper portal_transform, please let me know.
Also note: Some of the markdown_extensions might clash with each other (for example: dont use 'superscript' and 'subscript', you can enable / disable them in the ZMI, there is a list of some of them here: Extensions — Python-Markdown 3.4.1 documentation
Quick and dirty fix: WeTransfer - Send Large Files & Share Photos Online - Up to 2GB Free ( I have commented out the markdown tile. It installs lineage (in dependency of medialog.controlpanel, remove it gives you problems. by the way: medialog.controlpanel should not have a dependency on lineage, better to add a condition, but I dont have the time right now).
Anyway: you should be able to test it. 1) install it 2) Add the behaviour to a (new) content type 3) change settings in the control panel (at bottom).
Is it planned to further support markdown in Volto UI?
I'm interested in markdown with dexterity content types.
The Volto UI doesn't offer a select input for the mime-type when editing a richtext field. Neither the dexterity controlpanel offers the possibility to select the mime-type.
There are also problems with the RESTAPI returning HTML instead of markdown.
Maybe it's possible to go with an easy route: create a new type of field, use a simple textarea or see if there's any React markdown editor components that can be integrated, then render the output on display, maybe even with a field serializer registered with plone.restapi.
But it unfortunately adds to the list of features that a "frontend" obfuscates and even removes from a "backend"
Yes, but let's be frank, there's also things that are added, not just removed. Either Volto is not appropriate for your project, or you'll have to factor in the additional costs to develop your required functionality. I'm writing this as somebody that had to work on implementing plenty of features in Volto (for example completely rewriting the text editor, heavy lifting in Volto's addons infrastructure, etc) to make it fit for our projects.
You're right. I very much appreciate the impressive and wonderful work invested in Volto, specially by you! Can't thank you enough for giving your work to the community.
Personally I think Volto, specially React is the right way to go. Even if it'll be a long way.
What I am concerned with is that the technology around Plone Classic UI could be neglected or abandoned. Specially considering the huge amount of work invested in projects by our (and other) customers.
We have shortly convinced one big customer to go for Plone 6 Classic UI. Volto was discarded by our customer because lack of markdown (and because it was not yet released and battle proof).
I understand. Too bad about the situation... let's hope your client will turn to Volto sometimes in the future. I think it's a good idea, as a general rule, to address this sort of shortcomings with the rest of the Volto community. Maybe some solution could have been worked out.
My curious client tried to add markup in a text block only because the block properties contains a list of shortcuts. I see @mekell 's open issue but I was wondering if I should create an issue to hide the markdown shortcuts in the block properties until the issue fixed?