Symphony.

I'm guessing the labelling gives it away, but is there any way to provide more than one 'Required parameter' for a DS? I tried a few variations but nothing seemed to work…

Never needed it before but ideally I'd like all of the page parameters to be required for a certain DS.

Have you tried using conditionalizer?

What I used to do if you're using parameters, you can use the following:

 {$ds-datasource.field:thingthatwillnevermatch}

if you mean required as in available - you could just fill $this->_dependencies = array();

@animaux I have not will check it out! At a quick glance I'm not sure how I'd use it for what I'm after but it looks like a useful extension to familiarise myself with either way!

@gungliem I think maybe we're crossing-wires, I'm referring to the 'Conditions' fieldgroup in the DS editor, specifically the 'Required parameter' field. I think you're talking about DS filters. Or maybe I'm the one that is confused :)

basically you don't want the DS to run unless that parameter is available right? Was thinking 404 as that's how the param in question used to work.

I think that parameter is in a text string at the moment only one...

There's a way around it. If all your params are in the list, you can modify the execute function, check if they're set, if not return. If you want I can send you an example I do this all the time :)

The extension which animaux mentioned works but haven't used it for a long while.

If you like to be all page parameters required than it fails already if the first isn't there. Without overthinking things than should a check on the first parameter do the trick.

Otherwise can you give a 'live' example of what you like to achieve?

@plenaforma That's some good out-of-the-box thinking.

It turns out I think I was overthinking it for my scenario. Setting the second parameter as the required parameter, along with using it as the filter, ensures the intended behaviour. As a user attempting to go to, say, /stuff/ will get a 404, as only the first page parameter is present, and the second parameter is required. Seems obvious really - wonder why I thought there'd be an issue there…

tl:dr: I think it was already working as I needed it…

the required as of a couple version back means if this parameter does not exist please do not run this datasource - meaning that the 404 won't trigger either.

I think you need to filter both {$page} and {$type} and set dummy values if they don't exist. eg. {$page:thisshouldntwork} and {$type:thisshouldntwork} like that if they're blank you trigger a 404.

Hi @gunglien

Sorry I think you got caught in my editing frenzy - think I still need my morning caffein hit.

Although incidentally I think you have that the wrong way round, as we now have a: "Redirect to 404 page when the required parameter is not present" checkbox.

Although I don't think that I was aware you could set a default value as part of the filter, so I've certainly learned something useful there!

@nathan could be I haven't really used the editor of the latest version - though I remember having a discussion with John (@designermonkey) and Brendo about that functionality a while ago on github.

Default values are important! I use them all the time and they're key to most of the things I do.

@gunglien

I must have always managed without them (or worked around it!).

Out of interest is there a way to provide a 'dynamic' default value? In most of my use-cases the value going into the parameter will be something like a blog post title or company name, where it's set by the user within a section (so couldn't be statically added to a DS filter).

It would be handy if there were a way to say {$page:a-random-entry}- now that I would use a fair bit.