The filter "Node: Has new content" doesn't work after the upgrade to 6.2-2.6.

The reason is a not completely implemented bug-fix: #384286: Make it possible to expose the filter for "Node: Has new content". In this the filter is made exposable. The test for the filter if not exposed is not implement as written in the comment. So in the case the filter is not made exposed the data is newer filtered for "new content".

*** views_handler_filter_history_user_timestamp.inc.orig	2009-06-11 19:22:38.000000000 +0200
--- views_handler_filter_history_user_timestamp.inc	2009-06-11 19:12:25.000000000 +0200
***************
*** 38,44 ****
      }
  
      // Don't filter if we're exposed and the checkbox isn't selected.
!     if (empty($this->value)) {
        return;
      }
  
--- 38,44 ----
      }
  
      // Don't filter if we're exposed and the checkbox isn't selected.
!     if ( (!empty($this->options['exposed'])) && empty($this->value) ) {
        return;
      }

Comments

sl27257’s picture

sl27257
Location Stockholm
commented
Title: Filter "Node: Has new conten" doesn't work after upgrade » Filter "Node: Has new content" doesn't work after upgrade
Tally’s picture

Tally commented

My views that relied on a filter of Node: Has new content broke after the upgrade. They were showing every node that met the other filter criteria.

I applied the above patch and those views are functioning properly now. I compared the Views Query from a non-upgraded test site (I have 3 of them!) to the site with the patched copy of 6.x-2.6. The Queries are the same. The output of the views matches, also. As far as I can tell, the broken view is now working fine.

I vote that the patch is good, but I am just a nube at all this.

Paul Natsuo Kishimoto’s picture

Paul Natsuo Kishimoto commented
Status: Needs review » Reviewed & tested by the community

I agree with Tally that this is RTBC. The file being patched, if it wasn't clear to anyone, is modules/user/views_handler_filter_history_user_timestamp.inc (from the module root).

I hope this can be pushed out quickly, as it breaks the Organic Groups default og_unread view...presumably affecting 5700+ users of OG 6.x.

Paul Natsuo Kishimoto’s picture

Paul Natsuo Kishimoto commented
Priority: Normal » Critical

...on second thought, marking critical for the above reason (& vanity!)

sl27257’s picture

sl27257
Location Stockholm
commented

Ok,

thanks for your comments. I don't really know the procedure but I have seen that attached files with the extension .patch are somehow checked by the underlaying system.

Anyhow I am not a member of this project so I would really appriciate if someone involved could bring some light on what / how (I have) to do... Please! :-)

/Thomas

merlinofchaos’s picture

merlinofchaos commented

At this point I think you just have to wait for me to have the time to review, confirm and either feedback or commit. I haven't been loaded with free time lately so it takes me awhile to work up to a run of Views patch reviews.

weimeng’s picture

weimeng commented

Seems like the patch works.

Also, the file to be patched is at

modules/node/views_handler_filter_history_user_timestamp.inc

instead of the location mentioned #3.

andy inman’s picture

andy inman commented

Also had this problem after upgrade to D6.12 - ran this patch and it does indeed seem to fix the problem.

For those not so familiar with Drupal directory structure, the file you need to patch is at either:

1. (drupal)/sites/all/modules/views/modules/node/views_handler_filter_history_user_timestamp.inc

... where (drupal) is the path to your Drupal installation, perhaps something like /var/www/drupal-6.12 but will depend on various factors.

or

2. (drupal)/sites/(sitename)/modules/views/modules/node/views_handler_filter_history_user_timestamp.inc

... where (drupal) is as described above and (sitename) is the directory name that matches your site. Most likely you have Views installed in ../sites/all so (1) above is more likely the case than (2).

andy inman’s picture

andy inman commented

Additional - as far as I can see the problem is more generic than exposed filters - in my case I had a Views based block with no exposed filters, but a filter on "has new content". So, I'm suggesting that the "Component" here may be set wrongly.

merlinofchaos’s picture

merlinofchaos commented
Status: Reviewed & tested by the community » Fixed

Committed to -dev. Thanks for the patch!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.