Minn (root namespace)

Registers the PSR-4 loader for the Minn namespace.

the minn/ folder: the engine's own files

the site root with a trailing slash, as ABSPATH holds it

the WordPress release whose contracts the runtime speaks

The same context with another reader, for a surface that resolves one later.

wp-content under the site root.

The themes folder under wp-content.

Whether the request is over HTTPS.

The SQL modes WordPress turns off for its session (wpdb's incompatible modes): strictness and the modes that change what queries mean.

The most a column of a MySQL type holds, as wpdb::get_col_length answers: characters for char and varchar, bytes for the binary, blob and text types; false for any other type.

The connection the request being answered speaks through: its runtime's own, so nothing deep in a render can reach a connection belonging to another request. With no runtime (the command line, the unit suite) it is the process's own connection.

This is the one place in the core that asks the runtime anything; the alternative is a database door threaded through every renderer, and the seam is here until that threading is done.

The one connection for this process, opened from wp-config's constants on first use, its session without the incompatible modes, as WordPress's own connection is (a plugin's insert that leaves out a text column then succeeds, as it does there).

The session's modes: the server's, less the reference's incompatible ones and NO_BACKSLASH_ESCAPES, which the engine's own literal escaping (Query\Sql) relies on being off. Plugins see only the reference's list (incompatible_sql_modes).

A comma-separated SQL mode list without the incompatible ones (any case).

Sets this session's SQL modes, never NO_BACKSLASH_ESCAPES: the engine's literals escape quotes with a backslash (Query\Sql), which that mode would turn into a plain character, so a set_sql_mode() asking for it gets every other mode it named.

The underlying mysqli handle, for the facade's wpdb.

A value escaped for direct interpolation into SQL, for callers that build their own statements.

The table prefix from wp-config.

`posts` becomes `wp_posts`; the prefix comes from wp-config.php.

Every row of a prepared query, as associative arrays.

The first row of a prepared query, or null.

The first column of the first row, or null when there is no row.

Runs a write and returns the affected row count.

Asks to be told whenever a write statement names a table (Content\RowCache drops what it kept from it).

Tells the listeners of every table a write statement names, whichever door ran it (this one, or the facade's wpdb for plugin code). A name that merely contains another (wp_postmeta for posts) is not it.

Rewrites every "?" whose parameter is a list into that many placeholders, and flattens the values to match, so "IN (?)" becomes "IN (?, ?, ?)". An empty list becomes NULL, which nothing is IN, so a caller that means "everything" when the list is empty says so itself.

Runs a unit of work as one transaction: everything the closure writes lands, or none of it does. The closure's return value is passed back.

A transaction already open is joined rather than nested, since the storage engine has no nested transactions; the outermost call is the one that commits. A table that cannot do transactions (MyISAM, which no WordPress core table uses) silently keeps each write, which is the behaviour there was before this existed.

The id the last INSERT produced.

One option's stored value, or null when it is unset; home and siteurl answer to WP_HOME and WP_SITEURL. Once the runtime boots, the read is its option store's (the autoloaded list, wp_cache's options group), so the engine's own reads cost no query each, as get_option()'s don't.

Where option reads come from from now on: the runtime's option store, or null for the row itself.

What wp-config.php sets for an option, or null: WP_HOME and WP_SITEURL, when defined, stand for home and siteurl on every read, as on the reference (_config_wp_home), without a trailing slash.

One option's row as stored, whatever wp-config.php says, or null when it is unset.

The WordPress release whose contracts the runtime speaks; wp-includes/version.php says the same.

The front door: answer the request that arrived and send it. This is the only place the engine touches the world, so everything under it is a function of a request, callable more than once in a process.

The response for one request, whatever happens: a database that cannot be reached, salts that are not set, or a failure anywhere underneath, each answered in the language the request asked in.

Markup's pieces of HTML: comments and CDATA whole (to the end when unclosed), else from "<" to the next ">".

Markup cut into text and HTML pieces, the HTML ones at the odd positions (wp_html_split): a comment or CDATA section is one piece whatever it holds, and a "<" in text starts a piece that runs to the next ">".

Text escaped for HTML.

Text escaped for an attribute value.

Appends classes to the first element in a fragment (or to the first element already carrying $onClass), adding a class attribute when the element has none. Existing classes keep their order.

Drops script and style elements with their contents, then every other tag; whitespace runs optionally collapse to one space.

A single line of plain text from user input: tags stripped, control whitespace folded, percent escapes removed. The caller passes its own UTF-8 check and less-than encoder so its filters keep applying.

The code inside markup that is exactly one bare script element once the surrounding whitespace is gone, or null for anything else: a tag with attributes, an empty element, a missing end. The tag names match in any case and the code is returned as written.

The network, or $fake answering in its place. With $within, every hop of every request must also start with one of those URL prefixes, whatever a call's own hosts: say (an extension's needs.http).

A client that throws $why at every call: what an extension holds when its minn.json did not ask for http.

A GET.

A HEAD: the status and headers a GET would bring, without the body.

A DELETE.

A POST with a json:, form: or body: payload.

A PUT with a json:, form: or body: payload.

A PATCH with a json:, form: or body: payload.

Sends exactly what the Outbound says, with none of the verbs' rules about where a request may go: the door WordPress's own HTTP API comes through after applying its rules. A client bound to hosts refuses it, since curl follows a sent request's redirects where no rule can see.

Slashes and non-ASCII characters written as themselves: encode()'s default.

Slashes and non-ASCII characters escaped, as wp_json_encode() and the REST API write them.

A value as JSON; invalid UTF-8 is repaired, never a reason to fail.

The value the text holds, objects as arrays; with `or:` given, that comes back instead of an exception.

The value a JSON file holds, objects as arrays; with `or:` given, a missing or broken file gives that instead.

A value with every string and key made valid UTF-8, each invalid byte becoming "?", objects read as plain objects of their public properties.

JSON as arrays, but an empty object stays an object: an in-process REST answer keeps `{}` where the reference's data holds an empty object (a global style's emptied settings), which decoding to arrays would turn into `[]`.

The reference's 404 for a route nothing answers.

The reference's 400 for required parameters that did not arrive.

The reference's 400 for one parameter its schema refuses: the message under params, and under details with the refusal's code and data, as WP_REST_Request::has_valid_params reports it.

A statusless core error as REST serves it: HTTP 500 with data null.

The error as the reference's JSON body: code, message, data.