I have built a module that modifies a view and adds either a filter and argument. To do so, it uses the pre_query hook, calls views_view_add_filter and views_view_add_argument respectively, it then nulls the query and countquery variables of the view object to force Views to rebuild the query.
This works flawlessly with all views save those that use the Node Updated Time filter. It would seem that Views fails to rebuild the query using the parameters from the Node Updated Filter, and that some substitution fails, instead of UNIX timestamps, the query contains "value", like seen here, a print_r of $info:
<?php
Array
(
[query] => SELECT DISTINCT(node.nid), value FROM {node} node LEFT JOIN {term_node} term_node ON node.nid = term_node.nid WHERE (%s.%s IN ('%s')) AND (%s.%s %s '%s') AND (%s.%s %s '%s') AND (%s %s %s + %d) AND (term_node.tid IN ('76','81')) GROUP BY node.nid ORDER BY DESC
[countquery] => SELECT count(DISTINCT(node.nid)) FROM {node} node LEFT JOIN {term_node} term_node ON node.nid = term_node.nid WHERE (%s.%s IN ('%s')) AND (%s.%s %s '%s') AND (%s.%s %s '%s') AND (%s %s %s + %d) AND (term_node.tid IN ('76','81'))
[summary] =>
[level] =>
[args] => Array
(
[0] => node
[1] => type
[2] => content_wordsy_story
[3] => node
[4] => promote
[5] => =
[6] => 1
[7] => node
[8] => status
[9] => =
[10] => 1
[11] => node.changed
[12] => >
[13] => 1178097183
[14] => -31536000
)
)
?>
I haven't done any deeper debugging but it would appear that the query builder will not rebuild the queries properly, for the Node Update Time filter to work, the query cannot be modified or nulled at post_query or the necessary substitutions will not take place.
I'm going to do further debugging and see if I can come up with a patch. However first I'd like to have this confirmed as a bug in Views and not something else.
Comments
Comment #1
merlinofchaos commentedI'm having trouble following what's actually wrong here. It'd help if you gave me a piece of code that can duplicate what you're getting and/or show me exactly what you're expecting to be getting. My first thought was that you were having issues with query substitutions, but I don't think that's the case here. Reducing this to an easy-to-use test that'll duplicate the problem for me will make it a lot easier for me to solve it.
Comment #2
solipsist commentedOkay, I'll try to explain it a little better then.
The module I've written (and which I plan to make public once it works as intended) allows filtering any view (the admin decides which views it apples to) using terms (from a vocab selected by the admin) which can be specified by the user in his/her profile. In order to do this, the module loads the user's preferences and adds a filter with the terms selected by the user. There is also a block allowing the user to override any preferences and filter by one of the terms listed here. The block is available to all users, anonymous or authenticared. The module is used for a digg-like site where members need to be able to filter stories as they like.
I am using the following code to modify a view (I've omitted some unrelated code for clarity):
If everything goes well, this is the query (a print_r'd copy of $info) and the view object we end up with (the filter with array index 4 is the one the module added) which produces a set of rows allowing us to list the nodes that fit the user's preferences:
Unfortunately, this does not seem to work with views that use the Node Updated Time filter. Now I am beginning to wonder whether this is entirely related to my module as it seems to happen even without it. MySQL is throwing errors like the one below on localhost even when the view is not being modified while on the testing server it seems to happen only when the pre_query hook is being used to modify the view object. An unmodified view:
This is a similar error produced by a view that is modified:
Both queries look perfectly OK to me so I am clearly missing something here. What is confusing me further is that some views that use the Node Updated Time filter (node.changed > now + -x) and are modified by my module return rows as they should without producing any errors whatsoever. That could mean that this error could be entirely unrelated to Views and not the result of a bug at all. What do you think?
Comment #3
solipsist commentedSome additional information I forgot to include:
- When clicking a term in the block, an argument is added to the view taking the name of the term, like: sitename.com/movies to only show stories about movies (tagged with the term 'movies').
- The print_r'd output above is produced like this (I've modified Views to pass some extra variables through this hook, such as $info, for debugging purposes):
Comment #4
merlinofchaos commentedIn both queries, "ORDER BY DESC" is incorrect; it's somehow missing the field you are sorting on. What items do you have in the query that could be adding the sort? (Sorts can be created by lots of things, mostly arguments, sort criteria and fields when using tablesorting).
Comment #5
solipsist commentedDoh! I totally missed that! Thanks :)
Here are two views that generate errors. The first one generates the error it regardless of whether my module is enabled or not, the second one only does it when the module is enabled:
Comment #6
solipsist commentedLooking at the above, the issue seems related to the Voting API cache table - which in itself is interesting because I haven't made any modifications to that module.
Comment #7
solipsist commentedSo, what do you think? Is this a Views bug or is it related to something else?
Comment #8
solipsist commentedWe will pay for effective and prompt assistance with resolving this problem.
Comment #9
eaton commentedI'm not sure how this issue relates to VotingAPI at all; it does expose a filter that uses views_handler_filter_timestamp in the same way that the Node Updated field does.
Comment #10
solipsist commentedApparently the issue is not with Node Update Field filter, I was wrong and misunderstood how it all worked. Sorry about the confusion.
Point is, I can replicate this exact issue with a view that lists nodes using the votingapi_cache table as a field (without the additional factor of the module I have made). The faulty sorting happens only on those views, which has led me to suspect that there's a bug in votingapi_views.inc.
The faulty ORDER BY query (where the field is omitted) only happens when a votingapi_cache table field is used as field in the query, ie; ORDER BY votingapi_fieldname. It tends to happen under certain conditions and I have yet to determine exactly what those conditions are, however it seems to be pointing at votingapi_cache.
Comment #11
sunDo you still experience this issue?
Comment #12
solipsist commentedI implemented some form of workaround for the client (was over a year ago now). The issue can be closed.