Views integration is broken in the 7.x branch

Oh, ok. Seems no Flag views integration is getting picked up at all. Bumping in priority.

First issue is flag_views_api() is still specifying 2.0, we need 3.0.

Then, when you clear the Views cache, you get this:

Notice: Use of undefined constant FILTER_FORMAT_DEFAULT - assumed 'FILTER_FORMAT_DEFAULT' in flag_views_default_views() (line 261 of /Users/webchick/Sites/drupal-7.x-dev/sites/all/modules/flag/includes/flag.views_default.inc).

I replaced that with a call to http://api.drupal.org/api/function/filter_fallback_format/7. (and left a comment about this at http://api.drupal.org/api/constant/FILTER_FORMAT_DEFAULT/6#comment-4624)

This causes the Flag views to show up in the list, but for example /bookmarks is a 404. I re-saved the Flag view and it's now showing up, but there are still odd errors. I figured a straight-up export of the newly-saved view would help, but it appears flag.views_default.inc is doing some weird stuff to try and save on code, so I still need to look at that a bit more.

Anyway, here's an initial stab that gets us this far.

A little closer. Now /user/%/bookmarks works as intended. /bookmarks is still telling me I haven't bookmarked anything even though I have, though.

Hm. But even still, neither of these are appearing on a fresh install. :( Only when I clear the views cache. And then I still have to save them each individually to get them to not 404.

Furthermore, I have absolutely no idea why that /bookmarks view is only showing empty text. The logic appears sound.

Query in D6:

SELECT node.type AS node_type,
node.title AS node_title,
node.nid AS nid,
users.name AS users_name,
users.uid AS users_uid,
node_comment_statistics.comment_count AS node_comment_statistics_comment_count,
node_comment_statistics.last_comment_timestamp AS node_comment_statistics_last_comment_timestamp,
flag_content.content_id AS flag_content_content_id
 FROM node node 
 INNER JOIN flag_content flag_content_node ON node.nid = flag_content_node.content_id AND (flag_content_node.fid = 1 AND flag_content_node.uid = ***CURRENT_USER***)
 INNER JOIN users users ON node.uid = users.uid
 INNER JOIN node_comment_statistics node_comment_statistics ON node.nid = node_comment_statistics.nid
 LEFT JOIN flag_content flag_content ON node.nid = flag_content.content_id AND (flag_content.fid = 1 AND flag_content.uid = ***CURRENT_USER*** AND flag_content.sid = 0)
 WHERE node.status <> 0
   ORDER BY node_comment_statistics_last_comment_timestamp DESC

Query in D7:

SELECT node.type AS node_type, node.title AS node_title, node.nid AS nid, users.name AS users_name, users.uid AS users_uid, node_comment_statistics.comment_count AS node_comment_statistics_comment_count, node_comment_statistics.last_comment_timestamp AS node_comment_statistics_last_comment_timestamp, flag_content.content_id AS flag_content_content_id
FROM 
{node} node
INNER JOIN {flag_content} flag_content_node ON node.nid = flag_content_node.content_id AND (flag_content_node.fid = 1 AND flag_content_node.uid = ***CURRENT_USER***)
INNER JOIN {users} users ON node.uid = users.uid
INNER JOIN {node_comment_statistics} node_comment_statistics ON node.nid = node_comment_statistics.nid
LEFT JOIN {flag_content} flag_content ON node.nid = flag_content.content_id AND (flag_content.fid = 1 AND flag_content.uid = ***CURRENT_USER*** AND flag_content.sid = 0)
WHERE (( (node.status <> 0) ))
ORDER BY node_comment_statistics_last_comment_timestamp DESC
LIMIT 25 OFFSET 0

The only differences appear to be:
1. The D7 version of Views wraps the table names in {}s, like {node} and so on.
2. The where clause is WHERE (( (node.status <> 0) )) instead of just WHERE node.status <> 0, but apart from some stupid extra parentheses, it seems to match?
3. The D7 version includes the LIMIT clause

Need a hand on this one. :(

(I do "grep -r CURRENT_USER ." and don't see it handled)

Hm. Really?

webchicks-MacBook-Pro:views webchick$ grep -r 'CURRENT_USER' .
./modules/user/views_handler_filter_user_current.inc:    // OLD: $this->query->add_where($this->options['group'], "$this->table_alias.$this->real_field " . (empty($this->value) ? '!=' : '=') . " ***CURRENT_USER***");
./modules/user/views_handler_filter_user_current.inc:    // NEW: $this->query->add_where($this->table_alias . '.' . $this->real_field, CURRENT_USER, empty($this->value) ? '!=' : '=');
./modules/user/views_handler_filter_user_current.inc:      $where .= '<> ***CURRENT_USER***';
./modules/user/views_handler_filter_user_current.inc:      $where .= '= ***CURRENT_USER***';

It appears to be there, at least in my CVS checkout from a couple of days ago. But that's a good thought; if that wasn't being converted properly and ended up being "0" or some-such, that would certainly explain the results...

Ha. I tried turning on Devel query log and get this:

Fatal error: Exception thrown without a stack frame in Unknown on line 0 

Wheeeeee... :P #376824: Query log displays dreaded Fatal error: Exception thrown without a stack frame in Unknown on line 0 on Views pages

Ok, talking to dereine in #drupal-views, and #812970: Get Views Query substitutions working is the upstream Views issue for the ***CURRENT_USER*** problem.

Incidentally, your spidey sense about ***CURRENT_USER*** was right on, apparently this code exists in Views 7.x atm. ;)

      // Add additional arguments as a fake condition.
      // XXX: this doesn't work... because PDO mandates that all bound arguments
      // are used on the query. TODO: Find a better way to do this.
      if (!empty($additional_arguments)) {
        // $query->where('1 = 1', $additional_arguments);
        // $count_query->where('1 = 1', $additional_arguments);
      }