Menus and addresses
Menus
A menu is a tree of entries, and it belongs to one organization. Each entry can carry an icon, a CSS class and conditions, so the same menu can show different things to different visitors.
The item matching the current page is marked active, and so is its parent chain. Styling that is a matter of CSS, not of building a second menu.
Every firm has its own
A menu's machine name is unique per organization, so every firm has its
own main and its own footer. Nobody has to invent main_acme to get one,
and nobody's menu appears on anybody else's site.
Nothing is shared, and a menu is not an exception
A firm that has no menu of a given name gets an empty menu — never another firm's, and never one belonging to nobody. Somebody gives that firm its own. Inheriting navigation to fill a gap is the shape a leak takes when it looks like a convenience.
A firm is given its main and its footer the moment it is created, so
there is no window in which a site has a header and nothing to put in it.
Both are yours to rename; neither can be deleted, because the site asks for
them by name.
The back office addresses a menu by its identity rather than its name, for
the same reason: with two firms both holding a main, a name cannot say
which one you meant — and the failure that matters is not the error, it is
opening somebody else's navigation believing it was yours.
If your menu is called `acme_main`
It was renamed to main, and any menu block pointing at the old name was
repointed with it. The prefix existed only because the name had to be
unique across the whole installation — and it quietly cost that firm its
navigation, since everything asking for "main" by name never found it.
An entry points at a thing, not at an address
This is the sentence the whole menu system is built on. An entry holds a target — a page, a category or a listing — and the address is looked up when the menu is drawn.
Why it matters
An address is an answer. Answers go out of date; the question does not.
An entry that stored /charts kept saying /charts after the page moved,
and nothing noticed, because nothing knew the entry had meant that page.
What follows from it:
| When | What happens |
|---|---|
| The page gets a nicer address | Every menu follows it. Nobody edits a menu |
| The page is unpublished or deleted | The entry stops rendering, rather than publishing a dead link |
| The page belongs to another organization | It resolves to nothing — the same silence every cross-organization reference gets |
| A visitor is reading in Slovak | The entry links into the Slovak tree |
Use the Address field only when there is nothing to point at: an external site, or a route the platform does not own. An external link stays exactly as you typed it, because it can only be an address.
One menu, every language
Build the menu once. Give an entry a label per language under Label in other languages, and a visitor reads it in theirs.
An untranslated entry reads in its own language rather than leaving a hole in the menu. A label you have not overridden also picks up any translation of that same word from the interface catalogue, so a menu that says "Products" is often translated already.
Do not translate a menu by copying it
It used to be the only way, and the copies drift — one gets an entry the other never does. One entry, many labels.
Entries that do not render
Open a menu in the back office and any entry that cannot be reached is listed at the top, with the reason: its target is not public, it no longer exists, or it belongs to another organization.
They are hidden from visitors, not deleted — an entry nobody can see is an entry nobody can fix. An unreachable entry that has children is kept as a heading, so a working branch does not disappear with its parent.
The reason is named, the other firm's page is not
An entry pointing into another organization says exactly that, and stops there. It does not show you what it was pointing at, because a leaked label is still a leak.
Converting older menus
Entries that stored an address are converted to targets automatically, and the conversion reports what it took and what it left alone. To preview it, or to run it again after an import:
python manage.py menu_adopt_addresses # preview, writes nothing
python manage.py menu_adopt_addresses --apply # convert
An address it cannot place unambiguously stays an address and is named in the report. Two organizations that both use one path is exactly such a case: guessing there would put one firm's page into another firm's navigation.
Addresses
Where a thing lives is answered in one place. An alias an editor typed, a rule that gives a whole content type a pattern, a type whose public page is not the record page — all of them resolve through the same answer.
Never assemble a URL by hand
Not in a template, not in a token, not in a block. A hand-built address is correct until the day the type gains an alias, a pattern or its own kind of page — and then it is quietly wrong, still linking, still returning something. Ask for the canonical address.
An address belongs to a firm
Every organization has its own address space. Two firms on one installation
can both own /kontakt, both own /products, both own /o-nas — each answers
on its own domain, so there is nothing to collide.
Inside one firm an address still names exactly one page; that is what makes it an address. What changed is only the boundary the rule is enforced across.
| Question | Answer |
|---|---|
| Can another firm's page take the address I want? | No. Their address space is not yours |
Can I redirect /kontakt when another firm publishes it? |
Yes. Their live page does not shadow your redirect |
Whose page does a visitor get at /kontakt? |
The one belonging to the site whose domain they typed |
If you had to work around this before
It used to be first-come, first-served across the whole installation: the
second firm to want /kontakt was refused, and the usual workaround was a
prefixed address like /acme-kontakt. Those still work and nothing renames
them — but they are no longer necessary, and a redirect from the old one to
the plain address costs nothing.
Patterns
A content type can be given an address pattern built from its own values —
products/[record:field:category:path]/[record:field:sku], for instance.
Patterns use tokens, so an address can follow a
category hierarchy without anybody maintaining a list.
Redirects
When an address changes, the old one should keep working. Redirects are per site, and a moved page can be sent to its new home permanently or temporarily.
Meta tags
Titles, descriptions, canonical links and social-preview cards, defined per content type with tokens and overridable per record.
Every firm owns its patterns. The Meta tags screen edits the patterns of the firm you have open — it names the firm at the top — and each firm's public pages resolve meta strictly from that firm's own rows. There is no shared tier: a firm that has not set its own patterns gets the built-in smart fallbacks (its own site name and tagline, the record label, the first text and image of the page), never another firm's wording. WHY: on a platform where several firms publish under their own domains, a shared pattern is one firm's marketing on another firm's pages — so sharing is not a default here, it is impossible.
When this separation shipped, every firm received its own copy of the previously shared patterns, so nothing on any live site changed until that firm edited its copy.
A feed and a sitemap follow the same visibility rules as everything else: what is not published is not in them.
Share cards on the built-in pages
The pages the platform ships as code — download, contact (enquiry), cart, cookies, privacy — are
not records, so the meta tags of a record page never applied to them. They now carry the same
share card: og:type, og:site_name, a Twitter card and, as og:image, the site's own raster
mark (the file uploaded on the site, else the firm's branding logo). A link to the download page
shared on LinkedIn or Facebook shows a card, not bare text.
A firm's own words for a static page
Those built-in pages carry the platform's own title and description — the same words on
every firm's site. Meta tags → Static pages gives this firm's site its own: a title and a
description per path (/download/, /gdpr/, /cookies/, /search/, /cart/, the account
pages). Plain words, not token patterns; the Open Graph pair, the canonical address and the
share image follow from them. A page without its own words keeps the platform's. The words
travel in the site payload, so the page is right on the first render, without a second
request.
The firm's profiles in the front page's data
The front page's schema.org Organization node lists the firm's profiles as sameAs: every
absolute link of the site's social menu, in menu order. Fill the social menu (the footer's
icons) and the search engines read the same list — nothing is typed twice.
One address for the enquiry page
The enquiry page answers on /dopyt/ and /contact/. A site has ONE address for it: /dopyt/
when the site's default language is Slovak, /contact/ otherwise. The other path is a permanent
redirect and the canonical tag names the one address, so a search engine never sees two pages.