Minn\Front

The Minn bar on the public site: the same server-rendered chrome the app ships (assets/js/bar.js and assets/css/bar.css from the bundle), built here for a signed-in reader who can edit. There is no other bar and no other admin on the engine, so it is on for everyone who passes the edit_posts gate; the app's per-person opt-in does not apply.

The archives an address may stand for, as the reference answers them: the front, a search, a term's (a category's, a tag's, a plugin taxonomy's), an author's and a date's. Each is the archive when what it names exists (a term by its path's last slug, a valid date; an author's for any name); whether its page has posts is the main query's to say, and an empty page past the first, or an empty date, is the 404 it decides (Theme\FrontLifecycle::handle404).

The archive periods wp_get_archives lists: months, years, days and weeks that hold a published post of a type, newest first, each with its post count and archive URL, plus the post-by-post and alphabetical listings. Labels come from the caller's date formatter so the site's locale and week start apply; the week label joins the week's first and last day.

The engine's own static assets, served under a reserved path.

The addresses an attachment's page answers to besides those its rules find (Front\RuleTable: a loose one by its slug at the top, any by its slug under another address, "attachment/" between or not): by id or slug in the query (?attachment_id=, ?attachment=), and as a post (?p=, ?page_id=), which moves to its own page. With attachment pages off (wp_attachment_pages_enabled, the default) every address moves to the file itself; with them on, one that is not its own moves to its page. An attachment is readable as its parent is.

One month as the calendar widget and block draw it: a table whose caption names the month, whose head lists the week from the site's first day, and whose cells link the days a post was published on to that day's archive; today's cell carries the id the stylesheet lights; the nav below links the nearest months with posts on either side. Markup, whitespace and the attribute order of the two padding cells follow the reference byte for byte, since themes style the table by those hooks.

The words a calendar prints: weekday names Sunday first, the short form each column shows (an initial or an abbreviation), month names by number, and the abbreviation the month navigation uses.

Where a URL should redirect to, by the engine's own resolution: the canonical form of a request (trailing slash, `?p=` to permalink, doubled slashes, former slugs). The front controller applies this before any plugin runs; the `redirect_canonical()` facade asks it again for a URL a plugin names.

wp-comments-post.php: the comment form's target. The reference's answers, captured: 302 to the comment's anchor (with unapproved and moderation-hash when held), plain pages with 200 for a missing field, 403 when comments are closed, 409 for a duplicate, 429 for posting too quickly, and 405 for anything but POST.

The site logo a theme prints, as get_custom_logo builds it (probe plugin-helpers): the custom_logo theme mod's image at full size, never lazy, its alt its own or else the site's name, linked home (marked the current page on the front page). A theme that unlinks the home page logo gets a plain span there, the image then decorative (an empty alt). The image's attributes go through get_custom_logo_image_attributes and the whole through get_custom_logo; no logo is an empty string, or in the Customizer a hidden placeholder it can fill in.

The parts of a post's embed card the reference's embed template prints, as markup: the featured image and its shape (the widest of the image's sizes; wide enough and it sits above the title, else beside it, both by filter), the site's name and icon, the comments and sharing buttons, and the sharing dialog (its ids the post's and a random number, as on the reference). The facade's template tags print them.

The feeds, wherever a request asks for one: the feed var of the rule its address matched (the site's at /feed/, the comments' at /comments/feed/, a post's or an archive's after its address, a plugin's own) or ?feed= on any page. Each is WordPress's feed lifecycle: the main query with the feed asked for, then do_feed, whose handler prints the feed and its content type. A feed of something the address names but the site does not have is an empty feed, as the reference serves it.

The template tags a feed is written with that take more than a line, as the reference answers them in a feed's loop (probe feed-tags): a post's categories and tags in each feed's markup, its enclosures for RSS and Atom, the link to its comments feed, the feed's build date, and the site icon a feed carries.

The feed templates do_feed_* loads, written from the reference's output (suite feed-hooks, probes feed-templates): RSS 2.0, Atom, RDF and RSS 0.92 for posts, RSS 2.0 and Atom for comments. Each is written through the template tags, so every feed filter has its say, and fires each feed action where the reference fires it; the whitespace between is the reference's. A template is written once a request, as require_once loads it, and sends its content type through the header callback first.

A feed as it is written: text as given, and what each template tag and action prints, in the order the template asks for them.

The public site. One catch-all route: resolve the URL, then either redirect or render, through the active block theme when there is one, the classic PHP template runner when the theme is classic, and the interim template otherwise.

What a public URL resolved to.

The prev/next links a paged listing prints: which page sits either side of the one being read, and the anchor that points at it. Posts listings and comment threads both come through here; only the URL builder differs.

Maintenance mode, as hosting tools and updaters switch it on: a .maintenance file in the webroot whose $upgrading is less than ten minutes old. While it holds, every request gets the site's own maintenance.php (which prints its page and stops) or the 503 page; an older file is ignored.

The links between the pages of a post split with <!--nextpage-->, as wp_link_pages writes them (probe placeholders-a). By number: the before markup, each page (the current one a span, unless the whole post is not being shown and this is its first page) after a space for the first and the separator for the rest, the after markup. By next and previous, only where the whole post is shown: the previous page's link, the separator, the next page's. Nothing for a post in one page.

Numbered page links in the reference's shape: previous, the end and middle runs with one ellipsis per gap, the current page as a span, next.

Builds public URLs from the site's permalink structure. With an empty structure every link is a query-string form (?p=, ?cat=); with a structure, published and private posts get their pretty form and every other status keeps the query form, which is what the reference emits.

A post as other sites embed it, the oEmbed provider side, as the reference answers (probe oembed): the data (version, the site as provider, the author or else the site, the title) through oembed_response_data, whose default makes it "rich" with the embed markup: a blockquote linking the post, a sandboxed iframe of its /embed/ page carrying a fresh secret, and the inline script that sizes it. Only a publicly viewable post is embeddable; the width is held between 200 and 600 (oembed_min_max_width) and the height is a 16:9 share of it, at least 200.

The links to the posts either side of this one, and the nav block that wraps them. The caller's format wraps the anchor: `%link` is the whole anchor, `%title` the post's title and `%date` its date, and the anchor carries rel="prev" or rel="next".

Titles arrive already filtered; this only assembles.

A response WordPress's handlers print themselves (a sitemap, robots.txt), as the reference serves them: the main query stood with the request's own variables and the front-end steps around it, then $print; what was printed, under the status and headers the handlers sent. A handler that ends the request early (Printed, where the reference exits) ends it here too; when none did and there is nothing to print, null, and the theme renders the page on the query as it stands.

The surface monitors, crawlers, and hosting checks hit that is not a page: robots.txt, the XML-RPC and cron endpoints, the admin entry point, and the favicon. Feeds and sitemaps have controllers of their own.

Where the root's archive query forms move under pretty permalinks, as the reference's canonical redirect answers them (suite permalinks): a feed (?feed=) first, then a date (?m=, ?year=), then an author by id, then a term when the query names exactly one taxonomy (?cat= or ?category_name=, ?tag=, ?taxonomy= with ?term=, a registered taxonomy's own var; ?post_format= counts as one but never moves itself), each to its pretty address with the other arguments along. Nothing moves while a search is asked for (?s=, even empty), past the first page, or to something the site does not have. The singles' forms are SingleQueries'.

Whether a resolution may answer with a canonical redirect. A GET or HEAD follows them (the trailing slash, the pretty permalink for ?p=, the guessed destination); any other method holds and resolves the path as typed, as the reference's redirect_canonical bails on a POST.

The interim public theme: one clean template until the block-theme reader lands. The body-class tokens are the contract (stylesheets and crawlers key off them); the markup around them is engine-defined.

The query vars the reference's request parse sets for an address (WP::parse_request), which plugins read off $wp->query_vars and get_query_var: each public var the query string or form carries, else the one the matched rewrite rule set (Front\RuleTable), all in the public vars' order (a plugin's own after the core ones); a post type's own var brings post_type and name; a path no rule matches is error=404 (the query string's error is ignored).

The outcome of resolving a public URL: which kind of thing it names, the record behind it, the page number for paginated views, and the query vars of the rewrite rule the address matched (what the request parse hands plugins). Redirects carry their target instead.

Turns a public URL into a Resolution the way the reference's request parse does: the root by its query string, any other path by the first of the site's rewrite rules it fits (Front\RuleTable), whose query vars name what it is (Front\RuleRoutes). What is left here are the reference's canonical answers around that (redirect_canonical, wp_old_slug_redirect):

- Unpaged content and archives without a trailing slash redirect to the slashed form, as typed (case kept), as do an embed's and an endpoint's addresses; paged views, search, and 404s do not. - Query-var forms redirect to the pretty form when the target is public: a single's (?p=, ?page_id=, ?name=, ?pagename=; SingleQueries) and an archive's (?m=, ?year=, ?author=, one taxonomy's term; QueryMoves), unless a search is asked for. - A single asked for under a category it is not in (where the structure names one), or with an old-style page number, moves to its own address; a trackback address goes to the post; the front page answers only at the root. - A name the site no longer has: the post that used to have it, else the closest published page or post whose name starts with it, pages before posts, newest first. Archives never guess. - Non-public posts are 404 to anonymous readers and served to a reader who can edit them.

What a matched rewrite rule's query vars name, as the reference's main query reads them (suites permalinks, plugin-rules, request-vars): a post or page by id, an attachment by name, a page (or an attachment) by its path, a post by name (of the type the vars give), a registered type's item by its own var; else a search, a category's, tag's, post format's or registered taxonomy's archive, an author's, a date's, a post type's; else the front. A rule that set error is a 404, as is a single the reader may not read. Under a name the date or category the rule also captured does not narrow the find: where the post really lives is the canonical redirect's business.

An address read as WordPress's request parse reads it (suites permalinks, request-vars, plugin-rules): against the site's rewrite rules (made and stored when there are none, a plugin's own among them, each place's endpoints too), the first rule the address fits winning, as typed or decoded; a page's rule fits only when a page stands at the path it captured, under verbose page rules. A match is the rule's query vars with the matches put in. Which of them count is the request parse's business (the public vars, after the query_vars filter).

The addresses a single answers to besides its own, as the reference treats them: a slug the post used to have (alone, with a page number, or with an embed or trackback suffix), and an address that puts it under a category it is not in.

The single a query string asks for, as the reference's request parse and canonical redirect answer it: by id (?p=, ?page_id=, any viewable type's; an attachment's goes to its own page), an attachment by id or slug (?attachment_id=, ?attachment=), a post by slug (?name=), a page by path (?pagename=). With canonical redirects on, an address that is not the single's own moves there, the other query arguments along; without, each var is strict about the type it finds.

The sitemap index, its pages, and the two stylesheets, as the reference serves them: the request's sitemap variables stand in the main query and the sitemaps server answers at template_redirect (SitemapRequest), through every filter a plugin hooks, any provider it registers among them; what it does not print, the theme renders (a 404, or the page a stray address amounts to).

A sitemap request at template_redirect, as the reference's sitemaps server answers it: a sitemap address asked for another way (the query form, page 0) moves to its own; with the sitemaps off, a provider nobody registered, or a subtype or page that has nothing, the request is a 404 the theme renders; otherwise the stylesheet, the index or the provider's page is printed and the request ends. Since 7.1.3 this is where a sitemap page is judged: the main query no longer makes an empty page a 404 first, so a page a plugin fills past the page count still prints.

The two sitemap documents, index and URL set, from entry maps; one builder for the engine's routes and the facade's renderer. An element with nothing inside closes itself, at every level, as the reference's XML writer prints it (probe sitemap-classes).

What the sitemaps share with WP_Sitemaps, which serves them: the two stylesheets browsers get when they open a sitemap, their CSS (wp_sitemaps_stylesheet_css filters it), and the date form an entry's lastmod takes.

A term's parent chain and the tag cloud, built from term rows the caller already fetched and links the caller resolves. The category list and select are the walkers' (Walker_Category, Walker_CategoryDropdown).

WP_Admin_Bar's markup, piece by piece, as the reference prints it (probe admin-bar): the wrapper (a skip link until the page has opened its body, a class for phones), a group's list (named by the menu it opens from), and an item: a link or an empty div, its focus order, its attributes from meta, an arrow when it opens a menu below the top level, and any markup a plugin hangs after it.

The nodes WordPress puts on the toolbar itself, as the reference adds them on the front end for whoever is signed in (probe admin-bar): the account menu, the WordPress menu, the site menu with its appearance group, the site editor and customizer links, updates, comments, new content, the edit link for what the page shows, the shortlink, the secondary groups, and the search box. Each is one admin_bar_menu callback, so plugins can unhook any of them by name.

WP_Admin_Bar's nodes bound into the tree they print as, as the reference binds them (probe admin-bar): each gains its children and its type; an item's children go into its "-default" group, made when the first one arrives; a group inside a group sits next to it in a "-container", put where the outer group was; a node whose parent is missing is left out. The bar's own node accessors are used throughout, so a subclass that overrides them still sees every node it is asked for.