I have a view (http://gr8tour.info/test/cities). It lists all nodes of type 'City'.
I also have a content type called 'Accommodation' which has a node reference field to 'City' (i.e. accommodation is located in a city). I have a view of all accommodation nodes (http://gr8tour.info/test/all) which takes a City name as an argument.

Now, because I don't want a city listed in the above view if there are no accommodation nodes within that city (i.e. no nodes with a node reference to that city), I've added the following code as a PHP filter to my view:

<?php
$nodes = array();

$city_view = views_get_view('Test');
$city_view->set_item('page_3', 'filter', 'nid_php', NULL);
$city_view->set_display('page_3');
$city_view->set_arguments(array());
$city_view->pre_execute();
$city_view->execute();

foreach ($city_view->result as $city) {
  $accommodation_view = views_get_view('Test');
  $accommodation_view->set_display('page_1');
  $accommodation_view->set_arguments(array($city->node_title));
  $accommodation_view->pre_execute();
  $accommodation_view->execute();

  if (!empty($accommodation_view->result)) {
    $nodes[] = $city->nid;
  }

  $accommodation_view->destroy();
}

$city_view->destroy();
return $nodes;
?>

This basically means if the Accommodation view is empty when the current City is added as an argument, don't display that City in the first place.

The problem is this: When I'm logged in as an administrator, I see the view as it should be: a list of 5 cities. However, when I see that same view as an anonymous user, I see a list of almost 30 cities!

I've worked out that it has to do with the 'Administer Nodes' permission. If I give anonymous users that permission, they see the view with only 5 cities as it should be. Without it, they see all cities.

I'm wondering whether this is something the Views PHP Filter module has done wrong, or if this is a deeper issue in Views...?

CommentFileSizeAuthor
#4 view_export.txt7.53 KBAnonymous (not verified)

Comments

dawehner’s picture

dawehner
Primary language German
commented

As far as i understand it, this is yet another dupllicate nodes problem. There are quite some :) http://drupal.org/project/issues/views?text=duplicate&status=Open&priori...

Therefore you have to update to the latest development version and commit the patch from http://drupal.org/node/284392

Can you give some feedback, whether you have duplicate content?

Anonymous’s picture

Anonymous (not verified) commented

I'm not actually getting duplicate content, just content that shouldn't be there...
Is it still worth trying the patch in that case?

EDIT: i.e. anonymous users are seeing:
node1
node2
node3
node4
node5
etc.

They should only be seeing (as the admin role does):
node2
node3
node4

dawehner’s picture

dawehner
Primary language German
commented
Status: Active » Postponed (maintainer needs more info)

Puh. Are you really sure you gave then a detailed issue?

node2
node3
node4

How do you restrict the content....

I'm wondering whether this is something the Views PHP Filter module has done wrong, or if this is a deeper issue in Views...?

How do you use this.

And you have to export your view.... I thought you would have to know this...

Anonymous’s picture

Anonymous (not verified) commented
Status: Postponed (maintainer needs more info) » Active
StatusFileSize
new view_export.txt7.53 KB

Sorry, the 'node1, node2, etc.' are just to show that the results aren't duplicates (i.e. they're different nodes).

I restrict the content using the PHP code I posted above using the Views PHP Filter module.
Views PHP Filter works by simply filtering the results of the view to only show nodes whose node IDs are returned by the PHP code.

An export of my view is attached.

merlinofchaos’s picture

merlinofchaos commented

If this is a case of the PHP filter not working, and that's the only problem, this should be filed against that module. (If that's not the problem and I misunderstood, I apologize in advance).

Anonymous’s picture

Anonymous (not verified) commented

I was tossing up where to submit this to...

The PHP filter is working, but it seems only for users that have the 'Administer Nodes' permission. I searched through the PHP filter module for references to permissions or user access, but couldn't find anything. It seems to be a very simple module.

I therefore thought it could be something in Views that's causing the issue (possibly related to the code I'm using above), but it's just a guess.

merlinofchaos’s picture

merlinofchaos commented

Well, if the filter is supposed to remove records, and in one case it does not, then the filter is at least where to start. If it turns out not to be the culprit, it can be kicked back to Views, but I have no way of knowing that since I don't use the PHP filter at all, and I've never heard of anything like that (other than db_rewrite_sql and DISTINCT problems, but that causes dups, not failed filters).

Anonymous’s picture

Anonymous (not verified) commented
Project: Views (for Drupal 7) » Views PHP Filter
Version: 6.x-2.7 » 6.x-1.0-beta1

No problem, moving to Views PHP Filter issue queue...

gnassar’s picture

gnassar commented

First things first -- run a preview of the module and let us know what the generated SQL is.

All Views PHP Filter does is throw an extra add_where() into the Views query with "nid IN (list of nodes)"; the list of nodes is from the array that your PHP returns.

So if you're getting different results with anonymous and registered users, but the filter is filtering, it would seem like the problem is either in your PHP or in the Views module itself (since your PHP pulls some views to begin with).

Anonymous’s picture

Anonymous (not verified) commented

Here's the generated SQL for my test view (which I've allowed anonymous users to see):

SELECT node.nid AS nid,
   node.title AS node_title
 FROM node node 
 WHERE (node.status <> 0) AND (node.type in ('city')) AND (node.nid IN (193,196,198,199,299))

Note that I was logged is as administrator (and could therefore see the correct view output) when getting this SQL.

On a hunch, I gave my Staff role (who, as I mentioned previously, sees the wrong view output) permission to administer Views and checked the SQL when logged in as them. Here it is:

SELECT node.nid AS nid,
   node.title AS node_title
 FROM node node 
 WHERE (node.status <> 0) AND (node.type in ('city'))

Hope this helps.

gnassar’s picture

gnassar commented

The lack of viewsphpfilter's entry in the WHERE clause means that your code is returning an empty set when it executes. I'm guessing one of the views you're trying to load in your code is not set to allow being viewed by the Staff role, in which case your calls would return nothing.

(On a side note, technically the filter should be adding a "nid IS NULL" clause to the WHERE statement when given an empty array, instead of just not returning anything like it would if actually passed a NULL; this is recorded in issue #593768. But that would simply have Staff users being able to see *no* records instead of *all* records, and so isn't really your problem. It does, however, explain the specific behavior you're seeing.)

Anonymous’s picture

Anonymous (not verified) commented

All views related to this problem are displays within the one 'Test' view on my site. All these displays are set to 'Access: Unrestricted'...

gnassar’s picture

gnassar commented

Well, that was the one guess I had. Beyond that, all you have left is triaging your PHP to figure out why it would return an empty array in the Staff role but not in others.

gnassar’s picture

gnassar commented

For that matter, have you tried creating the view as a page, and then looking at it with both an Admin and a Staff account and seeing if your returned records are different?

I've committed some patches that provide some basic error messages for obviously bad PHP code. I don't know if this will help, but it may. The patches also fix the "empty treated as null" bug I mentioned earlier, so instead of 30+ results, you'll probably get 0. Should be OK for testing as soon as the contrib server rolls a nightly buid.

Anonymous’s picture

Anonymous (not verified) commented
Project: Views PHP Filter » Views (for Drupal 7)
Version: 6.x-1.0-beta1 » 6.x-2.8

The PHP code I was using was causing the front page to load very slowly (taking up to 15 seconds), so I replaced it with a module function that uses SQL to get information from the database directly. This seems to be much faster and has also done away with the problem of different roles getting different results, so I think the issue was definitely in the Views loading code (see first post above).

I'll move this back to the Views issue queue, but as I'm not using the code anymore (and therefore not experiencing the problem), it might be better to just close the issue...?

Anonymous’s picture

Anonymous (not verified) commented
Status: Active » Closed (fixed)