Users can opt-in to userclasses but cannot opt-out of them

[Jimmi08]

Moving my posts here from to not mess with issue

#5159

Bug description
Once a user has assigned themselves any custom userclass on the settings page, they cannot unassign it. In the database, I have noticed in the "e107_user" table that the "user_class" column is completely overwritten with the id of the userclass instead of it being appended to it. This happens on my current production install and a fresh test install.

I can confirm this in 7.4 too. And latest github version.

If you want a quick fix, I did it because I am using it on the live site too. But I have no idea why it helped and what is a problem, ok? Tested on e107sk.com

On left side is fix, on right side is actual version of handlers/user_class.php

		$e107 = e107::getInstance();
		$ecache = $e107->getCache();

Unfortunately, nothing has changed after applying your fix and clearing the cache.

I am sorry, it works for me - PHP 7.4 - locally with 8.1. I am not able to help more,

[Jimmi08]

@HatchlingByHeart delete your answer too if you can. Sorry for messing with your issue (it is better to left it untouched and discuss here)

[HatchlingByHeart]

Done.

[Alex-e107nl]

It is changed on 0ct 27.. 552af19 PHP 8.2 Deprecated error removal ?

I can confirm the problem, today's git....

[HatchlingByHeart]

Also, I am on PHP 8.2.13, which to my knowledge is the latest on the PHP 8.2.x branch.

Would downgrading to 8.1 or upgrading to 8.3 possibly help? @Jimmi08 @Alex-e107nl

[Jimmi08]

No idea, but I think that e107 fully supports 8.1. That commit is called PHP 8.2 fixes but it is changing other things too.

There is time zones issue and it is holiday time... you need to wait for core developers with this.

[Alex-e107nl]

I am also working on 8.1.26 so that's no solution... keep in mind that not everyone is in this timezone... wait and see if one of the dev's have a solution?

[Jimmi08]

I am not sure what to test. I have 2.3.3 installation, some plugins are there, custom theme... Userclasses work normally. PHP 8,2.

[HatchlingByHeart]

Given that the issue also happened on a fresh install of 2.3.3 for me, I can rule out any changes to files I have made. My theory is it may be related to PHP config. That's the only thing I can imagine would differ between a fresh install on my system and someone else's.

My server OS is Debian 11, and my PHP config can be found here (comments removed): https://www.dropbox.com/scl/fi/lmp1kip6mcjmhn0ufac3z/php.ini?rlkey=uqw3zy6p8s3pcjuavh20lpu4o&dl=0

Can you guys think of anything else that may differ in our environments?

[HatchlingByHeart]

For anyone curious about my process in setting up when I get these issues, here's the video I posted in the issue.

2023-12-21.14-44-40.mp4

[HatchlingByHeart]

Another user appears to have found the problem.

Quote (@Deltik): (#5159)

I was able to reproduce the bug as a normal user (not admin) by unchecking all the "Subscribed to" items.

The cause is that the class[] array being empty is not sent to the server for validation, so the server assumes that the client did not want to change the userclasses.

As for the "Manager" and "Visibility" changing from "Everyone (public)" to "Admin" in /e107_admin/userclass2.php?mode=main&action=edit, it's because "Everyone (public)" is saved as 0, which is interpreted as no value, so the default will be "Admin" when the page loads again. It is actually saved as "Everyone (public)", but a subsequent save will actually change it to "Admin".

So there are two bugs.

[HatchlingByHeart]

@Jimmi08 @Alex-e107nl
I was unable to fix the code, but I have a workaround that works:

Adding a dummy userclass that is otherwise not used for anything (ID# 1 in my case), and making the following changes:

/e107_core/shortcodes/batch/userclasses_shortcodes.php

/e107_handlers/userclass_class.php

[Vodhin]

I came across this issue a while ago. I added a bit of code to usersettings.php around line 540 to ensure that userclass was never empty by adding a useless value;

// Update Userclass - only if its the user changing their own data (admins can do it another way)
$allData['data']['user_class'] = ($allData['data']['user_class'] ? $allData['data']['user_class'] : -256);
if (isset($allData['data']['user_class']))
{ ...

this seems to work for me.