Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
Test/dummy content is great, but sometimes it might get in the way of editors that need to go there and delete the test content and enter real content. Some sites would benefit from the ability to have the dummy content for preview purposes only, but then scaffold new content with a node form as empty as possible. This is specially relevant when using paragraphs as the page-building paradigm, so the templates are mostly intended to let editors know what types of paragraphs they should use (and where), more than generating content to the paragraph fields themselves.
Proposed resolution
We could have the following new settings:
A- a per-bundle setting in the node type form called "Can generate "content-empty" nodes"
B- a global setting (radio buttons) called "Preferred cloning mode"
(x) Default (with content)
( ) Structure-only (empty fields)
Then, the following changes would happen:
1- In the templates page, if a content type is marked with the setting in A), we would add a new button to each template row, allowing them to create from an empty template. When clicked, this would remove content from all fields, except ERR fields (paragraphs), and do the same recursively (so that the added paragraphs also have their fields emptied). Since we are duplicating the node programmatically, we will be able to save the node even if required fields are missing. This means any new edit to the newly-created node will need to fill in all mandatory fields, at least.
2- If the setting in B) is changed to "Structure-only (empty fields)", we would also:
2a) Make this new button the primary button
2b) Make so that the menu links added by this module also start from empty templates, instead of directly cloning the original template (with content).
Remaining tasks
- Figure out best wording for all these config options and editor-visible labels
- Implement :)
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | templatize_node_with_options.png | 237.05 KB | marcoscano |
| #5 | content-select.png | 58.7 KB | dead_arm |
| #5 | preview-modal.png | 20.34 KB | dead_arm |
| #4 | updated-UI-text.png | 70.08 KB | dead_arm |
| #3 | per_type_setting.png | 351.81 KB | marcoscano |
Issue fork pate-3274639
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #3
marcoscanoHere's a first shot at how this could work. A few screenshots:
The new setting on each content type that can become a template:
And the global setting:
By default, and on existing sites, the current behavior is kept. If site admins don't change anything in the config, nothing new will appear or behave differently.
If site admins mark the new option on the per-type edit form, and the site-wide settings is kept as default, then we'll have a new secondary button in the templates page:
and a new secondary button in the preview modal:
and the links in the menu will create from the content-full template (current behavior, no change here).
On the other hand, if the site-wide setting is defined to prefer creating from empty templates (structure-only), then the new button in the templates page and in the preview is now displayed as primary:
and the menu links will trigger the cloning using the structure-only option (create from "empty" templates):
Is all this clear enough to editors/admins?
Comment #4
dead_armThis is super @marcoscano!!
Some suggestions on the UI text
1. Update the h1 with content to "Available [name] content templates" to reduce confusion about other types of templates in Drupal
2. Move the create with non-template button below, add "or" header to indicate it is different, update the button text to "Create without template"
3. Update the button text for creating with a template with content to "Create with template, include preview text" and without content to "Create with template, exclude preview text"
Comment #5
dead_armI think it would also be good to reflect the button text changes in the preview modal
and to move the create landing page without template option to the last position in the add content menu
Comment #6
hawkeye.twolf+1 this is great.
I wonder if the "Preferred cloning mode" should be per content-type rather than site wide... I can see a use-case where the "cloning with preview text" makes sense on one content type but not on another, so site builders would want a different default action on each.
If both clone mode checkboxes are checked, a new radio buttons element would appear to allow choosing the default mode.
Comment #7
marcoscanoThank you @dead_arm and @hawkeye.twolf for the feedback! 🙏
Re: #4 and #5 @dead_arm:
You bring some good points, but these interface items aren't being introduced in this ticket, they are already part of the (stable) module release. Even though this module doesn't have a ton of users :), I personally know of a few projects using this interface for quite a while, some of them on large editorial teams. I'd be reluctant to change their interface without a larger discussion, ideally including them if possible. Originally I had thought of this feature as a completely opt-in addition, so existing sites wouldn't have any impact, but if we follow your improvements that wouldn't be the case.
The parts of the UI being introduced here that I wasn't too sure about were more terms such as "structure only" or "content-empty nodes", etc, which make sense to me today, but might not be as easily understandable by others. I like the concept of "with/without preview text", that might make it easier to understand, thanks! 👍
Re: #6 @hawkeye.twolf:
You raise a good point about making the preferred mode per-content-type... 🤔 I think in my mind it made sense to be site-wide to keep consistency across menu items in different types, but it's true that if there's a type without paragraphs at all for example, creating from a template "without preview text" would be no different than just opening the empty node form...
Comment #8
marcoscanoThinking a bit more about the "with/without preview text" expression... Is "text" the most appropriate term here? Fields could have anything (images, video, etc), so I wonder if this might be confusing to some people. Maybe "with/without preview content" would be better?
Comment #9
quicksketchWhen creating a "Structure-only" version of the node, what happens with default values? I would guess that defaults are respected, and if that's the case, we may want to avoid the term "Empty", since fields will be populated with the default values from the field configuration.
That said, I think providing two separate buttons for "one with content" and "one without content" might be too much burden on the editorial user. It might also make a lot more sense for some templates, but not all of them. Instead of having these options be available for all templates (even at a per-content-type level), I think this would be better suited to be a per template setting, and the only setting would be whether to clone all content or maintain the structure only. Since this appears to really only affect Paragraphs, maybe only show that option if Paragraphs module is enabled.
So here's the workflow I'm imagining:
From here on out, PATE acts exactly as it does now. There's still only one button for "Create from Template", and it just has the behavior of copying the template content or not, predetermined on a per template basis. If you really want both options for the same template, save the same template twice: one with the entire template and one with structure only. That would also make it so that the admin menu structure stays the same as it does now.
Regardless of how the option gets implemented, I think this seems valuable for sites that make heavy use of paragraphs.
Comment #10
marcoscano@quicksketch thanks for the feedback! You bring excellent points.
Regarding default values, I had missed this, but it's true, we should provide an experience similar to opening a "new node form", which comes with default values, instead of "all fields empty". I'll give it a try, it shouldn't be too much more complex to restore default values instead of just unsetting the field values.
Regarding moving the setting into a per-template scenario, I like it! It does involve us creating a new base field to be able to store this on each node/template, but that is probably justified by the fact that this simplifies the UI a lot. I'll play with this idea and see what I can come up with.
Thanks again!
Comment #12
marcoscanoThanks everyone who contributed to this!
In the end, the per-template setting is indeed simpler (both form an implementation standpoint and less confusion on the UI). \o/
I went ahead with something like this:
All the rest remains the same (templates page, preview, menu links, etc.)
I also changed the implementation to reset fields to their default values, when creating from a "structure-only" template. That's why the terminology in the new UI setting avoids "empty" and uses "structure only" instead.
I also opened a follow-up to discuss other unrelated usability improvements mentioned here: #3276414: Usability improvements / UI text review
Thanks again!
Comment #13
quicksketchLooks great! Thanks @marcoscano!