AS far as I can tell, Views 1.x had a "Argument handling Code" field box that would process arguments in all calls of the view.

Views 2.x only has the "Action to take if argument is not present: >> Provide default argument >> Default argument type: >> PHP Code" option.

The problem is that the code inserted in the "PHP Code" box is only called when there is no argument in the URL so there is no way to process via PHP all arguments.

Is this a feature or a bug?

Comments

dawehner’s picture

dawehner
Primary language German
commented
Status: Active » Fixed

Its a bug .... of your usage. You have to use validator -> php code in the argument settings.

rsevero’s picture

rsevero commented
Category: bug » support
Status: Fixed » Active

Ok, maybe this isn't a bug report. I changed it to support request.

But I think I might not have made myself clear, I know I can analyze every argument with Validator PHP Code. But can I analyze AND change them?

I've just tried to do it but I couldn't find a variable/object/whatsoever where I would assign then new arguments that I came with after analyzing the original ones, i.e., I want to analyze the given arguments AND change them.

This issue is the only place I see any kind of mention to the possibility of changing arguments inside Validator PHP Code. If I can't change arguments inside Validator PHP Code the original comment I made when opening this issue is still in need of an answer.

rsevero’s picture

rsevero commented

If I'm right that the "Handle arguments through PHP" feature available in views 1 (where handle = analyze + change) isn't available in any form in views 2 I would like to know if views 2 maintainers would be interested in a patch that create such a feature.

I believe it won't be really hard to create it and I would prefer to expend time creating such a patch instead of an in house solution for my use only.

Please advise.

merlinofchaos’s picture

merlinofchaos commented
Status: Active » Fixed

If you need something that complex, I recommend you use hook_views_pre_build() and do your analysis there. We have worked to try to reduce the PHP that is actually embedded into a view to the minimum, so when things get to the level of complexity that you appear to need, a hook is the best way to go about it.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.