Content

Define content types (Articles, Events, Products), write entries in a rich editor, and publish them. Publishing turns each entry into a static HTML page on Firebase Hosting, with a list page per type.

What it is

Content has three layers:

Every entry has a draft and, once published, a published copy. You edit the draft; publishing copies it to the published copy and rebuilds the pages. The admin list shows each entry as Draft, Published or Edited (published, with changes since).

The standard pages (About, Contact, FAQ, Privacy Policy, Terms, Cookie Policy) are entries too, of a built-in type called Info Pages at /info, so admins edit them like any entry. See Standard pages.

Static pages are a separate, simpler thing: hand-written HTML files in src/custom/site/pages/ (Arc CMS ships sample privacy and cookie policies in public/_site/pages/). See Static pages.

Turn it on or off

Content is a switchable feature with the id content. It is on by default and needs no other feature. To turn it off, list it in src/custom/features.ts:

export const CUSTOM_FEATURES: FeatureChoice = {
    off: ['content'],
};

When it is off:

• The Content admin menu (content types, entries, authors) goes, and /admin/contents/..., /admin/authors and /p/... show the not-found page.
• The public content routes (/{type}, /{type}/{slug} and their language-prefixed twins) are not registered.
• The Cloud Functions in functions/src/features/content.ts are not exported, so a full functions deploy deletes them: processPublishQueue, onSiteSettingsWritten, onContentTypeDeleted and seedStaticPages. The draft search queue, which needs both content and search, goes too.
• The setup wizard does not create the Articles type or the standard pages, and data export offers no content collections.

Firestore data is not deleted. See Feature ids for every id.

Set it up

The setup wizard creates Articles (slug articles, default template) and the Info Pages type with the standard pages as drafts (see Standard pages). To add your own type:

1. Open Content > Content types (/admin/contents/content-types; /admin/contents on its own goes there too) and choose Add Content Type.

2. Give it a plural name, a singular name and a slug. The slug is the URL (/events) and the Firestore collection names (arc_events, arc_events_drafts), so pick it once.

3. Pick a Content Template (or keep Default Template). See Templates.

4. Add custom fields (below) and save.

For planning types and fields for a website, see Define content types.

Content type settings

Which columns the entry list shows is chosen with Columns on the entry list itself, and saved on the type for every admin.

Custom field types

You type a field's name; its key is made from it and fixed once the type is saved, so renaming the field later changes only its label. The key is the slug, a hyphen, then the name in lowercase with hyphens: "Card Icon" on events is events-card-icon. Types made with older versions may have an underscore after the slug (events_card_icon). A template can use the full key or the short name (card-icon), on a detail page and inside the items loop of a list or card block alike. The short name never replaces a built-in: a field named "Title" does not shadow title.

The content type's view page has a Template Reference with keys to click and copy. Each field there comes with the snippet its type needs, the same as the In a template column below.

Field types reference

Every custom field value is stored in the entry's customFields map under the field's key. The examples use the short name of a field on an events type.

The five repeating types (infocard, gallery, labelvalue, faq, maplocation) render only on detail pages, not inside the items loop of a list or card block. Every key their rows carry is listed under Custom field bindings.

Options from another content type

A dropdown, radio or checkbox field with Use data from another collection on offers the published entries of another content type:

• It stores the chosen entry's id, so {{ key }} prints the id, not the title.
• The id, the display field and the fields ticked under Additional Fields to Save are copied onto the entry. On a detail page the copy is ref_ plus the full key: {{ ref_events-speaker.title }}, ref_events-speaker.urlSlug, ref_events-speaker.coverImage. For a checkbox the copy is a list, which {{ }} cannot print.
• Any field of the other type, built-in or custom, can be the display field or a copied field.
• Only published entries are offered, so every link has a page to go to.
• Publishing rebuilds the copy from the linked entry as it is published at that moment, so a page shows the entry's current title and fields. When the linked entry changes later, publish the page again (or use Republish website). A linked entry that is no longer published is left out, so wrap its block in data-arc-if="ref_events-speaker".

Field settings

• Required is checked only when you press Publish, on the default language. Save as draft, the editor's own saving and Preview accept an empty field.
• Type can be changed after the type is saved, but values already stored are not converted. A text value under a field changed to number or image stays the same text, so check the entries that have one.
• Deleting a field takes it out of the editor, but its values stay in each entry's customFields, and a template that names the key still shows them.
• The key is locked once the type is saved, because entries refer to it.

In a second language the editor translates only prose: text and richtext fields, the headline and text of an infocard, a gallery caption, the heading, labels and values of a labelvalue, the heading, questions and answers of a faq, and the heading, names and addresses of a maplocation. Every other field, including options, dates, images, files, icons and the rows' order and pictures, is shared by all languages and edited on the default language's tab.

Use it

Write and publish an entry

1. Open Content > {your type} and choose Add {type}, such as Add Article.

2. Write the title and body in the rich editor (TipTap: headings, lists, tables, task lists, links, images from the media library (or straight from a PDF's pages, see From a PDF), YouTube embeds, text color and alignment). An image dropped or pasted into the body is uploaded to the media library first and goes in at the M size, with a progress box while it uploads; a PDF or other document goes to Files and in as a file card (a link showing its title, type and size); see Drop or paste into the editor. Attach files in the / menu links files already in the library. Fill in the cover image, summary, tags, author, SEO fields and custom fields. When the type's template folder has layouts, Layout picks the one this entry uses (see Layouts).

3. The editor saves the draft as you work. Use Preview to see the draft rendered on the site. Drag the dotted grip in the gap between the writing area and the settings panel to make the panel wider or narrower; the editor remembers the width for each content type on this computer, and a double-click puts it back.

4. Choose Publish. The editor shows the deploy status of this publish (Deploying to hosting..., then Deployed to hosting or Deploy failed, with the reason when you point at it) and offers a retry if the release failed. A page whose template folder is not on the live site yet fails with "Template folder 'x' is not on the live site. Deploy the website, then publish again." In npm run dev, Live site differs beside Publish means your site files are not the live ones yet, so the page would be built from the old ones: deploy the website first. Click it for the whole message. On a phone it is only the warning icon; tap it for the message.

Other actions:

There is no scheduled publishing: an entry goes live when you publish it. An entry that still holds outline text starting with [Replace: (the standard pages start with it) asks before it is published.

Put entries in your own order

Newest first suits articles and news. For services, team members or FAQs you choose the order:

1. Add or edit the type and set Entry order to Your own order. The entries keep the order they had, newest first, until you change it.

2. On the type's entry list, choose Arrange (it shows only for a type in your own order).

3. Drag the entries into place, or use the arrows, and save. Drafts are listed too and keep their place for when they are published.

Saving republishes the type's list page and, when it shows the type, the home page, in one release. Moving an entry does not mark it Edited. A new entry goes after the arranged ones until you arrange it. Above 200 entries the dialog reminds you that the list page shows the first 100.

Standard pages

Every site needs an About page, a way to get in touch and its policies. The setup wizard creates a content type called Info Pages (slug info, template folder info, your own order) with six drafts, in this order:

Every prompt to fill in starts with [Replace:, and the editor asks before publishing a page that still has one. The outlines are not legal advice: have the policies checked for where you work.

The Info Pages type has five fields that each page turns on as it needs: Locations (a map), FAQ, Show contact details (the email, phone, address and social links from Settings, About), Show contact form (only with the contact feature on, see Contact form) and Info boxes (an Info Cards field for the Contact layout's own boxes, such as opening hours). The info template folder shows each section only when it is set.

The Contact page starts in the Contact layout (info/detail-contact.html, see Layouts), in three rows:

1. The title and the body, full width.
2. For each place in Locations: the map on the left, its name, address and directions on the right.
3. On the left, boxes: the email and phone from Settings, About (with Show contact details on), the social links, then the page's Info boxes. On the right, the contact form.

A row with nothing to show is left out, and on a phone everything stacks in one column. The other pages use the standard info/detail.html; any of them can switch to the Contact layout, and Contact back to Standard, with Layout in the editor.

Once published, the pages are linked from the default footer in their arranged order, and the signup terms notice, the contact form's privacy line and the cookie banner link to /info/terms, /info/privacy-policy and /info/cookie-policy. Publishing or unpublishing a page, changing its title or arranging the pages republishes the whole site, so every footer agrees.

An install from before the standard pages existed adds them with Add standard pages on Content > Content types. It only adds what is missing, so it is safe to use again, and it adds nothing when a type of your own already uses the slug info. On an Info Pages type made by an earlier version it also adds the standard fields the type lacks (Info boxes), after your own fields; the button shows until the type has them. It never changes a page that exists, so an existing Contact page keeps its look until you pick Layout: Contact in the editor. A type created before the name Info Pages keeps its own name, Pages; rename it under Content types if you like. Delete a page you do not need, or leave it unpublished.

How publishing works

1. The editor saves the draft to arc_{slug}_drafts and writes a queue item (publish, unpublish or delete) to _publish_queue.

2. The processPublishQueue function (functions/src/publishQueue/processPublishQueue.ts) copies the draft to arc_{slug} with publishedOn set to the time of publishing, adds a version to PublishedHistory, copies translations and updates the search index.

3. It renders the detail page in every language the entry has, the Markdown twin, and the type's list page (and the home page when it shows the type), from the type's template (see Templates). With the seo feature on, it also rebuilds the sitemap, feeds, robots.txt and llms.txt.

4. All files go out as one Firebase Hosting release, through the Hosting REST API. The result is written to the published entry (deployStatus, deployError), which the editor shows. When the entry's own page cannot be built, the rest of the release (list page, sitemap, feeds) still goes out, and the entry is marked failed with the reason rather than deployed.

Hosting serves these files directly. The app's routes /{type} and /{type}/{slug} (src/app/pages/[contentTypeSlug]/) are the fallback: they render the same template in the browser for anything not yet on Hosting, for previews, and when you run the app locally.

To rebuild every published page, the static pages and the SEO files at once, run the seed (it also runs at the end of npm run deploy:dev and npm run deploy:prod):

npm run seed:dev

For production: npm run seed:prod.

Bulk import entries

On a type's entry list, Bulk Import reads the first sheet of an .xlsx or .csv file. It maps columns by header to Title (required), Content, Summary, URL Slug, Tags, Cover Image URL, SEO Title, Meta Description, Canonical URL, Featured, Author and the type's custom fields, and offers a sample file to download. You import as drafts or publish straight away. An author named in the Author column is matched by name, or created. Repeating fields (info cards, gallery, label and value, FAQ, map location) cannot be imported.

For moving whole collections between projects, see Data import and export.

Static pages

A static page is an HTML file in src/custom/site/pages/, such as src/custom/site/pages/privacy-policy.html, served at /p/privacy-policy. One with the same name as an Arc CMS sample in public/_site/pages/ replaces it. It can carry <arc-header> and <arc-footer>, a <title> and meta tags.

• In the app, /p/{name} fetches /pages/{name}.html, adds the site header and footer, and applies the title and meta tags.
• On Hosting, /p/{name} redirects (301) to /pages/{name}.
• The seed builds a finished copy, with header, footer and site stylesheets, at /pages/{name}/index.html for privacy-policy and cookie-policy. That list is fixed in functions/src/pages/seedStaticPages.ts.

The walkthrough is Write static pages.

Extend it

• Change how pages look: give the type its own template folder. See Templates.
• Read content in your own app code: published entries are in arc_{slug} and readable by anyone, so a page in src/custom/ can query them directly. A type with Generate public pages off is the way to keep structured data for an app without generating pages. See Add pages and routes.
• React to publishing in your own function: put a trigger on arc_{slug}/{id} in functions/src/custom/. See Write your own Cloud Functions.
• New field types and changes to the publish pipeline are core changes. See Keep core generic.

What it stores

An entry stores its custom field values in the customFields map, keyed by field key. Full field lists are in Data model.

All deploy with the arccms- prefix. See Cloud Functions.

Who can do what

The Content admin screens are admin only. See Roles and claims.

Troubleshooting