Returning nid not working (maybe I 'm misunderstanding)

I have the same issue.

i had the same problem for excluding a node by node id, i added that :
$query->add_where("node.nid NOT IN (%s)", $filter['value']);
in line 76 , but this solution is only for the option "ID list"

Same issue. Does not seem to function either with list or PHP options, returns list of many other nodes :(. Have tried to contact author but have not received response. Will see what I can do to patch tomorrow or soon :P

Ali27: have you self-assigned because you are committed to fix?

That's strange; I haven't heard from you. How did you try to contact me?

The module has been tested multiple times with PHP code, and prior commenters in other issue items have noted that it works. Not to mention we've been using it in production for over half a year. Perhaps there's a problem with your PHP code?

As far as the ID list option, the README notes that it's for testing. It is not a production feature, and is not in the current published build. The README also mentioned that it would survive if it was a feature people wanted. Requests were understandably few, as there are plenty of other ways to pick out individual nodes (including assigning them to a taxonomy, probably the most straightforward and appropriate way.)

I have gotten a small handful of requests regardless -- very few, but I'll entertain a patch that re-enables the feature. I'm actually a little surprised no one's picked up why the ID list doesn't work already, frankly. I thought it was sort of obvious. Line 60: if($filter['options']=='php'); the subsequent code block clearly constructs the $nids variable based on the PHP code. There's no block to handle the ID list option. All you need to reenable the ID list is an else clause after that code to construct the $nids variable from the filter value directly. That's one line of code. Should work; at the very least that may be enough to get somebody that wants to roll a patch started.

And please: if you have a patch to submit, roll a proper patch and attach it. If you don't know how, there are instructions in the developer docs.

You'd think something like

$return=array(0 => 7,  1 => 84);
return $return;

would work, wouldn't you? It did a few months ago... and does on our other sites... but something seems to have changed in the views query execution over in views_query.inc ... and it outputs quite a bit of other nodes if you step through it during execution.

In any case, did note that on list view a few months ago as well, but forgot... and of course, that you mention that this isn't written to exit cleanly if the filter doesn't eval cleanly... oh, goodness, another open point to eval(), we just did that again over in panels2...

In any case, also good to hear you're alive. I dropped a question via your contact form when I first used viewsphpfilter quite a while ago, and another asking if you're still maintaining it a few months ago...

If there's anything going on with views queries that isn't specific to our install, I'll let you know... I was just trying the list input again to debug, and probably won't patch (it'd be easy) as what's happening is clear from a debugger run...

'Normal'izing, btw... ali- or alpha-, if you have Qs, I'll try to answer.

This was a can't-dupe for me, but I just refactored some of the code and did some more NID list testing; just committed it after a good deal of testing. It works fine with the latest version of 5. (There's a 6 branch now as well.) Let me know if your problems persist.

And @kenthomas: yes, it is noted that if the PHP code is bad and the eval fails, the filter fails silently. Has been since the project's first dev snapshot. It's in the release notes.

Gave it a couple of weeks; marking as fixed and closing.

I had this same problem briefly with the 6.x version of the code, but then it went away after I started putting dpr() statements in my code, I think it may have been a cacheing problem.