Repository navigation
Support Frontmatter in MD files #145
Description
Activity
Thanks for your suggestion. While front matter is not really specified in commonmark, I still agree that we should make sure that it is not changed. So we should make sure to strip it from the markdown parsing and add a simple code block for editing at the beginning of the document.
Reacted by Jan C. Borchardt, Lukas Menzel, Stefan Gofferje and iMpronta48Reacted by Lars Becker and Stefan Gofferje- added this to the milestone
on Jul 9, 2019 That sounds great @juliushaertl , thank you for considering this suggestion.
You could also consider rendering the displayable content, such as title, in appropriate styles. But somehow the user would need to able to add or to edit the other fields.
Also, not sure, but if the block is appearing disassembled after changes are saved, then maybe there is a separate issue with the way documents are processed. A MarkDown editor ideally should, I think, preserve as much literal content as possible from the original document, not attempt to produce an entirely new document from the logical features of the AST.
Reacted by Henri CazottesHi, I think this feature is definitely important :-)
But I don't think it should be rendered as text like the rest. These blocks are supposed to be metadata (see, e.g. https://pandoc.org/MANUAL.html#extension-yaml_metadata_block which specifies it cleary, or https://jekyllrb.com/docs/front-matter/ which specifies it implicitly with the special rules IMO). The point is: you can have a lot more metadata in these blocks, not just "title" and "author" (I use them extensively to process with Pandoc). Trying to use them to render anything will probably lead to a lot of chaos…
So it probably requires a lot of work to get right from the UI/UX perspectives (the simple solution could be to treat it like a codeblock - but instead of inserting the codeblocks delimiter, use "---" and "---"; but this does not feel very satisfactory…)
Reacted by Julius Knorr, Pierre Ozoux, Marie-Cécile Godwin Paccard and iMpronta48But I don't think it should be rendered as text like the rest. These blocks are supposed to be metadata.
The point is: you can have a lot more metadata in these blocks, not just "title" and "author
The suggestion is not to render all metadata as stylized text, only the elements that appear visually in the document, such as title and author.
Naturally, other data must be shown in another manner. A collapsible code block would allow easy editing, while still offering a distraction-free view of the document that resembles final output with respect to display of the title and similar fields.
I saw the issue and since this is something I'm quite interested in, I tried to sketch something. The first attempt is to use a foldable table layout
Folded:
Unfolded:
And following @brainchild0 suggestion, a version with some of the metadata rendered differently
Folded:
Unfolded:
I don't feel like this solution is intrusive w.r.t. to the goal of keeping Text distraction free. Let me know what you think!
Still, I have no experience with the code base and I have close to 0 knowledge of JS, so I don't know if this is even feasible.
That said I think simply fixing the formatting bug that breaks the yaml frontmatter should be enough for now, and having the yaml block printed verbatim at the beginning of the file is a "good enough" solution, that allows the use of Text with CMSs like PicoCMS.
Reacted by mcnesium, Julius Knorr, Pierre Ozoux and SpartachettoReacted by Hans Martin Galliker@dyamon Thanks a lot for the mockups, this looks great imo but let's bring @nextcloud/designers in here for some additional feedback.
Regarding the implementation, we probably need to implement our own frontmatter plugin for markdown it that then returns a node that can be parsed by tiptap. It could be based on https://www.npmjs.com/package/markdown-it-front-matter
29 remaining items
Apparently we are talking about different things here. I was talking about not altering existing YAML code, while you seem to be talking about editing that (or creating it).
For simply leaving YAML code in Markdown files intact (i.e. untouched when the document is saved), I guess #593 can help (although its solution might not fix this). But I agree that it gets out of scope for that issue when it comes to editing or adding that.
Apparently we are talking about different things here. I was talking about not altering existing YAML code, while you seem to be talking about editing that (or creating it).
No, I am also referring, in my recent comments, to the idea of not altering the YAML block (hence "rewrite verbatim"). My earlier question points to the possibility that an application might leave segments of Markdown unaltered, but not similarly protect a YAML block, because of confusion over an assumption that the the YAML is rather some kind of Markdown, which it, under certain conditions, may attempt to alter.
Thus, one question is whether users currently experience problems of the kind originally reported. Yet, the broader issue is that a robust solution depends on recognizing the YAML block as a region of the document not subject to Markdown processing, and that realizing this solution depends on specific logic for detecting the YAML block.
This issue topic is the only currently open that directly indicates the need to include logic that guards the YAML block from any accidental effect, which might occur, without such logic, through some later change to the application, even if such an effect is not occurring currently.
Alright, thanks for clarifying that.
In that case, I think #593 is at least partly suitable, else we probably want to create a separate, more broad issue for this, as this is not only affecting YAML blocks, but all kinds of other segments that might reside in a Markdown file like LaTeX for example.
At least I hope there can be a solution that does not aim to first detect different content types in order to protect them afterwards, but that plain text is not altered in general at all if sections are not touched in the editor.
I can see however, that in the long run detection of YAML blocks is a good thing (to render them for example), but I'd assume that would be later down the road.
At least I hope there can be a solution that does not aim to first detect different content types in order to protect them afterwards, but that plain text is not altered in general at all if sections are not touched in the editor.
This distinction may be illusory. What you are calling "plain text" is simply document sections that the user wishes not to be processed as Markdown. The application is a WYSIWYG editor for Markdown, which means that it must follow one of two designs. First, it may treat the entire document as Markdown. Alternatively, second, it may invoke a method for detecting certain sections as not Markdown. I believe the current design corresponds to the first option, which, as argued, is not a solution for the desired behavior.
I suggest there is no possible solution that treats Markdown as Markdown, and YAML as not Markdown, but cannot detect the difference.
It should be mentioned that this would or might break commonmark support, as without a newline between text and the second
---it would be interpreted as a setext heading.With a empty line instead it would be interpreted as thematic break.
@susnux: Yes, it is true, but the pattern is common, and normally handled by a special case. Many processors handle the exception seamlessly.
I am sorry: the issue is closed, but in my Nextcloud instance front matter is messed up anyways… might there be something I am doing wrong?
The issue is closed because it's fixed in the next major version of Nextcloud.
Reacted by kosssiIt does not seem fixed in Nextcloud 25. :(
Reacted by ⁂ TommiReacted by ⁂ Tommi and Ferdinand ThiessenIt does not seem fixed in Nextcloud 25. :(
@hippi-viking sorry to hear, would you mind to provide your test file and the file after saved by the text app?
@susnux In the meantime i figured it is still a known and open issue that Text strips the YAML header from Markdown files - even if the file is only opened for reading. Problem is that this breaks PicoCMS. Historically Simple text editor was recommended to be used, but that is also broken under NC25, so at the moment there is no working text editor in NC for editing PicoCMS Markdown files.
For a test file if you type in the following 3 lines and later try open it it will be stripped:
---
Header: test
---I could reproduce this:
On the first time opening the file it works (I opened a file containing already a frontmatter).
After editing and downloading the changes are correctly saved, but when opening the file again the frontmatter is stripped.
I have an idea whats going on there, I will look into this but probably not before (mid of) next week.Reacted by ⁂ Tommi and Timo TootsReacted by Julius Knorr, ⁂ Tommi and Hippi VikingReacted by ⁂ TommiI could reproduce this
Could the issue be reopened?
@susnux Thank you for looking into this!
@xplosionmind I think it is not necessary, it is a known issue as per nextcloud/cms_pico#116 .
Is your feature request related to a problem? Please describe.
I'd love to use the Collaborative editor to share Page files for the Grav CMS (a flat-file CMS). Right now any Frontmatter (https://jekyllrb.com/docs/front-matter/) originally in the file seems to be re-saved in a different format. Frontmatter is used quite widely in both static site generators and flat-file CMSs.
Here is a simple example of Frontmatter for testing purposes:
When saved, this is the result:
Describe the solution you'd like
Any frontmatter contained in a MD should be visually distinct from the main content of the MD file, and also be editable (like a Code Block perhaps?)
Describe alternatives you've considered
I've not been able to find any so far.
Additional context
Add any other context or screenshots about the feature request here.
Thanks very much! The new collaborative editor is awesome to see in Nextcloud!