apps/meteor/app/wordpress/server/lib.ts (1)

9-18: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Rebuild the OAuth config on each refresh.

config is now a long-lived Partial, and this refactor no longer clears mode-specific fields. If an admin switches from custom or wordpress-com back to another server type, stale tokenPath, authorizePath, scope, or identityTokenSentVia values remain on the shared object and are written back through $set, so the next login can keep using the previous provider's endpoints.

Suggested direction

-const config: Partial<OAuthConfiguration> = {
+const baseConfig: Partial<OAuthConfiguration> = {
 	serverURL: '',
 	identityPath: '/oauth/me',
 
 	addAutopublishFields: {
 		forLoggedInUser: ['services.wordpress'],
 		forOtherUsers: ['services.wordpress.user_login'],
 	},
 	accessTokenParam: 'access_token',
 };
 
 const fillSettings = _.debounce(async (): Promise<void> => {
-	config.serverURL = settings.get('API_Wordpress_URL');
-	if (!config.serverURL) {
-		if (config.serverURL === undefined) {
+	const serverURL = settings.get('API_Wordpress_URL');
+	if (!serverURL) {
+		if (serverURL === undefined) {
 			return fillSettings();
 		}
 		return;
 	}
+
+	const config: Partial<OAuthConfiguration> = {
+		...baseConfig,
+		serverURL,
+	};

You'll also want the persistence step to replace or explicitly unset keys that are no longer applicable; otherwise omitted fields can survive in ServiceConfiguration.

Also applies to: 20-64, 68-74

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@apps/meteor/app/wordpress/server/lib.ts` around lines 9 - 18, The current
module-level `config: Partial<OAuthConfiguration>` is reused across refreshes
and retains mode-specific fields (like `tokenPath`, `authorizePath`, `scope`,
`identityTokenSentVia`) causing stale provider endpoints; change the code to
build a fresh OAuth config object inside the refresh/build function (instead of
the shared `config` variable) so each refresh computes fields based on the
current `serverType`, and when persisting to `ServiceConfiguration` explicitly
replace the stored object or unset keys that are no longer applicable (do not
merge into the old object). Locate and update the code that reads/writes
`config` (symbols: `config`, `OAuthConfiguration`, and the refresh/persist
function that calls `$set`) to construct a new config per refresh and ensure
persistence uses a full replace or explicit null/unset for removed keys.

apps/meteor/app/wordpress/server/lib.ts (1)

10-19: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Rebuild the OAuth config per fillSettings() run.

This shared mutable object can carry identityTokenSentVia, authorizePath, tokenPath, and scope from a previous server type into the next one. For example, after a wordpress-com run, switching to custom without all custom paths set will keep the old wordpress.com endpoints.

💡 Suggested fix

-const config: Partial<OAuthConfiguration> = {
+const baseConfig: Partial<OAuthConfiguration> = {
 	serverURL: '',
 	identityPath: '/oauth/me',

 	addAutopublishFields: {
 		forLoggedInUser: ['services.wordpress'],
 		forOtherUsers: ['services.wordpress.user_login'],
 	},
 	accessTokenParam: 'access_token',
 };

 const serviceKey = 'wordpress';

 const fillSettings = _.debounce(async (): Promise<void> => {
+	const config: Partial<OAuthConfiguration> = {
+		...baseConfig,
+	};

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@apps/meteor/app/wordpress/server/lib.ts` around lines 10 - 19, The shared
mutable const config is reused across runs and can retain properties
(identityTokenSentVia, authorizePath, tokenPath, scope, etc.) from previous
providers; update fillSettings() to create a fresh OAuth configuration object
for each invocation (or clone a pristine base) instead of mutating/importing the
module-level config, and explicitly reset or omit identityTokenSentVia,
authorizePath, tokenPath, scope (and any other provider-specific fields) before
applying new provider settings so previous endpoints/values (e.g.,
wordpress-com) cannot leak into subsequent runs.