How to use markdown with Volto?

Is it possible to use markdown with Volto?

What I've tried:

What I've also tried:

  • Add RichText behavior to Content Type "Page"
  • same as above

@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.

**bold** can probably also be written __bold__


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',

There is an old video here: medialog markdownII - YouTube

Code is here: GitHub - espenmn/medialog.markdown: Markdown widget for Plone 5

Feel free to 'take whatever you need' :slight_smile: 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

@tiberiuichim Oh. I see.

@espenmn Thanks for the hint.

I've been looking at it before.The code has lots of interesting ideas.

But it seems not to work with Plone 6 due to an AttributeError: module 'five' has no attribute 'grok' .

${PLONE_HOME}/bin/pip install medialog.markdown installs the following packages that might conflict with already installed packages:

collective.dexteritytextindexer==2.4.1
collective.js.bootstrap==3.3.7
collective.z3cform.datagridfield==3.0.0
five.grok==1.3.2
grokcore.annotation==3.2
grokcore.component==3.2.0
grokcore.security==3.0.1
grokcore.site==3.1
grokcore.view==3.2
grokcore.viewlet==3.1.0
martian==1.5
medialog.controlpanel==1.3
medialog.markdown==0.2.2
plone.app.jquery==1.11.2
plone.app.tiles==3.3.0
plone.directives.form==2.0.3
plone.tiles==2.3.1
zope.authentication==4.5.0
zope.login==2.2

grok is not related to my add-on, but maybe something it relies on does.

I would try to change setup.py to only require
'collective.z3cform.datagridfield',
'medialog.controlpanel',
'plone.api',

The tiles stuff is for mosaic, so try comment out

I will try to look at it as soon as I get the time

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).

UPDATE: Use GitHub versions ( espenmn (Espen Moe-Nilssen) · GitHub medialog.controlpanel & medialog.markdown )

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.

No, there's no such plans, AFAIK.

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.

This are really very bad news.

Yes this is already possible. But it unfortunately adds to the list of features that a "frontend" obfuscates and even removes from a "backend".

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).

1 Like

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.

1 Like

Slightly off topic (and I did not have the time to read all posts), but it is possible to 'do markdown with javascript (only).

That said: The python 'verision' is much better, in my opinion (check out stacked .io)

UPDATE: stacked io is gone

Yes. It is possible (see for example markdown-it or Marked).

But I'd prefer a server version which allows things like caching, sanitize, blocking of tags, extensions that interact with content etc.

There is nothing against use both (server side and client side) for different content types.

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?

@mikemets do a search first and if there isn't such an issue already present then yes please add an issue about this.