[Bug]: userclass - does not show properly after changes

[BillyBoy0823]

e107 version

v2.37

PHP version

PHP Version 8.1.34

What happened?

When I change a Members user class, if changes to show .253. I can change them to whatever is in the dropdown, But when I go to remove the setting, it will not default back to showing the user class as just Members again. it shows '--'. As seen in image

I think everything is working ok with the classes, including my plugins, but I am just starting testing on that...

Steps to reproduce

Just go to Users >> Manage and try it.

Expected behavior

1. not show .253 or any number when changing User Class.
2. Revert back to Members when no classes are selected for a Member.

Additional context

I tried it on my home system and three websites I have been installing. One with only the default user classes. At first I thought it was because of classes I added after the fact, but it happened on a fresh install as well.

[e107help]

Confirmed, @BillyBoy0823, and a clean catch. I traced it through the code and it's present on both the current release (v2.3.7) and current master, so it's a genuine core bug rather than anything in your setup. There are actually two separate faults here, which is why you're seeing two different wrong things.

1. The .253 (it's really a stray comma, ,253). The User Class column in Users → Manage is inline-editable, and that little editor only loads your classes plus "new" as its selectable options (users.php L333, classlist=classes,new). The built-in classes (Members = 253, Public, Guest and so on) aren't in that list. So when a member actually holds the built-in Members (253) class, the widget can't find a label for it and falls back to printing the raw value (admin.jquery.js L405, the else { $(this).text(value) } branch). The field also prepends a deliberate comma (form_handler.php L6092, the ",$value"), so the two together read as ,253, which is dead easy to misread as .253. A custom class shows its name fine precisely because it IS in that list.

2. The -- after you clear it. That's a separate, intentional-but-wrong placeholder. The field sets defaultLabel=--, and when the class comes back empty the renderer prints that label (form_handler.php L6072-L6074) instead of falling back to "Members" the way you'd expect.

So both of your asks line up with the code: never show a bare number, and treat "empty" as Members. The fix direction is small and field-local, widen the inline editor's option list so the built-in classes resolve to their names, and change that empty fallback. I've handed it to Deltik with the root cause; the actual fix is his call.

Cheers for testing it across four installs. The fresh-install repro is exactly what pins it as core and not your custom classes.