Event Triggered: user_signup_activated, sends password and required extended userfields miss *

[Alex-e107nl]

@e107help 2 things:
_First: I was surprised to see that the e-mail that gets sended to the admin when a new user gets activated has the full password of the user in it?

My settings are: Password in Email Confirmation - HIDE in e107_admin/prefs.php#nav-core-prefs-signup
In the mail there is this: [user_login] => REALPASSWORD
That is not how it is supposed to be._

Sorry, i made a mistake, filled in my password in the wrong field, i was working to fast... so this one is solved and can be skipped!

Second:
also when a extended userfield is Required there's no * before the fieldname... but i do not know if that is a template issue..
I only see this in the user_template.php:

	$USER_TEMPLATE['extended']['start'] = '';
	$USER_TEMPLATE['extended']['end']   = '';

	$USER_TEMPLATE['extended']['item'] = '
		<div class="row {EXTENDED_ID}">
		    <div class="ue-label col-xs-12 col-md-4">{EXTENDED_NAME}</div>
		    <div class="ue-value col-xs-12 col-md-8">{EXTENDED_VALUE}</div>
		</div>
		';

This feels somewhat as a deja vu, this problem has been in e107 before?

Can you look at it?

[e107help[bot]]

@Alex-e107nl taking the second one, since you have withdrawn the first. The marker for a required extended field is being emitted. Nothing draws it.

Required extended fields on the signup form reach signup_shortcodes.php:546-550, which calls sc_signup_is_mandatory(), which returns <span class='required'><!-- empty --></span> (:630-633). The user settings page does the same through {REQUIRED} in its extended-field template (usersettings_template.php:148-154, rendered at usersettings_shortcodes.php:670-679).

That span is empty on purpose. Whatever it shows has to come from CSS on .required, and there is none. The only rule ever written for the class sits inside a commented-out block at e107_web/css/e107.css:115-121, and even uncommented it sets a colour rather than producing an asterisk. Bootstrap 3, Bootstrap 5 and Voux do not style it either, and release/v2.3.x carries the identical span and the same commented-out block. So no field on either page shows a *, and username, email and password are as unmarked as your extended one.

Which settles the template question: it is not user_template.php. The block you pasted is the profile display template that user.php renders, and a display page has no required fields to mark. Nor does the field stop being required: renderElement() puts the HTML5 required attribute on the input (user_extended_class.php:1255) and userExtendedValidateAll() re-checks it server-side at signup, so an empty one is refused. The form just never warns the visitor to expect that.

Your deja vu is exact, and better than exact. #3676 is this same report, opened by @wrxxy on 14 February 2019 as "Missing Asterix after Extended User field introduced", and still open. The commit that answered it is the commit that took the asterisk away: 4327201254 (2019-03-01) deleted <span class='required'> *</span> from the templates, along with define("REQUIRED_FIELD_MARKER", ...), and replaced them with the empty span, resting on CSS that never landed.

For your own site today, it is one rule in your theme's stylesheet:

.required::after { content: "*"; color: #a94442; }

That is theme-side, so it fixes your forms without pre-empting where the fix belongs in core, which is the open part. I have written the trace up as #6124 and flagged there that it overlaps #3676; which of the two survives is Deltik's call, not mine. The design question in it is more yours than mine, though, given what you said on #5909 about dead classes in core defaults: should core ship the asterisk in e107_web/css/e107.css, where a theme that already draws its own would then draw two, or keep emitting a bare element and leave every theme to style it? Your view on that is worth more than my guess.

On the withdrawn half, for the record, because your reading of it was closer than you think: the New User notification prints every posted field except password1, password2, email_confirm and register (notify_class.php:313-334), so a value typed into the wrong box does arrive verbatim. Password in Email Confirmation is the user_reg_secureveri pref and governs a different message, the confirmation sent to the new user (user_model.php:1756-1762). It was not bypassed.