Who this is for. Everyone new to a site, before they go looking for anything. The most common early mistake on Core dna is searching the repository for something that lives in the database. After this page you will know where each part of a site lives, and which changes a deploy carries.
The line, part by part
| Part of the site | Lives in | Changed with | Carried by a git push |
|---|---|---|---|
| Templates | The repository, templates/ | Your editor | Yes |
| Front-end source: SCSS, JavaScript | The repository, usually src/ | Your editor, then a build | Only as the built files |
| Built CSS and JavaScript | The repository, usually dist/ or static/ | The build, then a commit | Yes |
Files served as they are: favicon.ico, robots.txt, the design's fonts and images | The repository | Your editor | Yes |
| Replacements for the platform's own interface wording | The repository, translations/ | Your editor | Yes |
| Layouts and their areas, input types, custom fields | The client's database | The admin (Customization) or the API | No |
| Pages, posts, products, forms, FAQ, custom entity records, and their revisions | The database | The admin or the API | No |
| Components, global components and menus | The database | The admin or the API | No |
| Members, backend users, groups and permissions | The database | The admin or the API | No |
| Jobs, redirects and search views | The database | The admin or the API | No |
| Settings | The database, and for a few, a settings file on the server that Core dna controls | Each module's Configuration screen in the admin | No |
| Uploaded files and images | The platform's file storage, served from /files/… | The admin's file manager or the API | No |
| The application: modules, admin, APIs, default templates | Core dna | Core dna | Not yours to change |
A deploy carries files, never database records. A layout created on a development site does not appear on production because the template it uses was deployed; it has to be created there too, or moved with the admin's tools. Code deploys, content does not covers how teams handle that.
The seam: a layout points at a file
A layout is a row in the database that stores a path, such as pages/pages/article.html. The file at that path is yours, in the repository. Neither works alone: a layout whose file is missing shows Template not found in Smarty or an error in Twig, and a file no layout names is never rendered for a page. Before moving or renaming a template, find the layouts that name it: the list under Customization › Layouts shows each layout's template.
Replacing the platform's templates
The platform has templates of its own, such as the error pages under errors/ and the messages it shows under includes/frontend/messages/. Templates are looked up in your templates/ folder first, so a file at the same path in your repository replaces the platform's. It is the one way a repository changes what the platform renders: keep the override file in place, because moving or renaming it restores the platform's own template in its place. Template resolution order has the detail.
Mistakes this line prevents
- Searching the repository for a layout, a menu or a setting. They are in the admin, on the environment you are looking at.
- Expecting a deploy to bring configuration with it. It brings files only.
- Editing a built file. The next build replaces it. Change the source and build: The build output is committed and served.
- Committing a secret. An email or payment provider's key belongs in that module's settings in the admin, where it is kept out of every repository. No credential belongs in a tracked file.