A published form does not appear anywhere on its own. Something has to ask for it, and Leed gives you three things that can: the page’s Form setting, a Form block in the page body, and a call to the leed/form partial in a template. They differ in exactly one way that matters — who decides where on the page the form sits. With the Form setting, the layout decides. With the Form block, the author decides. With the partial, the developer decides, once, for every page that uses that template.
- Page setting
- Form block
- Template partial
Nothing to write. Pick the form in the page editor’s Form dropdown, and your layout renders it wherever it calls the partial with no arguments:
{{> leed/form }}Inserted from the editor toolbar. In Leed Markdown the stored block is:
{% form formId="a1b2c3d4" %}Pasted into any .hbs file you maintain, naming the form explicitly:
{{> leed/form formId="a1b2c3d4" }}The page’s Form setting
Open a page, go to the right rail’s Settings tab, and the Form dropdown sits in Page Details between Page Type and the Target/Published Date field. Choose a form and clear it with the ✕; the rest of that panel is covered in page settings.
The dropdown is disabled unless the page’s page type allows forms. Every page type carries a Form requirement of Not Allowed, Optional or Required, and Not Allowed is the default for all three kinds — documentation, posts and API. On a fresh workspace this dropdown is therefore grayed out for every page, and it stays that way until someone sets Form to Optional or Required on the page type. That is done in configuring a page type, and it is the single most common reason this dropdown “does not work”.
Once chosen, the formId rides along in the published page’s front matter. Your layout is what turns it into a form, by calling the partial with no arguments — the partial then reads the id from the page’s own data. That is why this placement puts the layout in charge of position: the page says which form, the layout says where. Layouts and page types covers how a page type is bound to the layout that will make that call.
The editor’s Form block
The Form button in the editor toolbar — the same toolbar that inserts images and embeds — opens the Insert Form dialog: a labeled Form * select listing your forms by name, with Cancel and Insert Form, and a Create New Form button that takes you to the Forms section so you can go and make one.
The block lands at the cursor and is stored in the page body as a Leed Markdown shortcode:
{% form formId="a1b2c3d4" data-id="form-1" %}It carries exactly two attributes: formId, which is required, and an optional data-id. Anything else you write into that shortcode is dropped when the CMS reads the page back — the editor’s parser looks for those two and no others, and the next save rewrites the line without your addition. If you have seen a {% form %} example carrying some other attribute, it does not survive a round trip through the editor. Embeds and icons covers the shortcode family this belongs to.
Where the button is missing
The Form button is hidden on posts page types. Every other type gets it; posts do not.
In a template
If you maintain your own templates, name the form directly:
{{> leed/form formId="a1b2c3d4" }}The same call also works inside CMS page content, because the site build’s process shortcode scans rendered markdown for partial calls and compiles each one it finds. That is an escape hatch, not the recommended route: a partial call written into page body content is invisible to the CMS, so the form appears on the site while nothing in the editor shows that the page uses a form. The form partial documents everything it accepts and emits.
Which one to choose
| Placement | Who decides position | What it needs first | Stored as | Best for |
|---|---|---|---|---|
| Page Form setting | The layout | The page type’s Form requirement set to Optional or Required | formId on the page revision, published into its front matter | Landing pages built from one layout, where every page puts the form in the same place |
| Editor Form block | The author, per page | A page type that is not posts | {% form formId="…" %} in the page body | A form partway through an article, or two forms on one page |
| Template partial | The developer, once | Nothing but a published form | {{> leed/form formId="…" }} in a .hbs file | A form in every article footer, or a sidebar signup across a whole section |
Only the first of these counts as “using” a form for the purposes of deletion. Leed’s in-use check reads the page’s Form setting and nothing else, so a form embedded as a block or called from a template can be deleted out from under the pages that render it — building a form explains what that check does and does not see.
When a form does not appear
All four of these fail quietly. None of them produces an error you will notice without looking.
The form is not published. The partial looks the formId up in your site’s published form data and renders nothing at all when it is not there — no gap, no message, no console warning. A form you created this morning and have not deployed is in exactly this state. Publish the form first, then look again.
The embed has no formId. A {% form %} shortcode missing its id is the one case that leaves a trace: the site emits a literal <div>Could not render Form</div> where the form should have been. If you see that string on a page, the shortcode is malformed rather than the form being missing.
The page’s Form setting is set, but the layout never calls the partial. The id is sitting in the page’s front matter, and nothing reads it. This is the failure mode of the first placement, and it usually means the page type is bound to a layout that was not built to carry a form. Check the layout for a bare {{> leed/form }}.
You are looking at the preview site. The form renders there and the submit button even reaches its “Thank you!” state, but the submission is discarded and no callbacks run. Confirm which site you are on before concluding anything about capture — preview site vs live site covers the rest of what differs, and how forms work walks the whole chain from the rendered form to the contact record.