NewMode Form Embed - Action ID Override Problem

We are developing on Radicle Trellis And Kinsta.

Core Problem

The NewMode form embed is failing because the action ID (4175a1a5-374d-4bec-b324-14a104bf7fc6) is being replaced with the page slug (new-mode-test-anders) in the API request URL, causing a 404 error.

Expected URL: https://base.newmode.net/api/v2.0/action/4175a1a5-374d-4bec-b324-14a104bf7fc6/form
Actual URL: https://base.newmode.net/api/v2.0/action/new-mode-test-anders/form

Current Status

  • :white_check_mark: Works in WordPress editor (backend)
  • :white_check_mark: Works locally (development environment)
  • :cross_mark: Fails on Kinsta staging/production (frontend only)

Attempted Solutions

  1. WordPress Service Provider (NewModeServiceProvider.php)
  • Created meta boxes for action ID storage
  • JavaScript injection to dynamically set embed attributes
  • Custom shortcode implementation
  • WordPress filtering bypass attempts
  1. Custom Gutenberg Block (React component)
  • Block with action ID and base URL settings
  • Editor preview functionality
  • Dynamic rendering approach
  1. Alternative Embed Methods
  • WP Code Lite - Failed (same issue persists)
  • Manual script insertion in page templates
  • Direct HTML embedding - Same action ID override occurs
  1. Troubleshooting Steps
  • Disabled plugins to eliminate conflicts
  • Bypassed WordPress content filtering
  • Multiple embed methods tested
  • Custom block creation

Root Cause Analysis

Per NewMode support (Michael), this appears to be:

  • WordPress filtering issue specific to Kinsta production environment
  • Not a plugin conflict (tested with plugins disabled)
  • Not an embed method issue (multiple methods tested, all fail)
  • Environment-specific (works locally, fails on production)
  • Likely related to how Kinsta handles script execution or WordPress filtering at the server level

Next Steps

  1. Investigate Kinsta-specific configurations
  • Contact Kinsta support about WordPress filtering/script handling
  • Review server-level WordPress configurations
  1. Test with ngrok for local CORS testing (as suggested by NewMode support)
  2. Explore server-side rendering approach to bypass frontend filtering entirely
  3. Consider hosting environment change if Kinsta configuration cannot be resolved

Technical Notes

  • NewMode domain is correctly whitelisted
  • Issue persists across all embedding methods (WP Code Lite, custom blocks, manual insertion)
  • Problem occurs during script initialization phase regardless of implementation
  • This points to server-level WordPress filtering rather than plugin/theme conflicts

After some more investigation and speaking to Kinsta support, who found no issue on their end, I found the issue to be the wordpress permalink settings. For whatever reason the link settings are updating the action id to the page slug.

We’re now not seeing the action being updated or the CORS issues, however we’re just getting the below rendering. The form itself is also not rendering in the html at all, it’s only showing the footer.