Layouts, areas and components

Create your first layout and template, from the admin to the repo Deploy the template file first, create the layout that points at it in the admin, add the layout areas, then create a page that uses it. The admin only offers templates that already exist on the server. Add a layout area and render it in the template Add the layout area to the layout in the admin with a permanent name, an input type and an editor-facing label; it appears empty on every record using the layout. Then read it with the getter for its type. Create an input type for a design-token dropdown A select input type whose option keys are CSS classes and whose labels are what the author reads. Define it once, reuse it on every layout that offers the choice, and print the key straight into class="". Organise a long editing form with area groups Groups split a form past about ten fields into named, collapsible sections, ordered as you set them; ungrouped areas follow after. Templates are unaffected: they read areas by name whatever group holds them. Make an area an attribute instead of content Tick Attribute on the layout area and it leaves the content form for the Attributes tab, button or cog, depending on where it lives. Templates read it exactly as before; only the author's form changes. Attach alt text and a crop as attributes of an image area An attached attribute is an attribute with a parent: it sits behind a cog next to the image field and moves with it. Add imageAlt (text) and imageCrop (select) with the image as parent, and read them by name. Build your first standalone component A component layout is a layout with no controller whose template lives under components/. Create the template, register the layout, add it to a collection's supported layouts, and read your areas from component. Add a component collection an author can fill A collection is a layout area whose input type has the collection category. Add it to the layout, name the component layouts it accepts, and loop its elements in the template, rendering each element's component. Restrict which components an author may add to a collection Supported layouts on the layout area decide what the add menu offers. Fill them in on every collection and component area; an empty list offers every component layout on the site, including the block itself. Render a collection, handling both global and local components On the frontend, a collection element's getComponent() already returns the global component when the element points at one, so one loop serves both. Guard for blank, and pass only new variable names down. Nest a component inside another and keep heading levels valid A component with a collection of its own can hold components; the heading level is the thing that breaks. Keep the current level in the template context: read it, print, raise it for children, restore it afterwards. Convert component attributes into CSS classes Selects and multiselects whose keys are classes, and switches named after the class they turn on, become one class string through a shared helper, so no component carries the loop. Include it in Smarty, import it in Twig. Build a global header and footer an author can edit A global component is stored once, versioned, and edited by authors without a deploy. Give it a component layout, an identifier, and fetch it in the base template with _globalComponents.get(). Its template reads areas as any component does. Rename or retire a layout area without losing author content Content is stored against the layout area, not its name, so a rename keeps content and breaks templates; retire by hiding, never deleting; and change a type across categories by adding a new area and moving the content.