Block Not Showing Expected Data

This one is for when a block renders normally, no visible error, correct styling, right place on the page, but what’s inside it isn’t what you expected: empty, wrong, or out of date. If the block isn’t appearing at all, or the shortcode itself looks broken, see Common Issues and Shortcode attribute gotchas instead.

“A field is empty or showing the wrong value”#

The most common cause, by far, is a misspelled or mistyped attribute name, whether you’re writing a shortcode, calling nahnu_code_block_render() / nahnu_code_block_the() / nahnu_code_block_build_block_markup() from PHP, or filtering an OpenAPI-generated block’s attributes. None of these paths error on an unrecognized attribute name. They simply ignore it, and the real attribute quietly falls back to its own block.json default instead, most defaults being an empty string, false, or an empty array, which is why the symptom looks like “missing data” rather than “wrong data.”

Check the attribute name against the actual block registry rather than against memory or an older doc. Each block’s own doc in this documentation set lists its real settings, and INTEGRATION.md in the plugin folder has the complete attribute table for every block. Pay particular attention to exact casing (operationId, not operationid or OperationId) when you’re calling from PHP directly, since PHP arrays are case-sensitive even though the shortcode path recovers correct casing automatically.

If you’re generating attributes programmatically from another data source (an import script, a CMS field mapping), log the actual keys you’re about to pass right before the call, and diff them against the block’s declared attribute list. A silent typo is far easier to catch that way than by staring at rendered output.

“A Parameters row’s schema link doesn’t go anywhere”#

A Parameters row’s “Links to schema” field (typeRef) only resolves if its value is an exact, case-sensitive match for another Parameters block’s own “Schema name” field (schemaName) somewhere on the same page. There’s no fuzzy matching and no cross-page lookup, both blocks have to exist on the page being viewed, and the names have to match character for character.

The usual causes are a typo in one side or the other, a schema name that exists but only on a different page, or a schema block that was removed or renamed after other blocks were already pointed at its old name. Search the page’s block content for the exact schema name to confirm the target block is actually there and spelled the way the linking block expects.

“API Navigation is missing some endpoints”#

This is almost always because of how the block finds Endpoint blocks to list: it calls WordPress’s parse_blocks() on the current post’s content and recursively scans the result for real Gutenberg Endpoint blocks (nahnu-code-block/endpoint block comments). That means it only sees Endpoint blocks that were actually added through the block editor.

An Endpoint placed on the page via the shortcode (block="endpoint") is invisible to this scan. As far as parse_blocks() is concerned, that’s just plain text in the post content, not a parsed block, so it won’t show up in the navigation list no matter how correctly it’s rendering on its own.

If you’re mixing block-editor Endpoint blocks with shortcode-placed ones on the same page and want a complete navigation list, either place every Endpoint through the block editor, or don’t rely on API Navigation’s auto-scan for the shortcode-placed ones and link to them manually instead.

“A shortcode-placed block’s list/table is empty”#

For a block whose main data (parameters, responses, status codes, and similar) is read from the shortcode’s enclosed content rather than a quoted attribute, an empty result usually means the content wasn’t valid JSON by the time the plugin tried to decode it.

With WP_DEBUG off, this fails silently and on purpose: rather than showing broken markup to a site visitor, the block falls back to that attribute’s normal empty default, so the block still renders, just with nothing in that section. With WP_DEBUG on, an HTML comment appears in the page source naming the block and attribute that failed to decode, along with the underlying JSON error, which is almost always faster than guessing.

The most frequent real cause isn’t a hand-written JSON mistake, it’s wptexturize silently converting straight quotes to curly ones somewhere in the content before the shortcode callback ever sees it, which breaks JSON parsing outright. See Shortcode attribute gotchas for the full explanation and the more reliable PHP-based alternative for large or unusual content.

“I made a change but the page still shows the old content”#

This plugin doesn’t cache anything on its own, so once you rule out a typo or a linking mismatch, a stale result after a real edit almost always points to something else caching the rendered page:

• A page/full-page cache (a caching plugin, a host-level cache, a CDN) can keep serving the old HTML after a post is updated until that specific URL is purged. Clear the cache for that page, or wait out its TTL, and reload.
• Browser caching, less commonly, especially if the page was recently viewed. A hard refresh rules this out quickly.
• OpenAPI-generated content specifically: remember this plugin only converts one already-resolved operation into block markup at the moment it’s called. It doesn’t watch the source spec for changes. If you edited the OpenAPI spec itself, whether the resulting blocks update at all, and when, is entirely up to WP Super Docs’ own sync trigger, not something this plugin controls or is aware of. See How the sync works.

If you’re troubleshooting this on a staging or development site, also check whether that environment has its own separate cache or a stale copy of the OpenAPI spec file, distinct from production.

Tips#

• Turn on WP_DEBUG before anything else. Several of the fallbacks above are silent by design in production, but explain themselves in an HTML comment when it’s on.
• Rule out caching early, especially for anything OpenAPI-generated. A five-second cache purge saves a lot of time spent debugging content that was actually already correct.
• When only one field on an otherwise-correct block is wrong, check that field’s exact attribute name first. A near-miss typo is far more common than a genuine plugin bug.
• Compare the block editor’s own preview against the front end. If they show different content, the problem is in rendering or caching, not in the block’s stored data, which narrows where to look.
• If a shortcode-placed block and a block-editor block of the same type behave differently (API Navigation not seeing a shortcode Endpoint is the clearest example), that’s very often expected behavior rooted in how the two placement methods work, not a bug specific to your content.