Answers.Body: <p>Let me try to make some sense of the behavior you’re seeing.</p>
  
  <p>First, you should know that the <code>admin</code> param will query against the <code>admin</code> column in your <code>craft_users</code> table, which will either be set to <code>0</code> or <code>1</code> for each user.</p>
  
  <p>Like most Craft params, the <code>admin</code> param is set to <code>null</code> by default, and will only have any affect on the DB query if it is set to a <strong>non-empty</strong> value. (Here’s a list of what PHP considers “empty”: <a href="http://php.net/manual/en/function.empty.php#refsect1-function.empty-returnvalues" rel="nofollow">http://php.net/manual/en/function.empty.php#refsect1-function.empty-returnvalues</a>)</p>
  
  <p>So, here’s what’s happening behind the scenes for each thing you passed in:</p>
  
  <ul>
  <li><code>false</code> – That’s an empty value, so it’s the same as not passing anything in.</li>
  <li><code>'false'</code> – Since the <code>admin</code> column is numeric, MySQL has to normalize this string into a number (sortof like using JavaScript’s parseInt() function). The result for <code>'false'</code> is <code>0</code>, since <code>'false'</code> doesn’t begin with a number. The end result is that this awkwardly works as expected, but I wouldn’t recommend it.</li>
  <li><code>'true'</code> – Same effect as <code>'false'</code>. Ends up being <code>0</code>.</li>
  <li><code>true</code> – SQL doesn’t support PHP’s boolean datatypes (<code>true</code>/<code>false</code>), so PHP will convert this to <code>1</code> before passing it off to MySQL. (<code>false</code> likewise becomes <code>0</code>, but since <code>false</code> is empty, Craft won’t let your value make it that far in the first place.)</li>
  </ul>
  
  <p>In the future, I think this makes a good case for us allowing <code>false</code>, so we’ll probably start checking for that and allowing it. But that won’t help you today.</p>
  
  <p>So the question is then, what is the best way to find users that are(n’t) admins today? Here’s what I would recommend:</p>
  
  <p>Finding admins:</p>
  
  <ul>
  <li><code>1</code> (int)</li>
  <li><code>'1'</code> (string)</li>
  <li><code>true</code></li>
  </ul>
  
  <p>Finding non-admins:</p>
  
  <ul>
  <li><code>'not 1'</code> (string)</li>
  </ul>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-10-22T19:44:56.813Z
Answers.Text: Lol, so I was doing it completely wrong but somehow managed to return the results by luck. I guess it would be good to have this documented as I couldn't find any examples and the only reference I found was on the Cheat Sheet over at [Straight Up Craft](http://straightupcraft.com/articles/cheat-sheet-craft.users) with 'true or false' next to the 'admin' parameter. As the [docs for craft.user](http://buildwithcraft.com/docs/templating/craft.users#admin) didn't show an example I assumed it would behave like the fixedOrder parameter which you show a `true` or should this be a 1 as well?
Answers.UserDisplayName: Neal Hulme
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-10-22T20:50:54.743Z
Answers.Text: Just updated the [craft.users](http://buildwithcraft.com/docs/templating/craft.users#admin) page to explicitly state that you should enter `'1'` or `'not 1'`, plus included a couple examples. `fixedOrder` is different, because that param doesn’t translate directly into a DB condition like `admin` does.
Answers.UserDisplayName: Brandon Kelly
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-10-22T21:03:54.037Z
Answers.Text: Ah, that makes sense... is it good practice then to use 0's and 1's instead of true and false when dealing with DB queries to avoid these scenarios? A useful concept to be aware of.
Answers.UserDisplayName: Neal Hulme
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-10-22T21:40:26.163Z
Answers.Text: Not `0`s, because `0` and `'0'` are considered “empty” ;)
Answers.UserDisplayName: Brandon Kelly
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-10-22T19:25:15.867Z
Answers.LastActivityDate: 2014-10-22T19:25:15.867Z
Answers.UserDisplayName: Brandon Kelly
Body: <p>This may have been answered before but my searching has not come up with anything. I need clarification on when to quote and when not to quote the boolean in the admin criteria for craft.users in a Twig template.</p>
  
  <p>I have a plugin that displays a table of users and the reason this came up is I needed to exclude the admins from the table. Easy you say, just use the admin parameter and set it to false. That's what I thought so I did this:</p>
  
  <pre><code>{% set users = craft.users.admin(false) %}
  </code></pre>
  
  <p>This however returned all the users. So I thought maybe it needs quoting and did this:</p>
  
  <pre><code>{% set users = craft.users.admin('false') %}
  </code></pre>
  
  <p>Hurray! This did exactly what I wanted. Then I thought what if I only wanted the admins and tried:</p>
  
  <pre><code>{% set users = craft.users.admin('true') %}
  </code></pre>
  
  <p>This however returned all users that are not admins, eh? Ok, what about:</p>
  
  <pre><code>{% set users = craft.users.admin(true) %}
  </code></pre>
  
  <p>Hurray again! Only admins.</p>
  
  <p>So looking through the source I can see why the first unquoted false has no affect as it fails the <code>if(criteria-&gt;admin){}</code> and therefore does nothing. After that I got lost in parseParam() and arrayHelpers so if anyone could clarify to quote or not to quote (that is the question!) and if this is the expected behaviour. Seems a little strange you need to quote 'false' and not quote true to get the desired behaviour. I also tried passing the parameters as an object and the results were the same.</p>
  
Tags: <templating>
Title: craft.users.admin boolean parameter... to quote or not to quote?
ThreadText: # craft.users.admin boolean parameter... to quote or not to quote?
  
  (Asked by: username_0 on 2014-10-22)
  
  This may have been answered before but my searching has not come up with anything. I need clarification on when to quote and when not to quote the boolean in the admin criteria for craft.users in a Twig template.
  
  I have a plugin that displays a table of users and the reason this came up is I needed to exclude the admins from the table. Easy you say, just use the admin parameter and set it to false. That's what I thought so I did this:
  
  ```
  {% set users = craft.users.admin(false) %}
  
  ```
  
  This however returned all the users. So I thought maybe it needs quoting and did this:
  
  ```
  {% set users = craft.users.admin('false') %}
  
  ```
  
  Hurray! This did exactly what I wanted. Then I thought what if I only wanted the admins and tried:
  
  ```
  {% set users = craft.users.admin('true') %}
  
  ```
  
  This however returned all users that are not admins, eh? Ok, what about:
  
  ```
  {% set users = craft.users.admin(true) %}
  
  ```
  
  Hurray again! Only admins.
  
  So looking through the source I can see why the first unquoted false has no affect as it fails the `if(criteria->admin){}` and therefore does nothing. After that I got lost in parseParam() and arrayHelpers so if anyone could clarify to quote or not to quote (that is the question!) and if this is the expected behaviour. Seems a little strange you need to quote 'false' and not quote true to get the desired behaviour. I also tried passing the parameters as an object and the results were the same.
  
  **Tags:** templating
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2014-10-22. Score: 2 | Accepted answer
  
  Let me try to make some sense of the behavior you’re seeing.
  
  First, you should know that the `admin` param will query against the `admin` column in your `craft_users` table, which will either be set to `0` or `1` for each user.
  
  Like most Craft params, the `admin` param is set to `null` by default, and will only have any affect on the DB query if it is set to a **non-empty** value. (Here’s a list of what PHP considers “empty”: <http://php.net/manual/en/function.empty.php#refsect1-function.empty-returnvalues>)
  
  So, here’s what’s happening behind the scenes for each thing you passed in:
  
  * `false` – That’s an empty value, so it’s the same as not passing anything in.
  * `'false'` – Since the `admin` column is numeric, MySQL has to normalize this string into a number (sortof like using JavaScript’s parseInt() function). The result for `'false'` is `0`, since `'false'` doesn’t begin with a number. The end result is that this awkwardly works as expected, but I wouldn’t recommend it.
  * `'true'` – Same effect as `'false'`. Ends up being `0`.
  * `true` – SQL doesn’t support PHP’s boolean datatypes (`true`/`false`), so PHP will convert this to `1` before passing it off to MySQL. (`false` likewise becomes `0`, but since `false` is empty, Craft won’t let your value make it that far in the first place.)
  
  In the future, I think this makes a good case for us allowing `false`, so we’ll probably start checking for that and allowing it. But that won’t help you today.
  
  So the question is then, what is the best way to find users that are(n’t) admins today? Here’s what I would recommend:
  
  Finding admins:
  
  * `1` (int)
  * `'1'` (string)
  * `true`
  
  Finding non-admins:
  
  * `'not 1'` (string)
  
  > **Comments:**
  > **username_0**: Lol, so I was doing it completely wrong but somehow managed to return the results by luck. I guess it would be good to have this documented as I couldn't find any examples and the only reference I found was on the Cheat Sheet over at [Straight Up Craft](http://straightupcraft.com/articles/cheat-sheet-craft.users) with 'true or false' next to the 'admin' parameter. As the [docs for craft.user](http://buildwithcraft.com/docs/templating/craft.users#admin) didn't show an example I assumed it would behave like the fixedOrder parameter which you show a `true` or should this be a 1 as well?  
  > **username_1**: Just updated the [craft.users](http://buildwithcraft.com/docs/templating/craft.users#admin) page to explicitly state that you should enter `'1'` or `'not 1'`, plus included a couple examples. `fixedOrder` is different, because that param doesn’t translate directly into a DB condition like `admin` does.  
  > **username_0**: Ah, that makes sense... is it good practice then to use 0's and 1's instead of true and false when dealing with DB queries to avoid these scenarios? A useful concept to be aware of.  
  > **username_1**: Not `0`s, because `0` and `'0'` are considered “empty” ;)  
  
  ---
  
  