processwire-issues
processwire-issues copied to clipboard
Saving a User is missing the "Save + Keep Unpublished" button - especially important for alt user template / parent.
Short description of the issue
We really need to be able to easily have unpublished users. It's possible to publish and then check the "Unpublished" checkbox on the Settings tab and then click the "Save" button, but we shouldn't be forced to publish them to start with. This is particularly important when using a frontend branch of the page tree to store user accounts.
Expected behavior
We should be able to save a user without publishing them
Actual behavior
There is no "Save" or "Save + Keep Unpublished" button, only a "Publish" button.
@adrianbjI just tested, and when you create a new user, it's unpublished by default. After filling in the password, the user is published. You can unpublish a user in the Settings tab. Is this good enough to close this issue?
@matjazpotocnik I don't think that is sufficient as that is already noted in the initial write-up, but the request was still made.
@matjazpotocnik - as @netcarver noted, the issue is that you can't later modify a user without publishing it because there is no "Save + Keep Unpublished" button.
@adrianbj does it help if you comment line 331 'User', 'UserPage',
in ProcesspageEdit.module? Or use this hook:
$wire->addHookBefore('ProcessPageEdit::buildForm', function(HookEvent $event) {
$module = (array) $event->object;
$propertyName = 'otherCorePageClasses';
$_propertyName = chr(0).'*'.chr(0).$propertyName;
$newValue = $module[$_propertyName];
$key = array_search('User', $newValue); unset($newValue[$key]);
$key = array_search('UserPage', $newValue); unset($newValue[$key]);
array_walk($event->object, function (&$value, $key) use ($newValue, $propertyName) {
if(substr($key, -strlen($propertyName)) === $propertyName) $value = $newValue;
});
});
@ryancramerdesign there must be a reason why users are not allowed to be unpublished?
Users aren't intended to exist in different published states, other than the usual page creation process. (Likewise with role and permission pages). Roles are what are intended to control what a user can or can't do. I understand you can get around things, but I think there are some considerations and security questions for fully supporting it, and I'm not ready to fully support this just yet, but maybe after this next master/main version is done we can revisit.