Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[faustwp] WordPress URL validation fail when both front-end URL and WP URL are on localhost #1884

Open
1 task done
miacias opened this issue May 10, 2024 · 2 comments
Open
1 task done

Comments

@miacias
Copy link

miacias commented May 10, 2024

Description

Version Upgrade Bug Scenario

After starting a project using the Faustjs.org Getting Started npx command,

npx create-next-app \
    -e https://github.com/wpengine/faustjs/tree/canary \
    --example-path examples/next/faustwp-getting-started \
    --use-npm

connecting it to a LocalWP Atlas spin up (Local v9.0.2+6676; Atlas Add-on v1.7.2), and then deleting /node_modules and package-lock.json files and upgrading Next to v14, Faust to v3, and React and react-dom to v18, Faustjs no longer functions as intended. On startup npm run dev, the app crashes with this error:

error - Validation Failed: Your Faust front-end site URL value is misconfigured. It should NOT match the NEXT_PUBLIC_WORDPRESS_URL.

Error message

The front end Node environment runs on localhost:3000 and LocalWP environment runs on localhost:10010. There is no code, regex or otherwise, within Faustjs validateNextWordPressUrl.js that actually compares the front end Node URL and the WP URL, so the error message implying that the two URLs match is somewhat misleading. There is some other cause to the Bad Request that I have unfortunately been unable to identify as of yet.

Environment:

The Local /app directory points to an exterior folder with the Faustjs Getting Started sample project instead of Local's own /app-node folder. In this example, Faustjs starts up with v1 and Next on v12.

The .env.local file in the root of the Getting Started contains

NEXT_PUBLIC_WORDPRESS_URL=http://localhost:10010
FAUST_SECRET_KEY=ThisIsASecret

and the WP Admin Faust Settings page contains Front-end site URL: http://localhost:3000.

Steps to reproduce

Debugging hints

After some testing in Faustjs node_modules, validateFaustEnvVars.js returns status 200 and then passes to validateNextWordPressUrl.js which is returning 400, bad request with no other details.

When updating from older versions to the newer version, this error appears consistently.

Original:

{
  "name": "@faustwp/getting-started-example",
  "private": true,
  "version": "0.1.0",
  "scripts": {
    "dev": "faust dev",
    "build": "faust build",
    "generate": "faust generatePossibleTypes",
    "stylesheet": "faust generateGlobalStylesheet",
    "start": "faust start"
  },
  "dependencies": {
    "@apollo/client": "^3.6.6",
    "@faustwp/cli": "^2.0.0",
    "@faustwp/core": "^2.1.2",
    "@wordpress/base-styles": "^4.36.0",
    "@wordpress/block-library": "^7.19.0",
    "classnames": "^2.3.1",
    "graphql": "^16.6.0",
    "next": "^12.1.6",
    "react": "^17.0.2",
    "react-dom": "^17.0.2",
    "sass": "^1.54.9"
  },
  "engines": {
    "node": ">=16",
    "npm": ">=8"
  }
}

updated (breaking):

{
  "name": "broken-faust-v3",
  "private": true,
  "version": "0.1.0",
  "scripts": {
    "dev": "faust dev",
    "build": "faust build",
    "generate": "faust generatePossibleTypes",
    "stylesheet": "faust generateGlobalStylesheet",
    "start": "faust start"
  },
  "dependencies": {
    "@apollo/client": "^3.10.3",
    "@faustwp/cli": "^3.0.1",
    "@faustwp/core": "^3.0.1",
    "@fortawesome/fontawesome-free": "^6.5.2",
    "@fortawesome/fontawesome-svg-core": "^6.5.2",
    "@fortawesome/free-brands-svg-icons": "^6.5.2",
    "@fortawesome/free-regular-svg-icons": "^6.5.2",
    "@fortawesome/free-solid-svg-icons": "^6.5.2",
    "@fortawesome/react-fontawesome": "^0.2.0",
    "@wordpress/base-styles": "^4.48.0",
    "@wordpress/block-library": "^8.34.0",
    "classnames": "^2.5.1",
    "graphql": "^16.8.1",
    "next": "^14.2.3",
    "react": "^18.3.1",
    "react-dom": "^18.3.1",
    "sass": "^1.77.0"
  },
  "devDependencies": {
    "next-secure-headers": "^2.2.0"
  },
  "engines": {
    "node": ">=18",
    "npm": ">=8"
  }
}

After reverting Faustjs to v1.2.0 where the validation does not exist yet (but still keeping Next v14 and React v18 upgrades), the app runs without issue.

Additional context

No response

@faustwp/core Version

3.0.1

@faustwp/cli Version

3.0.1

FaustWP Plugin Version

1.2.3

WordPress Version

6.5.3

Additional environment details

No response

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

  • Yes
@miacias miacias changed the title Inaccurate error message & "Getting Started" to 3.0 Upgrade Bug Misleading error message & "Getting Started" to 3.0 Upgrade Bug May 10, 2024
@theodesp
Copy link
Member

Hey @miacias thank you for the report. The code related to this check is located in the Plugin

https://github.com/wpengine/faustjs/blob/canary/plugins/faustwp/includes/rest/callbacks.php#L550-L575

The code that checks the domain is here:

function domains_match( $domain1, $domain2 ) {

It checks the domains of both the frontend url and WordPress url do not match. I think when both point to localhost it fails. Maybe there should be an exception for localhost or check the ports as well?

A solution for this is to change your Wordpress url to point to a different local domain by changing the /etc/hosts file for localhost to point to a custom domain.

Local does this automatically for us for example:

## Local - Start ##
::1 mysite.local #Local Site
127.0.0.1 mysite.local #Local Site
::1 www.mysite.local #Local Site
127.0.0.1 www.mysite.local #Local Site

@theodesp theodesp changed the title Misleading error message & "Getting Started" to 3.0 Upgrade Bug [faustwp] WordPress URL validation fail when both front-end URL and WP URL are on localhost May 13, 2024
@miacias
Copy link
Author

miacias commented May 13, 2024

I agree that a quick workaround this bug would be to swap out the WP URL, but I fully agree that there should be a localhost exception made, especially because it is no longer backwards compatible. Thanks for pointing me to the right code snippet!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants