Is it possible to add multiple blocks of content to single pages (.md) without resorting to using modules?
You mean you want to add some more text editor?
If so, that is totally doable, using blueprints.
I basically need an arbitrary number of additional content blocks in Markdown, in the same page. So right now, the header is identified by two ---
lines followed by the content (referenced as page.content
) which is written in Markdown. But I need to add any number of additional, uniquely identifiable content blocks that I can reference in the template…
So, that might look like this:
{{ page.content }}
{{ page.content_2 }}
{{ page.content_3 }}
And so on and so forth…
Then, you have to provide your own blueprint.
If you want to add multiple editor (what you called “content block”) for the template article.html.twig
then you have to create a file under user/themes/yourtheme/blueprints/
and name it article.yaml
Inside, you will add this:
title: Article
'@extends':
type: default
context: blueprints://pages
form:
fields:
tabs:
fields:
content:
fields:
header.content_2:
type: editor
ordering@: 2
label: Second editor
header.content_3:
type: editor
ordering@: 3
label: Third editor
Then in your template article.html.twig
you can use
{{ page.content }}
{{ page.header.content_2|markdown }}
{{ page.header.content_3|markdown }}
Awesome, thanks!
Though, this requires me to set up a fixed number of content blocks. Would it be possible to add the blocks dynamically? Like not having a fixed number of editors/blocks but rather have the author choose the number of blocks?
I realize that this is almost certainly bordering modular content…
Sure, here is an example:
title: Article
'@extends':
type: default
context: blueprints://pages
form:
fields:
tabs:
fields:
content:
fields:
header.editorlist:
type: list
label: Add a block of text
btnLabel: Add block
controls: both
fields:
.block:
type: editor
label: Text block
Then you can access it with
{% for editor in page.header.editorlist %}
{{ editor.block|markdown }}
{% endfor %}
Very nice!
The GUI seems to bug out when doing this, though. Adding a block is easy enough, but reloading the page after adding content fixes the editor into a non-expandable box.
Expanding All/Collapse All doesn’t work…
yes, list field is special and you might find some bugs with some fields inside a list field.
Consider using instead a texarea field type instead of editor if possible.
textarea
suffers the same fate… I tried adding collapsed: false
to the blueprint to no avail.
Perhaps this is bug report worthy on GitHub?
EDIT - Issue reported: https://github.com/getgrav/grav/issues/1919
I think you can’t see a difference because the collapsed state of list elements will continue to show the first field. As you only have a single field, it will continue to show the editor when list is collapsed or expanded.
If you add another field, it should solve your problem
Yes, thanks. That did the trick.
One last question: Is it possible to remove the default content editor?
Sure, here is how you do it:
title: Article
'@extends':
type: default
context: blueprints://pages
form:
fields:
tabs:
fields:
content:
fields:
content:
unset@: true
Dude, you’ve been a lifesaver. Very much appreciated!