Views handlers broken (still use D6 API)

Duplicate of Tags view doesn't adopt correct vocabulary .

Views handlers are broken. Its need some work.

I'd say this is a separate issue actually. #1350292: Tags view doesn't adopt correct vocabulary is about the fact that changing the hashtags vocabulary doesn't change it for the view automatically. This is about a specific Views handler not working.

On the other hand, there are lots of Views handlers that aren't working right now, so I'm making this issue broader in scope.

Here is the patch for not own filter.

Patch for Own filter.

I have one question, Is ti mandatory to use prefixTables?

Patch participant filter.

Patch for communicated filter

I think other than these five filters(including latest only filter), other filters are working fine(Use current context is already ported).

Let's do this the D7 way, by actually using DBTNG expressions, e.g. for _filter_not_own:

$this->query->add_where(0, db_or()
  ->condition("$this->table_alias.type", 'user', '<>')
  ->condition("$this->table_alias.sender", "$this->table_alias.recipient", '<>')
);

Table prefixes will be irrelevant if we do it this way.

Here is a list of handlers with DB statements that need to be fixed:

• _plugin_argument_validate
• _argument_communicated
• _argument_participant
• _argument_rels_and_me
• _field_last (actually I would be okay with removing this field)
• _filter_communicated
• _filter_latest_only
• _filter_not_own
• _filter_own
• _filter_participant

Doing them all in one patch is fine, makes it easier to review.

Yeah. Hereafter I will write the queries in D7 way.

I fixed almost all the filter and field handlers in D7 way except the field_recipient.

When I add that field I'm geeting the following error

SQLSTATE[42S22]: Column not found: 1054 Unknown column 'statuses.uid' in 'field list'

And the query

SELECT statuses.sid AS sid, statuses.message AS statuses_message, users.uid AS users_uid, statuses.recipient AS statuses_recipient, statuses.type AS statuses_type, statuses.uid AS statuses_uid
FROM 
{statuses} statuses
INNER JOIN {users} users ON statuses.sender = users.uid
WHERE (((( (users.uid IN  (SELECT statuses.recipient AS recipient
FROM 
{statuses} statuses
WHERE ( (type = 'user') AND (recipient = '1') ))) OR (users.uid IN  (SELECT statuses.sender AS sender
FROM 
{statuses} statuses
WHERE ( (type = 'user') AND (sender = '1') ))) )AND (users.uid = '1') )))
LIMIT 10 OFFSET 0

I couldn't find a fix for it.

Hmm, seems like that is a problem in 6.x-3.x too. The issue is that the statuses_views_handler_field_recipient class extends views_handler_field_user which adds the "uid" field to the current table in its init method. This can probably be solved by just extending views_handler_field instead. (Interestingly, it looks like I meant to override the link_to_user field, but actually ended up adding a link_to field instead, so it looks like this was a total fail on my part.)

Nevermind. We will fix this. I think we need to look into the fbss comments handlers too.

Why we have two different queries for participant filter and participant argument?

query for participant filter

$this->table.sender = %d OR ($this->table.recipient = %d AND $this->table.type = 'user')

query for participant argument

($this->table.sender = %d OR $this->table.recipient = %d) AND $this->table.type = 'user'

Why we have two different queries for participant filter and participant argument?

The query for the filter is the correct one; the query for the argument is a mistake. Good catch. However if the argument filter is fixed then the conversation view needs to be changed to add a filter so it only shows statuses with the "user" type.

I think we need to look into the fbss comments handlers too.

Yeah, now that you mention it, there are handlers for several submodules that need to be fixed too:

• fbss_comments:
  • _field_cc
  • _field_cc2
• fbss_flag:
  • facebook_status_views_handler_argument_flagged_user (This actually needs to be renamed...)
  • facebook_status_views_handler_filter_flagged_user (This also needs to be renamed...)
• fbss_privacy:
  • _argument
  • _filter
• statuses_tags:
  • _argument_has_this_tag
  • _argument_has_this_tag_id
  • _field_all_terms
  • _filter_has_tag
  • _filter_has_this_tag

Statuses and comments are core for our module. So first we will fix this. We can have separate issues for submodule handlers

I generally consider non-integration submodules to be "core" (i.e. comments, privacy, and tags) and integration submodules to be secondary (activity, domain, flag, mollom, notifications, pathauto, rules, services, twitter, userpoints). That said, I have no problem splitting the submodule views handlers into separate issues and prioritizing them with comments first.

I couldnt find, participant argument and plugin argument validate in contextual filters list in views. Am I missing anything.?

As you mentioned in #16, first we will fix the issues in the core(statuses, comments, privacy and tags).

Added patch for fbss comments handlers.

The participant argument is called either "User is sender or recipient" or "User is participant" and the plugin_argument_validate class isn't a handler, it's a validation option for arguments. So if you add an argument for the status ID for example you will have an option to specify whether Views should validate that it really is a valid status ID.

+++ b/submodules/fbss_comments/fbss_comments_views_handler_field_cc.inc
@@ -11,7 +11,11 @@
   function render($values) {
     $sid = $values->{$this->field_alias};
-    $count = db_query("SELECT COUNT(cid) FROM {fbss_comments} WHERE sid = :sid", array(':sid' => $sid))->fetchField();
+    $count_query = db_select('fbss_comments')
+      ->condition('sid', $sid);
+    $count_query->addExpression('COUNT(cid)');
+    $count = $count_query->execute()
+      ->fetchField();
     return $count;

This is fine, though there's no need for the intermediate $count_query variable -- it can all be simplified into one expression that returns $count.

+++ b/submodules/fbss_comments/fbss_comments_views_handler_field_cc2.inc
@@ -11,7 +11,11 @@
   function render($values) {
     $sid = $values->{$this->field_alias};
-    $count = db_query("SELECT COUNT(cid) FROM {fbss_comments} WHERE sid = :sid", array(':sid' => $sid))->fetchField();
+    $count_query = db_select('fbss_comments')
+      ->condition('sid', $sid);
+    $count_query->addExpression('COUNT(cid)');
+    $count = $count_query->execute()
+      ->fetchField();
     return format_plural($count, '1 comment', '@count comments');
   }

Same deal here -- this is fine, I just would have made it more succinct. No big deal.

addExpression is not chainable, thats why I used an intermediate variable to hold the query.

Here is the patch for fbss_privacy views handlers.

Here is the final patch for this issue. Fixed all the handlers.

I need one clarification regarding plugin_argument_validate. I dunno how to write the following query in D7 way.

db_query("SELECT 1 FROM {statuses} WHERE sid = :sid", array(':sid' => $argument))->fetchField()

I know usage of "SELECT *" or "SELECT sid" is more costlier than "SELECT 1".

Why cant we use the following query instead

db_query_range('SELECT 1 FROM {statuses} WHERE sid = :sid', 0, 1, array(':sid' => $argument))->fetchField()

Limiting it to one result will also increase the performance

Forget to mention onething. I didnt tested statuses_views_handler_argument_rels_and_me, since I'm new to UR, and UR changed lot from D6 to D7. However modified the query in D7 way.

addExpression is not chainable, thats why I used an intermediate variable to hold the query.

Ah, you're right, I misread that.

+++ b/submodules/fbss_privacy/fbss_privacy_views_handler_argument.inc
@@ -32,24 +32,25 @@ class fbss_privacy_views_handler_argument extends views_handler_argument {
-    $query = "{statuses}.private = %d";
     // The argument user must have participated in the status message.
-    $this->query->add_where('fbss_privacy', db_prefix_tables("{statuses}.sender = %d OR ({statuses}.recipient = %d AND {statuses}.type = 'user')"), $argument, $argument);
+    $this->query->add_where('fbss_privacy', db_or()
+      ->condition("{statuses}.sender", $argument)
+      ->condition(db_and()->condition("{statuses}.recipient", $argument)->condition("{statuses}.type", 'user')));
     // Show only private or only non-private status messages.
     if (is_numeric($privacy)) {
       // Only show private messages if the current is the argument user or has admin permissions.
       if (!$privacy || $user->uid == $argument || user_access('view all private status messages')) {
-        $this->query->add_where('fbss_privacy', db_prefix_tables($query), $privacy);
+        $this->query->add_where('fbss_privacy', "{statuses}.private", $privacy);
       }
       else {
         // Return no results.
-        $this->query->add_where('fbss_privacy', db_prefix_tables("$query AND $query"), 0, 1);
+        $this->query->add_where('fbss_privacy', db_and()->condition('{statuses}.private', 1)->condition('{statuses}.private', 1));
       }
     }
     // Show private and non-private messages.
     elseif ($user->uid != $argument && !user_access('view all private status messages')) {
       // Return no results if the current user is not the argument user and has no admin permissions.
-      $this->query->add_where('fbss_privacy', db_prefix_tables("$query AND $query"), 0, 1);
+      $this->query->add_where('fbss_privacy', db_and()->condition('{statuses}.private', 1)->condition('{statuses}.private', 1));

"fbss_privacy" is the Views query group here; {statuses} is the table. So "{statuses}" shouldn't actually be included in any of these queries. If there is a need to use a table name, either use $alias = ensure_my_table() or $alias = ensure_table('foreign_table').

Additionally, the last two queries here are wrong. The values should be 0 and 1, not 1 and 1 so that no results are returned.

Similarly, there's no need to use $table_alias in the rest of this patch, since the table will be automatically added when the query gets compiled.

Using the query as you suggest in #22 is fine. So is not testing the UR handler -- we can address that separately if there is a problem.

+++ b/includes/views/handlers/statuses_views_handler_argument_communicated.inc
@@ -11,10 +11,15 @@
+    $recipient_sub_query = db_select('statuses')
+      ->fields('statuses', array('recipient'))
+      ->condition(db_and()->condition('type', 'user')->condition('recipient', $this->argument));

->condition()s are joined by AND by default. You can just invoke ->condition() several times instead of explicitly using db_and(). This happens in several places.

+++ b/includes/views/handlers/statuses_views_handler_argument_communicated.inc
@@ -11,10 +11,15 @@
+	);

This is too far indented, but actually looks like it should have been on the previous line.

+++ b/includes/views/handlers/statuses_views_handler_argument_participant.inc
@@ -11,6 +11,12 @@
+        ->condition("$this->table.sender", $argument)
+        ->condition(db_and()
+          ->condition("$this->table.recipient", $argument)
+          ->condition("$this->table.type", 'user')

Leave the table out of the queries -- it will be added automatically. This happens in a few places and is true whether the D6 version was using $this->table, $this->table_alias, {statuses}, or whatever.

+++ b/includes/views/handlers/statuses_views_handler_argument_rels_and_me.inc
@@ -14,8 +14,12 @@ class statuses_views_handler_argument_rels_and_me extends views_handler_argument
-    $this->query->add_where(isset($this->options['group']) ? $this->options['group'] : 0, db_prefix_tables("
+    /*$this->query->add_where(isset($this->options['group']) ? $this->options['group'] : 0, db_prefix_tables("
       (($this->table_alias.requestee_id = %d OR $this->table_alias.requester_id = %d) AND $this->table_alias.approved = 1) OR $alias.uid = %d
-    "), $argument, $argument, $argument);
+    "), $argument, $argument, $argument);*/

Just delete the lines instead of commenting things out... no point having cruft hanging around

+++ b/includes/views/handlers/statuses_views_handler_argument_rels_and_me.inc
@@ -14,8 +14,12 @@ class statuses_views_handler_argument_rels_and_me extends views_handler_argument
+    $this->query->add_where(isset($this->options['group']) ? $this->options['group'] : 0, db_or()
+      ->condition(db_and()->condition(db_or()->condition("$this->table_alias.requestee_id", $argument)->condition("$this->table_alias.requester_id", $argument))->condition("$this->table_alias.approved", 1))
+      ->condition("$alias.uid", $argument)
+    );

This would be way easier to read if you moved to a new line each time there is an arrow ->

+++ b/includes/views/handlers/statuses_views_handler_field_last.inc
@@ -12,17 +12,17 @@ class statuses_views_handler_field_last extends views_handler_field {
+	  )

This parenthesis is indented too far. It should either line up with the statement that has its matching paren, or it should go at the end of the previous line.

+++ b/includes/views/handlers/statuses_views_handler_field_recipient.inc
@@ -32,6 +32,7 @@ class statuses_views_handler_field_recipient extends views_handler_field_user {
+    $recipient_id = $values->statuses_recipient;

You can't rely on this being the name of the property; it could change when using prefixed tables or if multiple tables are in the query. Instead use $values->{$this->field_alias} in this case because this handler is tied to the "recipient" field in statuses.views.inc.

+++ b/includes/views/handlers/statuses_views_handler_filter_communicated.inc
@@ -12,10 +12,15 @@ class statuses_views_handler_filter_communicated extends views_handler_filter {
+	);

Indented too far, probably belongs on previous line

+++ b/includes/views/handlers/statuses_views_handler_filter_own.inc
@@ -19,7 +19,10 @@ class statuses_views_handler_filter_own extends views_handler_filter_boolean_ope
+        ->condition("$this->table_alias.type", 'user', '=')

The '=' is not required here

Thanks for your work on this.

Will work on the review points. Committed a fix to dev for fbss comments handlers.

Modified the fbss privacy views handlers as per the comments in #24

I just applied the last commits and I revised all the views one by one to see this:

1. statuses_all: Almost all of the handlers seems ok, but the feed display lacks some 'style extension'
2. statuses_stream: ok
3. fbss_ur_stream: Fails in the argument/handler called 'rels_and_me'
4. statuses_conversation: ok
5. statuses_mentions: ok
6. statuses_followed: Fails related to the issue 'flag_get_flag ...'
7. statuses_tags: Almost all of the handlers seems ok, but the feed display lacks some 'style extension'
8. statuses_private: OK

I don't know if the views are working ok at all, I think so, but just revising the views to find some broken handler.

@edioscom

Views handlers in the following modules got attention in this issue,

• fbss comments (Already committed)
• fbss privacy (Patch is ready and its needs to be reviewed)
• statuses (Almost ready, needs some cleanup)

Here is the list submodules which views handlers will get the attention soon

• fbss flag
• fbss tag

Other submodules needs a port from D6 to D7, So it will take some time for other submodules.

For RSS feed style plugin we have a separate issue Views RSS support missing

Thanks for the report, I just fixed the handlers, didn't looked into the default views.

Revised the patch as per the comments in #25.

Re #27, as I noted in #24, there is no need to use a table alias at all. Just use the field; the table will be added automatically.

@eidoscom thanks for the report

Re the patch in #30:

+++ b/includes/views/handlers/statuses_plugin_argument_validate.inc
@@ -11,6 +11,6 @@
-    return (bool) db_query("SELECT 1 FROM {statuses} WHERE sid = :sid", array(':sid' => $argument))->fetchField();
+    return (bool) db_query_range('SELECT 1 FROM {statuses} WHERE sid = :sid', 0, 1, array(':sid' => $argument))->fetchField();

I know I said this was okay before but there's actually no reason to use db_query_range() instead of db_query() here I think. fetchField() gets the first result out of the returned result set regardless of how many results there are, but there will always only be one result (or no results) in any case.

+++ b/includes/views/handlers/statuses_views_handler_argument_communicated.inc
@@ -11,10 +11,16 @@
-    $this->query->add_where(0, db_prefix_tables("
-        ({users}.uid IN (SELECT sender FROM {statuses} WHERE type = 'user' AND recipient = %d) OR
-        {users}.uid IN (SELECT recipient FROM {statuses} WHERE type = 'user' AND sender = %d))
-        AND {users}.uid <> %d
-    "), $this->argument, $this->argument, $this->argument);
+    $recipient_sub_query = db_select('statuses')
+      ->fields('statuses', array('recipient'))
+      ->condition('type', 'user')
+      ->condition('recipient', $this->argument);
+    $sender_sub_query = db_select('statuses')
+      ->fields('statuses', array('sender'))
+      ->condition('type', 'user')
+      ->condition('sender', $this->argument);
+    $this->query->add_where(0, db_and()
+      ->condition(db_or()->condition('users.uid', $recipient_sub_query, 'IN')->condition('users.uid', $sender_sub_query, 'IN'))
+      ->condition('users.uid', $this->argument));

You have the subquery conditions wrong here. The sender and recipient are mixed up.

Also, I'm pretty sure you can't just write "users.uid" because that will fail if the database uses prefixed tables. Instead get the table alias ($alias = $this->query->ensure_table('users');) and use "$alias.uid".

Additionally, it's easier to read if you don't have more than one arrow -> on one line.

+++ b/includes/views/handlers/statuses_views_handler_argument_rels_and_me.inc
@@ -13,9 +13,12 @@ class statuses_views_handler_argument_rels_and_me extends views_handler_argument
+          ->condition("$this->table_alias.requestee_id", $argument)
+          ->condition("$this->table_alias.requester_id", $argument))

Don't explicitly include $this->table_alias here. $this->table_alias refers to the alias of the statuses table which will be added automatically.

+++ b/includes/views/handlers/statuses_views_handler_field_last.inc
@@ -12,17 +12,16 @@ class statuses_views_handler_field_last extends views_handler_field {
+        ->condition(db_and()->condition('sender', $user->uid)->condition('recipient', $uid))
+        ->condition(db_and()->condition('sender', $uid)->condition('recipient', $user->uid)))

Not a big deal, but this would be easier to read if there was only one arrow -> on each line (i.e. if the sub-conditions were moved to their own lines).

+++ b/includes/views/handlers/statuses_views_handler_field_recipient.inc
@@ -8,7 +8,7 @@
-class statuses_views_handler_field_recipient extends views_handler_field_user {
+class statuses_views_handler_field_recipient extends views_handler_field {

This change reminds me that hook_views_handlers() has been removed in Views 3, so the implementations of it in every .views.inc file in the Statuses project should also be removed. That's not directly related to resolving this issue, so if you want to address it separately then let's open a new issue for it.

+++ b/includes/views/handlers/statuses_views_handler_filter_communicated.inc
@@ -12,10 +12,14 @@ class statuses_views_handler_filter_communicated extends views_handler_filter {
-    $this->query->add_where(0, db_prefix_tables("
-        ({users}.uid IN (SELECT sender FROM {statuses} WHERE type = 'user' AND recipient = %d) OR
-        {users}.uid IN (SELECT recipient FROM {statuses} WHERE type = 'user' AND sender = %d))
-        AND {users}.uid <> %d
-    "), $user->uid, $user->uid, $user->uid);
+    $recipient_sub_query = db_select('statuses')
+      ->fields('statuses', array('recipient'))
+      ->condition(db_and()->condition('type', 'user')->condition('recipient', $user->uid));
+    $sender_sub_query = db_select('statuses')
+      ->fields('statuses', array('sender'))
+      ->condition(db_and()->condition('type', 'user')->condition('sender', $user->uid));
+    $this->query->add_where(0, db_and()
+      ->condition(db_or()->condition('users.uid', $recipient_sub_query, 'IN')->condition('users.uid', $sender_sub_query, 'IN'))
+      ->condition('users.uid', $user->uid));

The same problems exist here as I noted in my comment about statuses_views_handler_argument_communicated above.

+++ b/includes/views/handlers/statuses_views_handler_filter_not_own.inc
@@ -19,7 +19,9 @@ class statuses_views_handler_filter_not_own extends views_handler_filter_boolean
+        ->condition("$this->table_alias.type", 'user', '<>')
+        ->where("$this->table_alias.sender <> $this->table_alias.recipient"));

Don't use the table alias here

+++ b/includes/views/handlers/statuses_views_handler_filter_own.inc
@@ -19,7 +19,9 @@ class statuses_views_handler_filter_own extends views_handler_filter_boolean_ope
+        ->condition("$this->table_alias.type", 'user')
+        ->where("$this->table_alias.sender = $this->table_alias.recipient"));

Don't use the table alias here

Removed table alias in all the handlers. and also removed the hook_views_handlers from statuses.view.inc

+++ b/includes/views/handlers/statuses_plugin_argument_validate.inc
@@ -11,6 +11,6 @@
-    return (bool) db_query("SELECT 1 FROM {statuses} WHERE sid = :sid", array(':sid' => $argument))->fetchField();
+    return (bool) db_query_range('SELECT 1 FROM {statuses} WHERE sid = :sid', 0, 1, array(':sid' => $argument))->fetchField();

Yeah, we will have only one result(or no result), however its better to limit the result to one when checking the existence.

Regarding table alias in conditions, I think the alias is not added automatically for conditions(May be I'm wrong on this. I'm quite new to writing own views handlers)

Here is the query which I got for filter_communicated

SELECT statuses.sid AS sid
FROM 
{statuses} statuses
INNER JOIN {users} users ON statuses.sender = users.uid
WHERE (((( (users.uid IN  (SELECT statuses.recipient AS recipient
FROM 
{statuses} statuses
WHERE  (type = '2') AND (sender = '2') )) OR (users.uid IN  (SELECT statuses.sender AS sender
FROM 
{statuses} statuses
WHERE  (type = 'user') AND (recipient = '2') )) )AND (users.uid = '2') )))
LIMIT 10 OFFSET 0

Will remove other hook_views_handlers too.

Added the revised patch. I need to revise the patch in #27(For fbss privacy), If we decide to remove table_alias in conditions.

Yeah, we will have only one result(or no result), however its better to limit the result to one when checking the existence.

Actually, I'm pretty sure the only difference between using db_query_range() and db_query() here is that db_query() adds a LIMIT 1 OFFSET 0 statement to the query, which makes it marginally slower because the result of the query has to be truncated after it's complete (though the performance difference is diminishingly small). The same value gets passed back to PHP either way. But like I said, it doesn't really matter.

Regarding table alias in conditions, I think the alias is not added automatically for conditions

Indeed, looks like I'm wrong on this.

I didn't go through the patch in #32 as thoroughly as I have the other patches but it looks ready to commit to me. (The patch to the privacy submodule looks fine too.) Leaving this issue at "needs work" to address the remaining issues:

• Updating the handlers for the Flag and Tags submodules
• Removing the hook_views_handlers() implementations from all submodules with Views integration
• Backporting some of the bug fixes identified in this issue to D6
• Fixing the UR rels_and_me handler

All of these things can be handled in separate issues, though they're related enough that it's fine to continue using this issue for everything except the D6 backport.

Actually, I'm pretty sure the only difference between using db_query_range() and db_query() here is that db_query() adds a LIMIT 1 OFFSET 0 statement to the query, which makes it marginally slower because the result of the query has to be truncated after it's complete (though the performance difference is diminishingly small). The same value gets passed back to PHP either way. But like I said, it doesn't really matter.

Got it, will use db_query()

Will commit the patch for statuses and fbss privacy views handlers. Already I started to work on the tags and flag views handlers. For rels_me I need to look into UR.

Added tag for reference.

Committed the patch in #32 to dev.

Committed a fix to dev for the following,

• fbss privacy views handler issues
• Removed hook_views_handlers from fbss comments and fbss privacy submodules
• Replaced db_query_range() with db_query() for status argument validate

I have one question regarding statuses_tags_views_handler_filter_has_this_tag. In this filter we have autocomplete field to select the specific statuses tag

   if (variable_get('statuses_tags_vid', -1) != -1) {
      $form['value']['#autocomplete_path'] = 'taxonomy/autocomplete/' . variable_get('statuses_tags_vid', -1);
    }

Where this value is used in the query(I think, value of this field is assigned to the variable $upper).

If so autocomplete for taxonomy is changed a lot in D7, We should pass the field name not the specific vid. In this case can we write our own callback to to fetch the taxonomy from the specified id?

You should be able to use the path admin/views/ajax/autocomplete/taxonomy which calls views_ajax_autocomplete_taxonomy().

The autocompleted value eventually gets used in the $where variable in op_equal(), op_contains, etc. $upper is typically the string 'UPPER'. You can check this by printing out the values, typically using the dsm() function from the Devel module which can handle pretty-printing complex arrays and objects.

Here is the patch for statuses tags views handlers.

I have couple of questions regarding has_this_tag_id argument handler,

First one, There is following condition, however I dunno where is the column called statuses.pid
$query .= "AND $this->table_alias.pid IN (%d, %d)";
For now commented this condition.

Second, I think there is problem with a if else satements, Currently its in the following structure

if (count($this->value) > 2) {
}
if (count($this->value) == 2) {
}
else{
}

However it should be like this,

if (count($this->value) > 2) {
}
else if (count($this->value) == 2) {
}
else{
}

First one, There is following condition, however I dunno where is the column called statuses.pid

Wow. This is cruft from FBSS 6.x-2.x. There is no "pid" column any more -- it was renamed to "sender." Previously it stood for "poster ID."

Second, I think there is problem with a if else satements

Looks like you're right.

+++ b/submodules/statuses_tags/views/statuses_tags_views_handler_argument_has_this_tag_id.inc
@@ -44,60 +44,41 @@ class statuses_tags_views_handler_argument_has_this_tag_id extends views_handler
-    if (count($this->value) == 2) {
+    else if (count($this->value) == 2) {

Should be "elseif" not "else if"... I actually prefer it the way you have it but that's what the Drupal Coding Standards document says

+++ b/submodules/statuses_tags/views/statuses_tags_views_handler_filter_has_this_tag.inc
@@ -39,42 +39,48 @@ class statuses_tags_views_handler_filter_has_this_tag extends views_handler_filt
-    $upper = $this->case_transform();

Transforming things to the same case can't just be discarded. I don't know if this is still the right way to do it, but there is an option to make filters "case insensitive" in which case the 'UPPER()' function needs to be used.

Otherwise the patch in #39 looks good.

Transforming things to the same case can't just be discarded. I don't know if this is still the right way to do it, but there is an option to make filters "case insensitive" in which case the 'UPPER()' function needs to be used.

How to achieve this? I couldn't find case transformation in views_handler_filter_string itself.

Huh, you're right, looks like that option was removed in D7. I wonder why. Anyway, my fault, I should have done my research first.

@Isaac :)

Committed a fix to dev for statuses tags submodule view handlers.

Here is the patch for fbss flag views handlers.

In both handlers variable $content_type is used, however its not defined anywhere. So I assumed that the content type, here is statuses.

FYI I committed a change to dev to replace %% with % in statuses_tags_views_handler_filter_has_this_tag.inc (I guess I missed that when reviewing the patch).

The patch in #44 looks good to me (you're right about $content_type).

I think once #44 is committed the only thing left is the UR rels_and_me handler and the D6 backport of some bug fixes made here. Let's address those in separate issues.

Committed a fix to dev for fbss flag views handlers.

Will create separate issue for rels_and_me handler(I think the new issue should cover complete UR integration).

Regarding D6 port, New issue should be created in Facebook-style Statuses (Microblog) and will create a patch for that too.

Statuses is no more unstable, we can go for stable release soon :)

Keeping the status as patch to be ported, until bug fixes made here are committed to 6.x branch

Yeah, this issue fixed means the core modules are reasonably stable. These are the 3 issues that are next most important:

#1501978: Create an upgrade path from Facebook-style Statuses (D6)
#1255648: Rules integration is broken
#1296238: calls to flag_get_flag('follow')->fid or ->status fail

With those fixed I would release an alpha. A beta would need to have nothing really completely broken, i.e. none of the integrations should be throwing errors even if they're not 100% upgraded (the one exception is Notifications; I'm okay with dropping that, given how painful writing that integration was the first time) and preferably the low-hanging fruit from this queue should be picked off (actually most of those aren't too bad). For an RC we need to test broadly and make sure almost everything works and the confirmed bug/task queue is low. I'm okay with getting in a few feature requests and postponed issues too as long as they aren't large fundamental changes.

Once the handlers are ok, all is working well. Good work to all ;)

I have a question. If I want to format the sender pic with some image style, I can't do it in the view because I can format the field output.... Where must be the option to do this?? It seems that you can define a user image at size that you want to show in the statuses boxes but I need to have the large version of the image ...

thanks

@eidoscom:

Your question is unrelated to this issue; in the future, please open a separate support request for things like this.

The short answer to your question is that you need the Imagecache Profiles module to be able to use image styles for user profile pictures. If you have that module installed then you will have an option to choose an image style when you click on the "Sender picture" field while editing a View.

Here is the patch for D6 backport.

Committed backport to FBSS dev.

I opened #1511686: Conversation view shows posts that are not part of the conversation because there is one point that was missed in this issue, but I'm happy to put this issue to rest.