You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
pages() exposes a method has() to quickly check if a matching page exists. This is currently lacking for the users() object. Having such an analogous method would strenghen the coherence of PW’s API, improve code clarity in users’ projects, and potentially prevent subtle bugs in setups with custom user templates or parents.
Optional: Steps that explain the enhancement
Implementation could be as simple as adding this method to wire/core/Users.php:
It would be interesting to add the method to PagesType, but this leads to a conflict with Permissions, which unfortunately also exposes a method by this name, but with a different signature:
Fatal error: Declaration of ProcessWire\Permissions::has($name) must be compatible with ProcessWire\PagesType::has($selector, $verbose = false)
It would actually be kind of sweet to fully unify this API. In fact, since has() is already able to take a raw page name in place of a selector, this may be possible without any breakage. (Unfortunately permissions()->has() always returns a bool and changing it would break people’s strict identity comparisons).
Current vs. suggested behavior
Currently to check if a user exists, for instance during sign-up, one has these options as far as I’m aware:
//loads unnecessary data, intent not quite as clearly as has(),//requires verbose sanitization because array syntax is unavailable,//also NullPage is not falsyif (users->get("name={$sanitizer->selectorValue($username)}")->id)
//quickly becomes overly complicated when using custom user templates/parentsif (pages()->has(['template' => 'user', 'name' => $username]))
Why would the enhancement be useful to users?
Knowing one is supposed to use has() to check page existance, one is tempted to assume the same applies to users. This suggestion would make the API more intuitive by unifying it and would allow one to write the following without having to worry about custom parents and templates:
if (users->has(['name' => $username]))
die('Sorry, that name is already taken');
Thanks!
The text was updated successfully, but these errors were encountered:
Indeed I just noticed not even pages()->get() and users()->get() are unified as the latter only takes a selector string. That’s a separate issue, but further illustrates the problem with using get() as a workaround, because it clutters the code with more sanitization. (In my pagename examples above, this is less urgent, but one may want to allow nice-looking user names potentially containing commas, for example, necessitating sanitization just for the sake of the selector).
Short description of the enhancement
pages()
exposes a methodhas()
to quickly check if a matching page exists. This is currently lacking for theusers()
object. Having such an analogous method would strenghen the coherence of PW’s API, improve code clarity in users’ projects, and potentially prevent subtle bugs in setups with custom user templates or parents.Optional: Steps that explain the enhancement
Implementation could be as simple as adding this method to
wire/core/Users.php
:It would be interesting to add the method to
PagesType
, but this leads to a conflict with Permissions, which unfortunately also exposes a method by this name, but with a different signature:It would actually be kind of sweet to fully unify this API. In fact, since
has()
is already able to take a raw page name in place of a selector, this may be possible without any breakage. (Unfortunatelypermissions()->has()
always returns a bool and changing it would break people’s strict identity comparisons).Current vs. suggested behavior
Currently to check if a user exists, for instance during sign-up, one has these options as far as I’m aware:
Why would the enhancement be useful to users?
Knowing one is supposed to use
has()
to check page existance, one is tempted to assume the same applies to users. This suggestion would make the API more intuitive by unifying it and would allow one to write the following without having to worry about custom parents and templates:Thanks!
The text was updated successfully, but these errors were encountered: