| 开发者 | ja1me4 |
|---|---|
| 更新时间 | 2026年9月20日 13:10 |
| PHP版本: | 7.4 及以上 |
| WordPress版本: | 7.1 |
| 版权: | GPLv2 or later |
| 版权网址: | 版权信息 |
<html> or <body> (filterable).address parameter with its own line1, city, etc.), linkable type references (e.g. "array of ProgramResponseDto" linking to another Parameters block set up as that named schema), and a copy-link icon on each row for deep-linking to a specific parameter.invalid_request_error / parameter_missing), distinct from HTTP status codes, each with an optional expandable example error body.customer.created), each with a description, an optional expandable example payload, and a copy-link icon.servers array, including server variable templating like {region}.[nahnu_code_block block="..."] shortcode (for widgets, page builders, or classic-editor content) or directly from PHP via nahnu_code_block_render() (for theme templates) — see INTEGRATION.md. Both support the same per-instance color overrides as the settings page.
External services and data
Nahnu Code & API Block does not connect to any external service, API, or CDN at runtime, and does not collect, transmit, or store any personal data. The Prism.js syntax-highlighting library is bundled with the plugin files (MIT licensed) rather than loaded from a third-party server. The Try It Console block is the one exception worth being explicit about: when a site visitor clicks "Send request" on that block, their own browser makes a direct HTTP request to whatever URL is shown in that block (which the page author configured, and the visitor can edit). That request comes from the visitor's browser, not from your WordPress server, and nothing about it is seen by this plugin's author or by Nahnu.
nahnu-code-block folder to /wp-content/plugins/, or install the plugin through the Plugins → Add New screen in your WordPress admin.No. Everything is rendered on your own server and in the visitor's browser. The plugin makes no external network requests, with the one exception noted above for the Try It Console, which is a request the visitor themselves chooses to send.
It's designed to cooperate rather than compete. By default it follows the visitor's OS-level light/dark preference. You can also use the nahnu_code_block_dark_mode_selectors filter to tell it which CSS selector your existing dark-mode plugin toggles (for example body.dark-mode), so the code block switches along with the rest of your site.
Yes. If your theme or plugin already sets a class or attribute for dark mode (like body.dark-mode), add it via the nahnu_code_block_dark_mode_selectors PHP filter and it works automatically, with no JavaScript required. If your toggle is JavaScript-driven, call window.NahnuCodeBlock.setTheme('dark' | 'light' | 'auto') from your own click handler. Full details, including how to rebrand the actual colors, are in HOOKS.md in the plugin folder.
Yes. All colors are exposed as CSS custom properties scoped to .nahnu-code-block (for example --nahnu-code-block-token-string), so they can be overridden from your theme's stylesheet without touching plugin files.
It only ever performs a request from the visitor's own browser to a URL you configure (and the visitor can see and edit before sending). It does not run on, or route through, your WordPress server, so it can't be used to make your server call arbitrary internal or external URLs.
No, not by adding a block through the Classic Editor's UI. You can still
place any block on a Classic Editor page (or anywhere else outside the
block editor) using the [nahnu_code_block block="..."] shortcode, or by
calling nahnu_code_block_render() from a template if you're a
developer — see "Can I render a block from PHP or a theme template?"
below.
Yes. Since version 1.0.2, nahnu_code_block_render( 'endpoint', array( 'method' => 'GET', 'path' => '/v1/users' ) )
(and its echoing counterpart nahnu_code_block_the()) renders any of this
plugin's blocks straight to HTML from a theme template, a widget, or a
page-builder module — no post content or block editor required. The same
thing is available as a [nahnu_code_block block="..."] shortcode for
places that only accept shortcodes. Full details, including how to pass
each block's attributes, are in INTEGRATION.md.
Yes. Settings → Nahnu Code Block has a color picker for each core
color (accent, text, background, header/footer background, muted text,
border) in both light and dark mode — every block on your site picks
these up automatically, however it was added to the page, including
blocks placed with the [nahnu_code_block] shortcode. A single block or
shortcode instance can also override just its own colors (e.g. one
partner-branded endpoint) without changing the site-wide palette — see
HOOKS.md for the shortcode attributes and the equivalent PHP filter.
[nahnu_code_block ...] shortcode syntax (or any other plugin's shortcode syntax) as a properly highlighted, copy-pasteable code sample.do_shortcode(), which runs over the entire rendered page after every block (including this one) has already produced its output — square brackets pass through esc_html() untouched, so a literal [nahnu_code_block ...] example was never actually inert. The code block's displayed brackets are now encoded as HTML entities at the character level, which a browser still renders as ordinary [/] and which the Copy button (reading the browser's own decoded text) still copies as real, directly usable brackets — but which WordPress's shortcode parser can no longer misread as a real invocation. This fixes example shortcodes silently vanishing (or, worse, swallowing surrounding page content) when shown this way; no double-bracket escaping needed.nahnu_code_block_render() (and nahnu_code_block_the(), its echoing counterpart) so a theme or plugin developer can render any of this plugin's blocks directly from PHP — in a template file, a widget, or a page-builder module — without needing the block to live in a post's content or pass through the block editor.[nahnu_code_block block="..."] shortcode wrapping the same rendering path, for widgets, classic-editor content, and page builders that only accept shortcodes.code attribute — now reads that value from the shortcode's enclosed content instead of a quoted attribute. A quoted attribute can never safely hold a JSON array (WordPress's own shortcode parser treats any ] character inside the tag, even deep inside a quoted attribute's value, as the end of that shortcode — corrupting it the moment the array isn't empty), and can't hold real code containing a quote character either.[nahnu_code_block] attribute on every block, not just the ones above: the shortcode handler was normalizing attributes through shortcode_atts() against a list that only ever contained block and the seven color-override names, which meant every other attribute a block actually needed — code, method, path, language, all of it — was being silently discarded before the block ever rendered, on every single shortcode call. On top of that, WordPress always lowercases shortcode attribute names before a callback sees them, which broke every camelCase attribute (operationId, authRequired, relatedOperations, showLineNumbers, and others) independently of the first bug. Both are fixed: every attribute now reaches its block correctly, under its real declared name, regardless of the case it was written in.accentColor, accentTextColor, bgColor, chromeBgColor, textColor, borderColor, mutedColor shortcode attributes, or a third argument to nahnu_code_block_render()/nahnu_code_block_the() — so a single shortcode or PHP-rendered block can carry its own branding without changing the site-wide palette.wp_head() has already printed (the common case for a template file, since it usually runs after get_header()) now still gets its stylesheet, instead of silently rendering unstyled.INTEGRATION.md and HOOKS.md.:hover — are now always visible on touch devices, since touchscreens don't reliably trigger hover states.servers array).address parameter with its own line1/city fields), parameter location (query/path/header/cookie/body, matching OpenAPI's in field), a per-parameter Deprecated flag, and an Allowed-values (enum) field.nahnu_code_block_build_block_markup() — lets another plugin (e.g. a docs platform importing an OpenAPI spec) generate any of this plugin's blocks programmatically, with correct WordPress block markup and sensible attribute defaults. Documented in the new INTEGRATION.md.nahnu_code_block_pre_attributes filter, for third-party plugins that scan the page and inject their own UI into <pre> elements (with a real example for WP Super Docs, which was colliding with this plugin's own copy button and language label).<style> element it's printed inside, following a WordPress.org review finding.