Crypto30x

Forum Replies Created

Viewing 2 replies - 1 through 2 (of 2 total)
  • Forum: Developing with WordPress
    In reply to: Problem Registering External API Key with Custom Plugin
    Crypto30x

    (@crypto30x)

    9 months, 1 week ago

    Hi @deenjames,

    Great work on setting up the settings page and getting your plugin to save the API key to the database! Since hard-coding the key works but retrieving it via get_option() doesn’t, the issue likely lies in how it’s being stored or retrieved. What to Check & Next Steps 1. Debug What’s Actually Being Retrieved

    Dump the value you’re getting from the database to confirm what’s being returned:

    $api_key = get_option('my_plugin_api_key'); var_dump($api_key);

    Run this via WP-CLI or inspect the raw HTML output, not just in browser-rendered view — some characters may get stripped or transformed during rendering. This will help reveal if it’s empty, malformed, or nested within an array. ww.wp.xz.cn 2. Ensure Option Name Matches Exactly

    Even a tiny mismatch (e.g., a typo or difference in naming convention) between your register_setting() and get_option() can result in retrieving nothing or unknown values. Double-check that:

    • The option name in register_setting() matches the one in get_option()
    • There are no stray characters or whitespace in the name ww.wp.xz.cn

    3. Check If Option Is Scalar or Array

    If your settings input field uses array naming syntax — for example, <input name="my_plugin_api_key[api_key]" ...> — WordPress will save the option as an array, not a string. In that case, calling get_option('my_plugin_api_key') returns an array, and you’d need to access the API key like this:

    $opts = get_option('my_plugin_api_key'); $api_key = isset($opts['api_key']) ? $opts['api_key'] : '';

    This setup mismatch could definitely cause the “Invalid API key” response you’re seeing. ww.wp.xz.cn Summary Table CheckpointWhat to DoRetrieve & inspect valueUse var_dump() outside of browser-rendered view to see raw dataOption name alignmentConfirm exact match between register_setting() and get_option()Data structure checkDetermine if option is a string or array and handle accordingly

    Once you’ve verified the retrieval and structure, test your API request again with the extracted value. If you’re still seeing issues, feel free to share the relevant snippet of your settings and retrieval code—I’d be happy to help debug further!

    Forum: Developing with WordPress
    In reply to: Block Contains unexpected or Invalid content
    Crypto30x

    (@crypto30x)

    9 months, 1 week ago

    Hi @woracious,

    You’ve clearly put a ton of effort into this — kudos for the thorough setup and troubleshooting so far! Here’s a breakdown of what might be going on and a few approaches you could try: Possible Causes & Troubleshooting Steps

    1. FSE enforces stricter validation than the post editor
    The Full Site Editor (FSE) may process dynamic blocks differently, especially handling self-closing comments like <!-- wp:estylish/estylish-share /--> with more caution. Even if your dynamic block is technically correct, FSE might reject it due to stricter parsing rules or mismatches in expected block structure.

    2. Mismatched registration between JS and PHP
    Double-check that every property defined in your JavaScript — including attributes, supports, and example — aligns exactly with your PHP registration. Even minor differences in default values or attribute naming can trip validation.

    3. Block deprecation or update handling
    Since FSE may load template parts across versions, consider defining deprecated versions of the block that gracefully fallback if the structure changes over time. This often helps bridge compatibility gaps.

    4. html: false isn’t always sufficient
    While setting "html": false in block.json typically suppresses validation errors, FSE sometimes ignores this or applies it inconsistently. You might temporarily toggle this option to see if it fixes the rendering in FSE. Recommended Next Steps

    • Compare serialized output
      Copy the block HTML from a post (where it works), and do the same in FSE. Compare them character by character — whitespace, casing, and encoding can all cause FSE to flag content.
    • Log rendered output visually
      Temporarily add debug output inside your render.php to log or display what the server is outputting. It could point out unexpected inline characters or formatting.
    • Test with a minimal setup
      Create a simplified version of your dynamic block — maybe just a single ToggleControl or even none. If the minimal block validates properly in FSE, you can iteratively add features back to locate the precise trigger.
    • Look into block deprecations
      Define a deprecated version with slightly different markup to satisfy FSE’s expectations. You can list it under deprecations in your block.json.


    • Quick Example of Minimal Block for Debugging
    • // index.js registerBlockType(metadata.name, { ...metadata, supports: { html: false }, save: () => null, edit: () => <div {...useBlockProps()}>Test Block</div>, }); Sample Check in render.php
    • error_log('Estylish block render called'); return '<div class="estylish-share">Rendered correctly!</div>';
    • If FSE still balks at this minimal output, the issue is likely with editor-level expectations.
    • You’re so close — hang tight! Let me know what you discover after trying any of these steps, and we’ll keep narrowing it down until it works seamlessly in FSE.
Viewing 2 replies - 1 through 2 (of 2 total)