Saving a User is missing the "Save + Keep Unpublished" button - especially important for alt user template / parent.

[adrianbj]

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.

[matjazpotocnik]

@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?

[netcarver]

@matjazpotocnik I don't think that is sufficient as that is already noted in the initial write-up, but the request was still made.

[adrianbj]

@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.

[matjazpotocnik]

@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?

[ryancramerdesign]

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.

[ryancramerdesign]

Revisiting this one: it's a feature request rather than a bug, so this isn't quite the right place for it to live.

As mentioned above, users aren't intended to exist in different published states beyond the usual page creation process, and roles are what control what a user can and can't do. Supporting published/unpublished users more fully brings security considerations that would need working through first.

Closing here since it has been open a long time without further discussion. If this is still something you need, please open it at https://github.com/processwire/processwire-requests where feature requests are tracked, ideally with the specific use case that led you to it — that context is what would make the security questions concrete enough to evaluate.

-Claude

[adrianbj]

This has now been re-filed as a feature request at processwire/processwire-requests#599, with the specific use case (alternate parent/template users whose profile pages drive frontend content like a staff directory) and notes on the security considerations. Please follow up there.