Add new argument default action that uses wildcard as default value

This fixes an issue with the current fullcalendar ajax branch.

Without this patch:
1) Errors
2) Ajax broken

With this patch
1) No errors
2) ajax working

I don't really think we should be changing the default behavior, here.

Arguments were always meant to be sequential. You can't just skip arguments in the middle. They're modelled after PHP. For example, in PHP this is not valid:

  function foo($a, $b = FALSE, $c)

The main feature was designed for drill-down summaries, or for 'hackable' URLs. I think the canonical use case was something like:

blogs/$user/$year/$month

The reason wildcards exist is so that you can go:

blogs/all/2011/9

And that just works. There's no way to represent that as a URL. If you change the behavior of ignore, today, then you could break/change the behavior of existing views.

Therefore, the answer is, IMO, to not use default ignore, but default fixed wildcard. Now, I'm totally happy to have a default argument plugin that can figure out the wildcard and plug it in for you, but I'm very leery of changing the existing behavior. This is not a very common use case, it is something that has grown as Views' usage has gotten more and more advanced over the years.

Subscribe.

Right, but PHP doesn't have an 'ignore'. In this case, with FALSE, you provided a default value. The idea there was that in the above, if you ignore the year, you are going to ignore the month to, and everything after it. And that's the existing behavior, and I am opposed to changing this behavior because it's going to break somebody's view that's relying on this behavior which is in fact how I designed it.

Seems somehow related to #1250336: Any argument after a missing one is silently ignored (D7)

While I appreciate the history behind the current behavior, I'll argue that this really isn't the way to go.

These days, there's a lot of different ways to get arguments into views, apart from urls and custom code, there's (at least) two different ways to put a view into a panel and have arguments passed, and having views ignore later arguments because a "Display all results for the specified field" argument wasn't supplied is a major usability WTF.

A new argument plugin solves the problem in much the same way as using the existing default argument plugin does, which is: not at all. It only adds another option that might confuse new users (2 different options that looks like they're doing the same thing), and another frob to fiddle for those that can't get views to behave as they would expect. And it'll only be people that's spend a couple of hours studying the code that'll really understand the difference.

In my opinion, a better solution would be to change the default behaviour, and create a new "Ignore following arguments" switch to the "when not available" settings, and have view::update() set it for old views using anything but "Provide default value". That makes the behavior optional and explicit, and makes "Display all results..." do what it says on the tin.