Setting Up a Rule
A rule is one row and a handful of decisions that are awkward to revisit.
Where to find it
Architect Panel → Configuration:
- Friendly URLs — the rules that generate readable addresses
The root path
The segment every generated address sits under. Short, lower case, plural, and describing the thing — products, articles, jobs.
Avoid anything that looks like a file or a system path, and avoid words you might want for a real page later.
The source field
The field the readable part comes from. Choose one that is:
- Meaningful — a person should recognise what the page is from the address.
- Stable — renaming a record changes its address.
- Reasonably short — a long address is truncated everywhere it is displayed.
The space replacer
A hyphen conventionally. Underscores work but read less well and are treated differently by some search engines. Whatever you choose, be consistent across every rule on the site.
The destination prefix
Where the friendly address actually points — the real page with its parameter. Get this right first, because every generated path uses it, and a wrong prefix means every address in that rule resolves to the wrong place.
Nesting
Where the datastore has a parent field, naming it produces hierarchical addresses. Worth doing where the hierarchy is meaningful to a reader and worth skipping where it is only meaningful internally.
Test with awkward records
Not with a tidy example. Try a record whose name has an apostrophe, an ampersand, an accent, a very long name, and one that duplicates another. Those four cover nearly every generation problem.
Check what an existing record generates
Rules apply as records change, so an existing record does not necessarily have a path until it is next saved. Confirm what your existing data produces rather than assuming the rule applies retrospectively.
Renaming breaks links
The consequence people forget. A record renamed gets a new address, and the old one stops working — for bookmarks, for e-mails sent last month, and for search results.
Where addresses matter commercially, treat renaming as a decision rather than an edit.
Worked example
A site created a products rule under a short root with hyphens and the product name as the source, tested with a name containing an ampersand and a duplicate, and confirmed the destination prefix before enabling it. Product renaming was made a two-person decision because of the link breakage.
Recommendations
- Short, plural root paths that will not clash with real pages.
- Hyphens, consistently, across every rule.
- Test with awkward names, not tidy ones.
- Treat renaming as breaking a link, because it is.