What's the benefit of having an external wrapper class for this? I mean I get unit testing benefits but generally the principle of helper classes is that they should be static methods. If they aren't going to be statics then imo they should just be more methods in JUser. I really don't see the use of them being this standalone class you have to inject into JUser

@wilsonge Please read this: https://github.com/sebastianbergmann/de-legacy-fy#wrapping-a-static-api-class

We need this wrapper in Joomla! 3.x for backward compatibility, it will be removed in Joomla! 4.x.

In practice, Joomla has always used static helpers. In theory, it isn't necessarily the best way to go about things.

Travis failed because we need also to adjust the loader to handle the new introduced "helperwrapper" classes.

loader.php - change in the function import

// Handle special case for helper classes.
if ($class == 'helper' || $class == 'helperwrapper')

If you create a new folder named helper in the libraries/joomla/user folder then rename the file to wrapper.php it'll work. The autoloader expects a new folder at each capital letter with the final one being the file name reference.

@mbabker Thanks! I wanted to adjust the loader but your solution is just perfect.

@test This PR works as expected, I have tested:

• Creating a new user
• Activating the new user
• Modify the user profile
• Remove the user
• Change the user password

All works as expected.

@test this PR works as expected, I have tested:

• activate/deactivate a user
• Creating a new user
• Changing password and login with new pass
• add/remove user from Usergroup

Moving to RTC

This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/4717.

@sebastianbergmann Can you please take a look on our implementation? Thanks!

Looks good to me, @Kubik-Rubik.

Thanks @sebastianbergmann!

Merged to 3.4-dev