View arguments are ignored

There is code to do this. What version of views are you using? Views 1.6 beta has made some changes that affected other modules, and it's possible that it has also affected this one.

Hi Doug!

I used a development snapshot 5.x-dev (> 5.x-beta3) and just upgraded to the latest version of Views (5.x-1.6-beta5). Unfortunately the error is still there.

I am using the latest tagadelic (v 1.36.2.3 2007/03/13 09:58:31) and the latest tagadelic_views-5.x-1.x-dev (v 1.1 2007/03/12 14:53:49).

Can I give you any other info? A simple experiment is to create a username argument in the view to show only data for the user given in the argument (mydrupal.org/myview/username). If I choose Tagadelic as the view type, the argument is ignored and all nodes are shown. Any other type, e.g. list type, works as expected and filters the given user's nodes correctly.

true, I seem to experience the same behaviour - trying to use an argument to display tags for nodes that are inside a given taxonomy term.
The View argument is discarded

I believe I'm experiencing a similar problem when determining the sort order. I have a tagadelic view that displays 25 nodes sorted randomly. I also have tagadelic set to random. The order of the tags in the block are randomly arranged every time I refresh, because of the tagadelic setting, but the actual tags that appear are always the same 25. So it's as if the view is outputting the same nodes over and over again, ignoring the sort configuration.

I am using the latest version of views, tagadelic, and tagadelic views.

Me too. No views arguments are being taken into account using Views 1.6 and the DRUPAL-5 tag of tagadelic_views.

If you add
$args = $view->args;
on line 63 underneath
if ($view->view_args_php) {
then arguments work fine.

I added hickory's suggestion to the 5.x-1.x-dev branch. Does this solve the problem?

It doesn't fix the problem of the sort order being completely ignored. I can spin that out in a different thread if you think that's appropriate.

Hi there!

I just checked hickory's solution for myself, and that should do the trick most of the time. Most of the time? Yeah, you will guess it... Another related error has appeared: Use of an database prefix will result in false SQL.

I'll stick with my example of the user name argument (mydrupal.org/myview/username). The generated where clause looks like

a) ... AND (node.type IN ('aContentType')) AND (users.name = 'aUserName') ... instead of the expected

b) ... AND (PREFIXnode.type IN ('aContentType')) AND (PREFIXusers.name = 'aUserName') ....

But both, a and b are defect, because the views module declares 'PREFIXnode node' in the JOIN part. A working where clause would thus either declare PREFIXusers users or generate PREFIXusers.name = 'aUserName'.

I tried to set the prefix with $view->use_alias_prefix = 'PREFIX'; just before _views_build_query(...), but that collided with other parts of the query generated by the views module.

Here is the whole generated SQL sequence for reference:

hickory's suggestion solves the problem for me. So far, i've found no further errors.