5.6.1 release zip: php-scoper prefixes WordPress globals (WP_User, WP_Error, WP_Object_Cache), causing immediate TypeError on activation

[no2pixel]

Checklist

• I have looked into the Readme and the documentation, and have not found a suitable solution or answer.
• I have searched the issues and have not found a suitable solution or answer.
• I have searched the Auth0 Community forums and have not found a suitable solution or answer.
• I agree to the terms within the Auth0 Code of Conduct.

Description

The pre-built Auth0_WordPress_5.6.1.zip published on the 5.6.1 release page is unusable as shipped: php-scoper rewrites WordPress's global classes (WP_User, WP_Error, WP_Object_Cache) into the plugin's vendor namespace (Auth0\WordPress\Vendor\WP_*), and those classes don't exist. The plugin throws a fatal TypeError on the first request after activation.

This appears to be a missing entry in the php-scoper exclude/expose configuration — WordPress globals should be left in the global namespace.

Affected files in the 5.6.1 release zip

src/Actions/Authentication.php:11   use Auth0\WordPress\Vendor\WP_Error;
src/Actions/Authentication.php:12   use Auth0\WordPress\Vendor\WP_User;
src/Actions/Sync.php:9              use Auth0\WordPress\Vendor\WP_User;
src/Cache/WpObjectCachePool.php:8   use Auth0\WordPress\Vendor\WP_Object_Cache;

(The source tree on the 5.6.1 git tag is fine — use WP_User; etc. The bug is introduced during the scoper build.)

Error

PHP Fatal error:  Uncaught TypeError: Auth0\WordPress\Actions\Authentication::getAccountByConnection():
Return value must be of type ?Auth0\WordPress\Vendor\WP_User, WP_User returned
in .../wp-content/plugins/wp-auth0/src/Actions/Authentication.php:110
Stack trace:
#0 .../src/Actions/Authentication.php(280): Auth0\WordPress\Actions\Authentication->getAccountByConnection('auth0|…')
E
#1 .../wp-includes/class-wp-hook.php(341): Auth0\WordPress\Actions\Authentication->onInit('')
#2 .../wp-includes/class-wp-hook.php(365): WP_Hook->apply_filters(NULL, Array)
#3 .../wp-includes/plugin.php(522): WP_Hook->do_action(Array)
#4 .../wp-settings.php(742): do_action('init')

Equivalent fatals will fire from any code path that exercises WP_Error (src/Actions/Authentication.php) or WP_Object_Cache (src/Cache/WpObjectCachePool.php).

Reproduction

1. Download Auth0_WordPress_5.6.1.zip from the GitHub release page.
2. Unpack it into wp-content/plugins/ of a clean WordPress install (verified on WP 6.5, PHP 8.1+).
3. Activate the Auth0 plugin from the admin.
4. Load any admin or front-end URL (or wait for the next init hook).
5. Observe the fatal TypeError in debug.log and a 500/WSOD in the browser.
6. The login flow exercises this fastest: a real user reaching Authentication::onInit() will fatal as soon as getAccountByConnection() matches a WP_User.

Additional context

Patch the four imports back to the global namespace:

- use Auth0\WordPress\Vendor\WP_Error;
- use Auth0\WordPress\Vendor\WP_User;
+ use WP_Error;
+ use WP_User;

- use Auth0\WordPress\Vendor\WP_Object_Cache;
+ use WP_Object_Cache;

To find any others slipping through in future builds:

grep -rn 'Auth0\\WordPress\\Vendor\\WP_' src/

Suggested fix
Add WordPress core globals to the scoper exclude list in scoper.inc.php. At minimum the symbols already referenced by src/:

• WP_User
• WP_Error
• WP_Object_Cache

A safer exclude is the broader WP_* symbol prefix plus WP's procedural globals (wp_, is_, etc., though those mostly appear unprefixed already). Auth0's own scoper config docs cover the exclude-classes / expose-classes options.

wp-auth0 version

5.6.1 (release zip)

WordPress version

6.5.x

PHP version

8.1+

[kishore7snehil]

👋 @no2pixel, Thanks for the detailed report. The root cause was a missing exclude-classes configuration in our php-scoper setup - WordPress global classes (WP_User, WP_Error, WP_Object_Cache) were not excluded from namespace prefixing during the build.

This has been fixed and the release artifacts for 5.6.1 have been re-uploaded. The zip on the release page should now work correctly.

We've also added a post-build verification step that will catch this class of issue in future releases.

Could you verify with the updated zip and confirm it resolves the issue on your end?