The Solo theme adds a per-content-type theme hook suggestion to the node add and edit form, so a template named node-edit-form--article.html.twig in your sub-theme applies to Article forms and nothing else. Drupal core does not offer this. Core routes every node form through one template, which is fine until you have a content type with thirty fields and an editor who has to scroll past twenty of them to reach the one they came for.
This is how the mechanism works, how to use it, and the one rule that catches everybody the first time.
Why bother customising an edit form at all
Because the edit form is the product, for the people who use your site every day. A content team that fills in the same complex form fifty times a week is paying a small tax on every single one, and an editorial interface that groups related fields together and hides the irrelevant ones is worth more to them than most front-end polish. It is also the cheapest usability work available on a Drupal build: no new modules, no new dependencies, one template file.
How Solo wires it up
Two pieces of theme code make it work, and it is worth knowing both so you can tell what is failing when something does not.
First, Solo alters every node form and sets its #theme to node_edit_form. Without that step, node forms fall through to the generic form.html.twig and no node-specific template is consulted at all. The same alter also converts the advanced and meta groups into containers and pushes revision information under the meta group, which is what produces the familiar two-column editing layout.
Second, Solo implements the theme suggestion hook for that hook name and appends node_edit_form__<bundle>. It works out the bundle two ways: from the node object on the form when you are editing, and from the node_type route parameter when you are creating. That second path matters — without it your template would apply on edit and silently not apply on add, which is a maddening thing to debug.
The suggestion translates to a filename by the usual Drupal rule: underscores become hyphens, and the double underscore becomes a double hyphen. node_edit_form__article becomes node-edit-form--article.html.twig.
Doing it, in four steps
1. Work in a sub-theme
Never edit the theme's own templates. Solo ships an empty starter sub-theme for this, and a Composer update of the parent will overwrite anything you put in the parent's directory. If you have not set one up, the Solo setup order covers where the sub-theme decision belongs in the sequence.
2. Copy the base template
Take templates/admin/node-edit-form.html.twig from the Solo theme and put it in your sub-theme at templates/admin/node-edit-form--article.html.twig. Copying rather than starting blank matters: the shipped template attaches the stylesheet that produces the two-column layout, and a template that omits that line renders an unstyled stack of fields.
3. Clear the cache and confirm the template is being used
Theme hook suggestions are cached. Run drush cr, then turn on Twig debugging at /admin/config/development/settings and load the Article add form. Drupal writes an HTML comment into the page source listing every candidate template and marking the one it chose, so you can see immediately whether your file was even found.
Do this before you start moving fields around. Half the time spent on this task is spent editing a file that was never being read.
4. Print the fields you want, and exclude them from the rest
Inside the template, render individual fields by name and then output everything you have not named:
{{ attach_library('solo/solo-node-edit-form') }}
<div class="layout-node-form solo-clear">
<div class="layout-region layout-region-node-main solo-padding">
{{ form.title }}
{{ form.field_subtitle }}
{{ form.body }}
{{ form|without('title', 'field_subtitle', 'body', 'advanced', 'footer', 'actions') }}
</div>
<div class="layout-region layout-region-node-secondary solo-padding">
{{ form.advanced }}
</div>
<div class="layout-region layout-region-node-footer solo-padding">
{{ form.footer }}
{{ form.actions }}
</div>
</div>Per-content-type form templates are a small change that ages badly when nobody documents them. Drupal theming covers doing it so the next person can read it.
The rule that catches everyone
Every field you print explicitly must also appear in the without() list. Miss one and it renders twice — once where you placed it and once inside the catch-all — and because both copies are functional form elements, the duplicate is not merely cosmetic. It is confusing to editors and it is the first thing to check when a form looks almost right.
To find out what you can print, add {{ dump(form) }} to the template while Twig debugging is on. Take it out again before you commit; leaving a form dump in a template ships your form structure into the page source.
Common questions
Can I do this without a per-content-type template?
Yes, if the change should apply to every content type — override node-edit-form.html.twig in your sub-theme with no bundle suffix. Use the per-bundle form only when the content types genuinely need different layouts.
Does this replace Field Group or Layout Builder?
No, and it is not competing with them. Field Group is configuration and travels with a config export; a Twig template is code and travels with git. Field Group is the better answer for anything a site builder should be able to change. A template is the better answer when the arrangement is structural and you want it reviewed in a pull request.
Will this survive a Drupal upgrade?
Theme hook suggestions are a stable Drupal API and the pattern has been unchanged for years. What can move under you is the internal structure of the node form itself — the names of the advanced, meta, footer and actions groups. Re-run the dump(form) check after a major core upgrade rather than assuming.
What if my field does not appear when I print it by name?
Check the field's machine name in Structure → Content types → Manage fields, and check the field is not hidden on that form display. A field disabled in the form display is not in form at all, so printing it produces nothing and no error.
Does the suggestion work on the node add form as well as edit?
Yes. Solo reads the bundle from the route's node_type parameter when there is no node object yet, which is what makes the add form work. If you are writing this hook yourself in another theme, that is the branch people forget.
When this is worth the hour
Customise the edit form when a content type has enough fields that editors are getting them wrong, or when a specific field needs to be next to another one to be filled in correctly. Do not do it because the default looks plain — the default is fine, and every template you own is a template you maintain.
For form improvements that are configuration rather than code, Selectify covers the select-widget side of the same problem. And if you are untangling why an editorial interface has become unusable, that is usually a content-model question before it is a template one — the kind of thing that turns up in the portfolio more often than a redesign does.
If you want the editing experience for a complex content type designed and built rather than iterated at, that is Drupal development work and it is normally measured in hours, not weeks.
