I came across a project that required views_get_view_result to take a third argument, $filters. I didn't want this to pull from a URL because i was processing the data in a very specific way. I though it would be good to add this as a feature to views, in the event that someone else could use it.

I have included the patch that does just this, and handles it in the same way as the $display_id.

Comments

dawehner’s picture

Status: Needs review » Needs work
+++ b/views.moduleundefined
@@ -2143,6 +2146,9 @@ function views_get_view_result($name, $display_id = NULL) {
     }
+   	if ($filters) {

It would be cool if you could proper drupal code style aka spaces here. The rest looks pretty fine

kbalderson’s picture

Per drupal standards, now using spaces instead of tabs.

I also changed the variable name to more accurately align with the current views nomenclature. (exposed_input instead of filters)

dawehner’s picture

Now it would be even cooler if would document the new variable in the function header.

kbalderson’s picture

Done. Am I cool enough yet?

merlinofchaos’s picture

Status: Needs work » Closed (won't fix)

This doesn't really fit alongside views_embed_view and completely changes the function signature for anyone using it now. That is severe API breakage of the kind that is not acceptable in a minor release.

Like views_embed_view, if you want to add exposed filters, you have to take the function apart. It is not a long piece of code, honestly, as most if the if checks are not really necessary for your code.

kbalderson’s picture

That's fine. not really knowing the ins and outs of the api, I thought to contribute something that helped me.

Thanks for the input.