AxeWP/wp-graphql-headless-login

0.0.9 breaks the "ADDITIONAL AUTHORIZED DOMAINS" form field

ArkDouglas opened this issue · 4 comments

Description

Upgrading to 0.0.9 renders the form field for "additional authorized domains" in the provider settings unusable - any input fields do not display, when a new host is input it dissapears.

Steps to reproduce

  1. Install 0.0.9
  2. Go to graphql > settings > headless login
  3. Scroll down to "Access Control Settings"
  4. Attempt to utilize the "Additional authorized domains" field

Additional context

No response

Plugin Version

0.0.9

WordPress Version

6.2

WPGraphQL Version

1.14.0

Additional enviornmental details

No response

Please confirm that you have searched existing issues in the repo.

  • Yes

Please confirm that you have disabled ALL plugins except for WPGraphQL and Headless Login for WPGraphQL

  • Yes
  • My issue is with a specific 3rd-party plugin.

Hey @ArkDouglas , I'm struggling to replicate this locally.

  1. Any chance you have other plugins enabled (and if so does disabling them fix it?)
  2. Are you seeing any errors in the console log / network request window when trying to save in your browser?
  3. If you enable WP_DEBUG_LOG, does anything get output to debug.log?
  4. How are your other Plugin Options / Access Control settings configured?

1: Disabled all other plugins, still exists
2. No errors in the console or network request
3. My debug.log just gives this error: (using local) [27-Apr-2023 02:35:01 UTC] Xdebug: [Step Debug] Could not connect to debugging client. Tried: 127.0.0.1:9000 (from REMOTE_ADDR HTTP header), localhost:9000 (fallback through xdebug.client_host/xdebug.client_port) :-(
4. I don't have any other access control setting plugins

Could be I have a botched local instance.

If I try it on a different headless instance, the form field doesn't appear (disabled plugins, wordpress 6.1):
image

I spun up a new bigcommerce blueprint on local just to test on a clean instance as well (6.2) and the form also doesn't appear there.

Was able to track this down, and fix in #69. (For some reason my local /build was cached so I was never actually testing those changes 😲)

PS: this issue qualifies for my WPGraphQL Spring Cleaning campaign, where I'm donating dev hours to WPGraphQL projects for every issue/PR opened between now and April 31st. If you're interested, let me know via the link where you want the time donated to.

cc #9