Copying an existing site

Read this when the owner already has a site and asks you to bring it over: match its look, but put its content where the owner can edit it from the dashboard. building still applies to everything else.

A copy is done when it looks like the original and the owner can edit every article, case study and other repeated item from the dashboard. A pixel-perfect copy they can’t edit has failed, the same as an editable one that looks nothing like the original.

Anything the site repeats is a table

Articles, case studies, projects, services, team members, testimonials and prices are each a list of items with the same shape. Each kind is one table, and each item is one row. Articles use the reserved posts table, so the owner edits them in Posts. Case studies and projects use the reserved portfolio table, so the owner edits them in Portfolio, with a cover, drafts and an order of their own (vzk/tables, “Portfolio”). Every other kind gets a table of its own (create_table), edited from its table screen.

• One item is one row. Its words, its long text and its pictures are the row’s values, never a page of its own or text typed into a page, a layout or a component. Long text goes in as Markdown (vzk/tables, “Writing a post body”).
• Anything an item carries is a field on its table. A summary, a category, a card picture, a price or a place in the order gets a field (update_table adds one later), read as record.summary on the table page and item.summary in a listing. Order by a sortable field with sortBy rather than by where rows happen to sit. A portfolio already keeps a summary, a cover and a position, and lists in the owner’s order when a page names none, so a case study’s metrics, client or year are the fields to add.
• One table page renders every row of a kind that has pages of its own, reading record. A component holds reusable presentation, never one item’s content.
• Every listing reads the table. The home page, the listing page and any other page that shows an item loop over tables.<name> and read the same fields. A summary is written once, on the row, never retyped into another page’s fields.
• A very long article is split into several posts, because a body has a size ceiling (vzk/tables).

Pages the owner can find their way around

• Name every page field for what it holds and where it shows (hero.title, pricing.note), and every dictionary key for its phrase (nav_contact), with one key per phrase (vzk/pages, “Naming fields”; vzk/languages). A field named by a counter is editable but impossible to find.
• A policy, terms or a long story is one Markdown field, not a field per paragraph (vzk/pages, “Long text”).

Bring the tokens, not the built CSS

Copy the old site’s colours, fonts and spacing into @theme, and its recurring pieces into component classes (vzk/styling). Never paste its built stylesheet: a write of it is refused, and the compiler already makes every utility the pages use.

Try the platform before a workaround

Draft the design with Markdown bodies and structured fields first. Reach for a workaround only once a draft shows they cannot match it, and file that gap with request_feature so the platform can close it.

Check before merging

For each table you made, edit one row’s title, body and each other field you added on its screen (or with update_record) and look at the preview: the row’s page and every listing that shows it change, because all of them read the row. A preview shows draft posts and portfolio items too. If any still shows the old words, text was copied into a page, a layout or a component, and it has to move into the row. Put the edits back afterwards.

Once content has moved into a table, delete the pages and components that held it.