Answers.Body: <p>Unfortunately this is a limitation of that feature. In this case, both of your Lightswitch fields will be tweaking the DB query with their own <code>WHERE [field_column_name] = 1</code>, without knowledge of each other.</p>
  
  <p>To avoid this, just give each of your Lightswitch fields their own unique handles.</p>
  
  <p>If you want to get all the blocks where either one of your Lightswitch fields are checked, you could do this:</p>
  
  <pre><code>{% set blockIds = entry.matrixField.type('type1').typeOneLightswitchField(1).ids()
      |merge(entry.matrixField.type('type2').typeTwoLightswitchField(1).ids())
  %}
  
  {% for block in entry.matrixField.id(blockIds) %}
      ...
  {% endfor %}
  </code></pre>
  
  <p>Not exactly a clean solution, but it’ll get the job done.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-01-29T20:07:12.750Z
Answers.Text: Thanks for the answer, Brandon. To clarify, I gave them the same handle by propose, to allow me to access them with the Matrix block query I posted in the example. I'll search for a workaround then! :)
Answers.UserDisplayName: carlcs
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-01-29T20:11:36.997Z
Answers.Text: @carlcs Ah, gotcha. Just updated my answer with a possible workaround.
Answers.UserDisplayName: Brandon Kelly
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-01-29T19:58:47.040Z
Answers.LastActivityDate: 2015-01-29T20:11:17.277Z
Answers.LastEditDate: 2015-01-29T20:11:17.277Z
Answers.UserDisplayName: Brandon Kelly
Body: <p>This is a great new feature of Craft 2.3:</p>
  
  <blockquote>
    <p>It is now possible to set custom field parameters on Matrix block queries.</p>
  </blockquote>
  
  <p>I was wondering what would happen, if two or more Matrix Block Types had a field with the same handle (e.g. <code>myLightswitchField</code>), and if it was possible to query for blocks across Block Types using this field as a parameter.</p>
  
  <p>My example code doesn't return any blocks:</p>
  
  <pre><code>{% set blocks = entry.myMatrixField.myLightswitchField('1') %}
  
  Yeah! There's {{ blocks|length }} Matrix blocks enabled.
  </code></pre>
  
  <p>This is just an example! I know that you can disable blocks from the block's context menu.</p>
  
Tags: <matrix><field><filter><block-types>
Title: Query for blocks across Block Types using the new field parameter?
ThreadText: # Query for blocks across Block Types using the new field parameter?
  
  (Asked by: username_0 on 2014-12-03)
  
  This is a great new feature of Craft 2.3:
  
  > It is now possible to set custom field parameters on Matrix block queries.
  
  I was wondering what would happen, if two or more Matrix Block Types had a field with the same handle (e.g. `myLightswitchField`), and if it was possible to query for blocks across Block Types using this field as a parameter.
  
  My example code doesn't return any blocks:
  
  ```
  {% set blocks = entry.myMatrixField.myLightswitchField('1') %}
  
  Yeah! There's {{ blocks|length }} Matrix blocks enabled.
  
  ```
  
  This is just an example! I know that you can disable blocks from the block's context menu.
  
  **Tags:** matrix, field, filter, block-types
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2015-01-29. Score: 4 | Accepted answer
  
  Unfortunately this is a limitation of that feature. In this case, both of your Lightswitch fields will be tweaking the DB query with their own `WHERE [field_column_name] = 1`, without knowledge of each other.
  
  To avoid this, just give each of your Lightswitch fields their own unique handles.
  
  If you want to get all the blocks where either one of your Lightswitch fields are checked, you could do this:
  
  ```
  {% set blockIds = entry.matrixField.type('type1').typeOneLightswitchField(1).ids()
      |merge(entry.matrixField.type('type2').typeTwoLightswitchField(1).ids())
  %}
  
  {% for block in entry.matrixField.id(blockIds) %}
      ...
  {% endfor %}
  
  ```
  
  Not exactly a clean solution, but it’ll get the job done.
  
  > **Comments:**
  > **username_0**: Thanks for the answer, username_1. To clarify, I gave them the same handle by propose, to allow me to access them with the Matrix block query I posted in the example. I'll search for a workaround then! :)  
  > **username_1**: @username_0 Ah, gotcha. Just updated my answer with a possible workaround.  
  
  ---
  
  