[Website] Prevent Query API defaults from overriding login info provided by the Blueprint #2871

bgrgicak · 2025-11-06T06:17:42Z

Motivation for the change, related issues

As reported in #2872 the Playground website will override the login step and shorthand when applying Query API overrides.

The default behavior of the Query API is to set the login shorthand to true, but the override doesn't check if the Blueprint already provides a login step or shorthand. This behavior results in the user being unable to use the login step and shorthand on the Playground website, except if they explicitly set ?login=no in the Query API.

Implementation details

This PR addresses the issue by prepending the default login step to the steps array instead of appending it to the end. By prepending it, the login steps provided by the user will override the default login step.

The login step only defines the PLAYGROUND_AUTO_LOGIN_AS_USER const, we can have multiple, because each step overrides the definition of the previous step. (login step code).
On the first page load, a mu-plugin detects the const and logs in the user defined in that const (login code).
Because of that, it doesn't matter how many times we call the login step, login will be executed once.

Testing Instructions (or ideally a Blueprint)

CI

Manual testing

Checkout this branch
Open this Playground website link
Once Playground loads you should be logged in as the Demo User

…ded by the Blueprint

Copilot

Pull Request Overview

This PR prevents the login query parameter from overriding login configurations that are already defined in a blueprint. The change adds logic to check for existing login configurations before applying the query parameter default.

Adds detection for existing login steps in the blueprint's steps array
Adds detection for existing login shorthand in the blueprint object
Only applies the login=true default when neither form of login is already present

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

packages/playground/website/src/lib/state/url/resolve-blueprint-from-url.ts

…gin-step-isnt-provided

adamziel · 2025-11-06T08:34:19Z

This means explicitly specifying login=yes won't override the Blueprint value. Let's do it a bit differently and only override if the query parameter was explicitly provided.

bgrgicak · 2025-11-06T09:48:30Z

This means explicitly specifying login=yes won't override the Blueprint value. Let's do it a bit differently and only override if the query parameter was explicitly provided.

I implemented it in 5834f58, but I'm not sure that this is the best solution.

My concern is this scenario. The Blueprints says login as Demo and the Query API says login. I would expect that _login as Demo_ + _login_ = _login as Demo_, but now it results in _login as admin_.

adamziel · 2025-11-12T15:19:55Z

My concern is this scenario. The Blueprints says login as Demo and the Query API says login. I would expect that login as Demo + login = login as Demo, but now it results in login as admin.

?login=yes basically means "log me in as admin" so that's the expected behavior. ?login=no means "don't log me in". Lack of the ?login query parameter means "do whatever the Blueprint do". While I agree ?login=yes could potentially confuse someone reading it as "log me in, either as admin or as the user specified in the Blueprint", that particular complaint never came up.

adamziel · 2025-11-12T15:24:04Z

packages/playground/website/src/lib/state/url/resolve-blueprint-from-url.ts

+	const shouldSetLoginToTrue = () => {
+		/**
+		 * Allow the Query API to explicitly set login
+		 * if the login query param is provided.
+		 */
+		if (query.get('login') === 'no') {
+			return false;
+		}
+		if (query.get('login') === 'yes') {
+			return true;
+		}
+
+		/**
+		 * Set login to true by default in the Blueprint
+		 * only if it doesn't already contain a login step or shorthand.
+		 * Otherwise, the login provided by the blueprint would be overridden.
+		 */
+		if (
+			blueprint.steps?.some(
+				(step) =>
+					step && typeof step === 'object' && step?.step === 'login'
+			)
+		) {
+			return false;
+		}
+		if (blueprint.login !== undefined) {
+			return false;
+		}
+		return true;
+	};
+	if (shouldSetLoginToTrue()) {
 		blueprint.login = true;
 	}


How about this?

Suggested change

const shouldSetLoginToTrue = () => {

/**

* Allow the Query API to explicitly set login

* if the login query param is provided.

*/

if (query.get('login') === 'no') {

return false;

}

if (query.get('login') === 'yes') {

return true;

}

/**

* Set login to true by default in the Blueprint

* only if it doesn't already contain a login step or shorthand.

* Otherwise, the login provided by the blueprint would be overridden.

*/

if (

blueprint.steps?.some(

(step) =>

step && typeof step === 'object' && step?.step === 'login'

)

) {

return false;

}

if (blueprint.login !== undefined) {

return false;

}

return true;

};

if (shouldSetLoginToTrue()) {

blueprint.login = true;

}

// Override the `login` property if explicitly requested:

if (query.get('login') === 'yes') {

blueprint.login = true;

} else if(query.get('login') === 'no') {

blueprint.login = false;

}

That's much cleaner, but with it login defaults to false. Do we want to change the default login value?

Now, if you go to http://127.0.0.1:5400/website-server/?php=8.3, the user won't be logged in, while before the change, they would be.

Opening Playground without any query arguments would still login the user because we apply the welcome Blueprint by default.

Ah, good point! Then let's initialize that default Playground-provided Blueprint with login: true – I've just proposed another suggestion above.

Does that mean if I:

add "login": false to my blueprint.json for my plugin SVN; and

have my own "login" in "steps" with specific non-admin user.

Then the resulting Live Preview would have the non-admin user login instead of admin?

Then let's initialize that default Playground-provided Blueprint with login: true

If we do that, opening Playground with /#{"landingPage":"/wp-admin/"} would end up at the login screen because the user wouldn't be logged in by default. While today it logs in the user and loads wp-admin.

@adamziel check out my last commit 0730056. By prepending the default login step instead of appending it to the steps array, we allow Blueprints to override it.

Then the resulting Live Preview would have the non-admin user login instead of admin?

Unfortunately no. If you add login: false to the Blueprint, it would be overridden by the Query API to true.
You can test it with this Playground link.

@bgrgicak: Is there anyway I might use the Live Preview to allow preview of the plugin with non-admin user?

I assume although this PR was inspired by #2872, this won't be a solution to it in the end.

I updated implementation details to match the new approach and explain why we can have multiple login steps and why it won't cause multiple login attempts.

I assume although this PR was inspired by #2872, this won't be a solution to it in the end.

@yookoala it should solve your issue, I'm using your Blueprint in testing instructions :)

@bgrgicak this is a pretty cool approach 👍

adamziel · 2025-11-18T23:26:13Z

packages/playground/website/src/lib/state/url/resolve-blueprint-from-url.ts

 		// via the hash fragment (#{...}) or via the `blueprint-url` query param.
 		return {
 			blueprint: {
 				plugins: query.getAll('plugin'),


Suggested change

login: true,

plugins: query.getAll('plugin'),

See #2871 (comment)

…ername is provided test

…gin-step-isnt-provided

[Website] Prevent Query API defaults from overriding login info provi…

d4a1232

…ded by the Blueprint

bgrgicak requested a review from Copilot November 6, 2025 06:17

bgrgicak self-assigned this Nov 6, 2025

bgrgicak added [Type] Bug An existing feature does not function as intended [Aspect] Website [Package][@wp-playground] Website labels Nov 6, 2025

bgrgicak mentioned this pull request Nov 6, 2025

Login with a different user doesn't seem to work #2872

Closed

bgrgicak linked an issue Nov 6, 2025 that may be closed by this pull request

Login with a different user doesn't seem to work #2872

Closed

Copilot AI reviewed Nov 6, 2025

View reviewed changes

packages/playground/website/src/lib/state/url/resolve-blueprint-from-url.ts Outdated Show resolved Hide resolved

Check if step exists

85404d9

bgrgicak marked this pull request as ready for review November 6, 2025 06:42

Merge branch 'trunk' into update/393-apply-login-query-override-if-lo…

1a5ef99

…gin-step-isnt-provided

bgrgicak requested a review from a team November 6, 2025 06:42

Allow login=yes to override Blueprint login step and shorhand

5834f58

adamziel reviewed Nov 12, 2025

View reviewed changes

adamziel reviewed Nov 18, 2025

View reviewed changes

bgrgicak added 3 commits November 19, 2025 06:00

Add should login a non-admin user if a login step with a non-admin us…

1e8cc53

…ername is provided test

Prepend the default login step to allow Blueprints to override it

0730056

Merge branch 'trunk' into update/393-apply-login-query-override-if-lo…

16729c6

…gin-step-isnt-provided

adamziel merged commit dd3a67f into trunk Nov 19, 2025
32 checks passed

adamziel deleted the update/393-apply-login-query-override-if-login-step-isnt-provided branch November 19, 2025 10:43

[Website] Prevent Query API defaults from overriding login info provided by the Blueprint #2871

[Website] Prevent Query API defaults from overriding login info provided by the Blueprint #2871

Conversation

bgrgicak commented Nov 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Motivation for the change, related issues

Implementation details

Testing Instructions (or ideally a Blueprint)

Manual testing

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull Request Overview

Uh oh!

Uh oh!

adamziel commented Nov 6, 2025

Uh oh!

bgrgicak commented Nov 6, 2025

Uh oh!

adamziel commented Nov 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

adamziel Nov 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

bgrgicak commented Nov 6, 2025 •

edited

Loading

adamziel commented Nov 12, 2025 •

edited

Loading

adamziel Nov 18, 2025 •

edited

Loading