GET parameter formatting for nested assets

[quimby]

Background:

• I have nested a Matrix Search Page in a Standard Page.
• Search Page has been set up to search on a metadata field, root node dynamically set as part of the nest.  No issues so far.
• By default all results are returned (basically a 'Show all'), as the Search Page has been set up to allow empty searches.
• On the left hand side I have a list of checkboxes showing available options (currently hard-coded) and a submit.  Basically this is a filter of the original results.
• Clicking on one (and only one) of the checkboxes and submitting returns results that have the metadata field matching the selected checkbox. Still no issues, all working fine.

Issue:

When I select multiple checkboxes (i.e. I want to filter on multiple values, as an OR) the following arguments get written to the URL:

?doctype=value1&doctype=value2        <-- not working, filters on value2 only

When this is fed into the Search Page it is only filtering on the second one, seemingly the first gets overwritten or ignored in some way.

 

I did some testing and found the following syntax works if passed to the search:

?doctype=value1,value2                <-- working, filters on both value1 and value2

So is there some way I can set up my HTML form, or use keyword modifiers, or set up the Search Page so that either I can get the first type to work and filter by both values, or alternatively wrangle it so the values are submitted in the second form?

 

Cheers

[nnhubbard]

Have you setup a Search Page and configured it without hardcoding anything, just to see how Matrix would write that GET?

[quimby]

It generates a drop-down (HTML select box), which only allows single selection.  So in that case there would never be an issue because there would never be more than value for the param being passed.

[nnhubbard]

Can't you just use javascript to format it like your second example?

[quimby]

Of course can use javascript, but would prefer a HTML-only solution if possible.  Was also wondering whether this was a quirk of Matrix, or something not considered before, and if anyone else had found same issue and/or solved it.

[quimby]

Ok, it's not pretty.  This is what I have come up with:

 

1. Rewrite the HTML select/options (these would have to be hard-coded anyway since by default Matrix allows single-selection only, which doesn't meet our requirements).  Rewrite in such a way that rather than the checkboxes all having the same name, and thereby creating an array, each checkbox is instead uniquely named.  E.g. ...
...
...
...

There is also logic in there for adding 'checked' attributes (or is called a property?) on options selected in the search (useful as in my case I'm continuously showing these options including on result pages).

 

2. Leave the Matrix Search Page fields configuration as is, in my case a GET parameter called 'doctype' to match on a specific metadata field, set to OR logic.

3. In the standard page embedding the search form add a nested GET variable, in my case I called doctype, update to this value (yes, using the "one Matrix keyword to rule them all" approach): ...
...
...
...

So why does this work?

• Selecting multiple checkboxes and submitting now submits a query string that has uniquely named args, specifically:

  ?option1=show&option2=show...
  

  So the globals_get keywords in the variables section on the embedding page can now handle it correctly (Matrix globals_get keyword doesn't handle array values at all, as stated in manuals).
   

• The sequence of keywords in the GET variables in the embedding page handles each of these options separately and outputs a value followed by a comma.  (You could in fact customise what these search values are to match your metadata keys, if required, at this point).  Fortunately Matrix Search page allows you to have a comma on the end and is forgiving and runs the search as expected.  Were it not for that none of this would work.
   

• Interestingly it doesn't matter what the value for the options is set to, since you are a translating/mapping them in the nested variable anyway.  You can even leave the value attribute off completely.  Due to the nature of how checkboxes are handled it will default to a value of 'on' if checked, unchecked ones do not even get a a param set at all, and so our logic only has to check that the param was set, specific value is irrelevant.

It's not all good news

Above approach requires a lot of manual coding HTML.  Not a problem in my case as I was going to have to manually code it anyway, but updates will be that much more difficult.  Each time a new option is added or an existing one updated I'm going to have to come in here and change not only the options list but also the big keywords list in the embedding page.  Again, in my case this list will change very infrequently so it's ok, but if you are going to be changing the options frequently then this may not be an ideal solution.

 

 

Edit: Wanted to also say Nic is absolutely right, this could be accomplished with a handful of lines of javascript.  Sometimes I like to see if something *can* be done a certain way - one of my character flaws.  In fact, if you wanted a highly dynamic solution you could use the built-in Matrix selector, hide it, and use JS to generate a list of checkboxes directly in the DOM.  For frequently updated options this would be an ideal solution as the checkboxes would automatically generate based on your metadata field values.

[Bart]

I'm assuming Matrix is spitting out a select field by default because that's the type of field that the metadata field is set to? So matrix will just use that field type when generating the input field for the search page, which makes sense. There would have to be additional configuration screens on the search page search fields screen for you to control what format you want that field to output in, which could be a nice feature I guess. 

[quimby]

I'm assuming Matrix is spitting out a select field by default because that's the type of field that the metadata field is set to?

 

That's what I assumed too, which is perfect for selecting a single value but not useful for multiple. (Update: another issue may be the metadata field does not itself allow multiple, which is intentional, but the filter option does).

 

I think more the issue is not being able to handle arrays of GET params, which seems to be a keywords limitation.  E.g. if I have the following query string:

?param=v1&param=v2

Then I would expect the keyword %globals_get_param% to output "v1,v2" (Note: not sure if that's actually correct according to any standard).  Instead the keyword just seems to output the last value i.e. "v2".  Manuals say the keyword doesn't handle param arrays so maybe the fix is non-trivial (otherwise they would have just fixed it).

 

Would be a nice feature, but I reckon since it's an edge case - first time I've ever encountered it, possibly also the last - not sure it's worth the time.

[Bart]

 

I think more the issue is not being able to handle arrays of GET params, which seems to be a keywords limitation.  E.g. if I have the following query string:

?param=v1&param=v2

 

The problem with that is that it's not a standard way of passing url parameters, because you are basically overwriting v1 with v2. It's like doing this is JS:

 

var param = "v1";

var param = "v2";

//param will print "v2"

 

The correct way to pass them in a URL parameter would be via comma separated values:

 

?param=v1,v2,v3