Closed (fixed)
Project:
Views (for Drupal 7)
Version:
6.x-3.x-dev
Component:
Miscellaneous
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
29 Jun 2010 at 17:01 UTC
Updated:
6 Apr 2011 at 00:02 UTC
Jump to comment: Most recent file
Comments
Comment #1
marcp commentedPatch is attached.
Comment #2
bonobo commentedAny word on this?
Comment #3
dawehnerCan you explain why you do this?
Default argument's are only used when Action to take if argument is not present: which is not the case here. I don't see the point why it's needed currently.
Comment #4
bonobo commentedThe use case is similar to what is described here - the argument works for the page display, but doesn't work for the block display.
This patch addresses the issue.
Comment #5
bonobo commentedAny word on this?
Comment #6
k3n3dy commentedI'm experiencing this problem. It seems Views just doesn't see the tid argument in the URL. I applied the patch but nothing changed.
Using Drupal 6.19
Views 6.x-2.11
Faceted Search 6.x-1.x-dev
Everything works as expected with pages. When I use blocks (and I need it) it just doesn't work at all.
Any suggestion is very much appreciated.
Thanks.
Kenedy
Comment #7
merlinofchaos commentedOk. My apologies about the delay getting to this. The Views 'needs review' queue is very large and there's a large number of patches that have sat for awhile.
Ironically, bumping the patch in your case made it wait longer, because when I do try to hit the needs review queue,I go oldest first. Bumping it moves it to the top, so I assume it hasn't been waiting as long and it doesn't end up getting consideration. Go figure.
I think this patch makes sense. However, a patch for just 6.x-2.x can't be committed. I need patches for 6.x-3.x primarily, and then I have to consider if this is serious enough to put in 6.x-2.x. This is not technically a bug, this is a new feature. I've let some new features into 2.x when I figure they're valuable enough to deal with the potential disruption. I'm wavering on this. I don't see that this one really needs to go into 2.x but I also don't see it as too disruptive.
Comment #8
merlinofchaos commentedComment #9
marcp commentedPatch for 6.x-3.x is attached.
You can test it out quickly with the following view which provides a page accessible at termposts/% and a block that should show up on any page where tid is an argument. Before applying the patch, the block will not appear when viewing termposts/%.
Comment #10
AlsApplied the patch for Views 2.x but problem not solved (like #6).
Using Drupal 6.17 + Views 2.11 + block view. Working perfectly in preview, with tid argument entered manually.
I see the problem also in standard nodes, so I suppose the "taxonomy term ID from URL" does not work at all (not just in page views) when standard paths are tweaked by Pathauto, which is essential for SEO.
Hope the patch can be accepted, 10 rows to correct URL scanning seems not a great risk?
I have worked around the problem switching the "default argument type" to PHP code and using the following:
1) With Drupal's original links. Always valid as real URLs remain active even when aliased:
if (arg(0) == 'KKKKK' && arg(2) != '') {
return arg(2);
}
Where
- arg(0) = reference to specific paths ('KKKK'). Optional, prevents unexpected behaviour if the argument is used in URLs all over the site.
- arg(2) = assuming that taxonomy id is the 3rd part of the URL.
Example
URL: http://www.sitename.com/KKKK/page/1
KKKK will be read as arg(0), 1 will be arg(2) and returned as tid.
2) With aliased URLs:
$pageurl = drupal_get_path_alias($_GET['q']);
$pageurl = explode('/', $pageurl);
return $pageurl[2];
Where
- first row reads aliased URL
- second row splits it in an array
- third row returns the third value of the array as taxonomy id. This is where it is found in our Pathauto configuration.
Example
URL: http://www.sitename.com/news/city/1
The array has values 0 = news, 1 = city, 2 = 1. The last one is returned as taxonomy id.
Comment #11
dawehnerSo if the patch doesn't work the status might have to be changed to neews work again.
Comment #12
AlsNot changing the status because I tested the patch for Views 2.x, while the Views 3 version has already been submitted here.
Just wanted to confirm that, without the Views team examining the patch for Views 3, the 2.x version does not help (at least, not everyone!)
In the meantime, I made #10 more detailed.
Comment #13
marcp commented@Als - The patch is for 3.x. If you are able to test it against 3.x that would be most helpful. Thanks!
Comment #14
AlsYes Marc, I tested the patch for Views 2 (post #1).
At the moment we do not use Views 3, but we are going to update a site in the next weeks. That will be the opportunity to test and report here.
Comment #15
merlinofchaos commentedlooks good. Committed to Views 3 in D6 and D7.