views argument from the url
Pasqualle - January 13, 2009 - 12:40
| Project: | Quick Tabs |
| Version: | 6.x-2.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
Description
QT should support the %N format as the view argument grabbed from the url.
quote from the panels module:
Additional arguments to send to the view as if they were part of the URL in the form of arg1/arg2/arg3. You may use %0, %1, ..., %N to grab arguments from the URL.
#1
Oh subscribe. Probably the most important thing for me right now.
I anticipate this hugely.
#2
little guide toward the solution, extracted from the panels_views_all_views_render() (panels_views.module)
$arguments = explode('/', $_GET['q']);
$args = $conf['args'];
foreach ($arguments as $id => $arg) {
$args = str_replace("%$id", $arg, $args);
}
...
$args = preg_replace(',/?(%\d|@\d),', '', $args);
$args = $args ? explode('/', $args) : array();
...
$view->set_arguments($args);
#3
Hopefully I did this right...
This small patch should add this much needed and easy to implement feature :)
Please try it. (See http://drupal.org/patch if you need to learn how to apply it)
Thanks
#4
Subscribing, greetings, Martijn
#5
It works but
1. using '%' sign in the view argument makes invalid HTML for the quicktab as it is used for the link id (to load ajax content)
<a id="view--2--0--cars--block_1--%1"
Warning: <a> attribute "id" has invalid value "view--2--0--cars--block_1--%1"
I don't have a good solution for this. Maybe we can use Drupal.settings.quicktabs to pass settings to quicktabs.js (instead of adding it to the link) but it requires a quite large rewrite of the source code.
2. I think the input should be sanitized. check_plain() on arg() or something.. But I am not sure about this.
I would prefer to have the same code as Panels have for displaying the view, and a confirmation that the arg handling is safe (as I do not see where it is sanitized in Panels)
#6
Doh... that's not good.
Here's an update.
#7
I think with the new patch views inside ajax quicktabs does not handle args from url
but you are getting close to the solution :)
#8
Nothing changed in the argument handling code part - only the addition of str_replace for '%' with 'arg'.
Maybe try downloading the module fresh and applying the patch again.
I can confirm argument handling is still working for me.
#9
ok, I tested it now. I can tell it does not even worked with the previous patch.
the problem is that the quicktabs.js needs that value what you have changed in the last patch. There must be the exact argument value for that view, otherwise it can't work with an ajax quicktab..
if you put the view on the first tabpage than it will work, as the first tabpage in not an ajax tabpage, it is loaded at page load. Try to move the view to the second tabpage and you will notice that the view does not receive the arg from url..
#10
Ah, I wasn't using ajax.
Ok, the solution would be to set a js variable - rather than hacking it out of a css id.
No mucking about that way - I'll fix this when I get a chance.
Cheers!
#11
Well, turns out the js variable was already being set, so I don't know why it wasn't being used over hacking it out of a css id. Eeeek.
Anyway... please try it out.
PS. There was another bug where extra slashes were getting added to the view variable (due to not being emptied for each tab).
Cheers
#12
the last patch is strikingly interesting...
I have some questions, as I see you must be quite familiar with Drupal ajax handling:
1. why tab.qtid?
var args = Drupal.settings.views.ajaxViews[tab.qtid].view_args;
I tried to find where is it set in the module, but I can't find a connection. In the _quicktabs_prepare_views() function the qtid is not used.
2. How do you check the values in Drupal.settings? Is it possible with firebug?
#13
1. I figured the tab.qtid was the id of the quicktab. (The order in which they appear). If this is incorrect, my apologies.
I'll have to setup a few more tab pages and test more thoroughly... to ensure this is the right variable.
2. Firebug :) Unfortunately you can't see the globals unless you reference them. (not a problem in this case)
How did it work for you?
#14
seems to be working fine here. thank you thank you and thank you.
#15
I just tested this on a tracker view as a second tab. It picks up the argument correctly and displays tracker for the proper user as tracker/uid would.
Great work!
Best,
Andrey.
#16
Hmm, the method for getting the correct view args from Drupal.settings was not reliable. I have reworked the patch to add the evaluated url args onto the id string of the tab element. It's working for me but I'm aware that different people have different use cases so wanted to throw this up and see if it works for everyone else before committing.
#17
I am not sure, but the last patch seems like a possible security hole, as it puts a parameter from url directly into the HTML output within the _quicktabs_construct_tab_attributes() function..
#18
Ah, never thought of that - good catch. Then I guess we're stuck with passing it through Drupal.settings but it may need to just go in Drupal.settings.quicktabs seeing as there's no reliable way to access the correct ajaxView object from Drupal.settings.views.ajaxViews - even checking against the view name and display id isn't reliable because you could have two instances of that exact same view/display with different arguments.
#19
Changing the status...
#20
I would like to see this feature solved in 2.x version, but I am not sure how big the Drupal.settings.quicktabs change would be..
#21
subscribing
#22
OK, since getting tab details into Drupal.settings.quicktabs (per #394400: Use Drupal.settings.quicktabs) we now have a reliable way of getting the correct view arguments. The fix committed in http://drupal.org/cvs?commit=184224 is a reworking of pingers' approach using this more reliable method for the ajax views. Please try out the next dev release (should be created a few hours from now) and let me know if there are any issues with this.
#23
small html problem
Warning: <a> attribute "id" has invalid value "1-0"ID must begin with a letter ([A-Za-z]) and may be followed by any number of letters, digits ([0-9]), hyphens ("-"), underscores ("_"), colons (":"), and periods (".").
the problematic code inside _quicktabs_construct_link_options() function:
quicktabs.module line 316
$id = implode('-', array($qtid, $tabkey));I guess the tab link id is not used any more so this code can be removed.
#24
Ah yes, I had got rid of all the other info we'd been putting in there and thought I'd better leave something as I think the element's id is used in the progress-loading js, but forgot there would only be numbers left ;-) I'll add quicktabs-tab- or something to the start of it
#25
there is something wrong with view argument handling in ajax loaded tabpages.
the view argument setting is: If the argument is not present then display all values. This setting works with non-ajax quicktab, but with ajax quicktab the view is not displayed if the argument is not provided in the url.
Tried with single and multiple arguments also..
#26
Hmm, I'm not sure how to handle this... need to look into it more.
#27
subscribing
#28
OK, I've committed a change which I think eliminates problems with non-present arguments from the url (http://drupal.org/cvs?commit=185662). However, during testing I did notice a strange bug with views arguments, which I haven't found a fix for but it is extremely edge-casey:
If you have a QT block with the same view in two tabs but with different arguments, if the second tab rather than the first is loaded on page load (e.g. by accessing it directly with ?quicktabs_0=1 or whatever appended to the path) and it has pager links (ajax-enabled of course), then the pager links mistakenly call the view with the arguments for first tab. However, this second view works perfectly fine if it is loaded via ajax, as it would be under normal circumstances. It also works fine if the QT block is set to non-ajax mode.
Otherwise, I think the arguments are working properly. Please test.
#29
the current argument handling was not able to process this type of argument:
%1+myterm+%2it could be a valid list of taxonomy term arguments for the view.
So I replaced the argument handling code with the one used in panels 3, and also replaced the ugly view rendering code:
$output = call_user_func_array('views_embed_view', $func_args)http://drupal.org/cvs?commit=186444
this still needs testing..
#30
fixed #24 http://drupal.org/cvs?commit=186452
We should simplify the markup when we move to theme templates..
#31
It seems the only remaining issue here is #25. I need to retest that..
#32
I'm experiencing the same problem as #25 with the latest Dev of 6.12 x 2.x
I have three tabs, all views blocks that depend on the arg(2); of the taxonomy url to populate the blocks.. Only the 1st tab works, I can't ajax load the other tabs, if I ditch the ajax mode all three tabs populate fine. From what I gather none of the above patches would solve this right, it's next on the list?
#33
no there is no patch for #25
#34
subs
slightly similar as #25
but with ajax quicktab the view is not displayed if the argument is not provided in the url.Tried with single and multiple arguments also..
For me only the first tab loads, the rest do not, even if I have the argument in the URL!
This is on plain taxonomy pages, overriden with views. I would show a QT block, but only the first tab loads, even if I pass arg(2) to the block.
#35
@giorgio79: please create a new issue, because the taxonomy argument should would.
#36
Thanks Pasqualle. Meanwhile I solved my issue at #34. For the second tab I had to pass an argument, but only %2 worked for a taxonomy term ajax quicktab, arg2 or arg1 did not. Thought I post it here now that I solved it instead of a new one.