Multi-brand checklist #

This page is for project leads, brand owners and administrators who add a brand to an installation that already runs other sites. Copy it into your project tracker and tick it off. Every item links to the page that explains it. The checklist assumes the decisions on Planning several brands have been taken.

Contents #

1. Decisions
2. Build
3. Content and teams
4. Links and languages
5. Operations
6. Launch day
7. The first month

Decisions #

• To do: The brand has a named owner who approves content and the launch.
• To do: One installation was chosen deliberately; the trade-offs (upgrades together, restores together, shared load) are written into the plan (One installation or several).
• To do: What the brand shares with the others, and what it keeps apart, is decided (Deciding what to share).
• To do: Address scheme chosen: own host, path below another brand, or both (How visitors reach a brand).
• To do: Languages of the brand decided (Multilingual checklist).

Build #

• To do: A folder for the brand exists under the content root.
• To do: The brand's siteaccess(es) exist, with site name, address, start page, root node and design (Step by step: a second site).
• To do: The siteaccess is registered and matched (host map or path).
• To do: The brand's design is in its own extension, with no theme files edited in place (A design per brand).
• To do: Per-brand settings live in the brand's site extension where possible (Settings, logs and caches per site).
• To do: The administration knows the new siteaccess (SiteList[]), so previews work.

Content and teams #

• To do: Start page, menu folders and legal pages (imprint, privacy notice, terms) are published.
• To do: Shared content is placed or related, not copied.
• To do: Shared folders, users and media are marked always available where the brand uses other languages.
• To do: Editors of the brand have a role limited to its folder; central teams keep their own rights (Keeping teams in their brand).
• To do: An approval workflow is in place if the brand's content must be approved (Workflows).

Links and languages #

• To do: ezurlmultisite lists the new brand with the node id of this installation (Links between your sites).
• To do: Links from other brands into the new one, and back, open the right site (tag pages, search, related items).
• To do: If the brand has several languages: the language switcher links each page to the same page in the other language (Language switchers and addresses per language).

Operations #

• To do: DNS for the brand's host names points to the server.
• To do: Certificates cover every host name (Going live: hosts, HTTPS and siteaccesses).
• To do: Logs and caches of the brand go where the administrator expects; retention is agreed.
• To do: Monitoring checks the brand's address, not only the main brand's (Health checks and uptime).
• To do: The backup covers the brand, and everyone understands a restore restores all brands.
• To do: Caches are warmed for the new brand before announcing it (Preloading caches).

Launch day #

• To do: INI cache cleared after the last settings change; under Velocity, Velocity restarted.
• To do: The brand's start page answers 200 over HTTPS at every address.
• To do: A test order, form or sign-up works if the brand has one.
• To do: The other brands still look and behave exactly as before.
• To do: Sitemaps and feeds of the brand point to its own address (Sitemaps, Feeds and syndication).

The first month #

• To do: The brand's error log is read weekly (Reading logs without shell access).
• To do: Broken links are checked (Broken links and content checks).
• To do: The brand owner confirms that editors can work without help.
• To do: Lessons learned are added to this checklist for the next brand.

Related pages #

• Several brands on one installation
• Planning several brands
• Planning multisite and multilingual projects: checklists
• Launch checklist for websites
• Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.