The best editor, vi, is pronounced "SIX" :wq
views
Modify Views SQL Query in Drupal, Restrict View to Search Term
So I wanted to be able to pass a default value to the the Views search filter, to filter by a view by a search term, to display that view in a block.
EDIT: There is an easier way to do this, which renders this whole tutorial useful only for other SQL hijacking. Under Filter, select Node: Body. See screenshot.
I had two options, create a view, create an RSS feed, run it through Yahoo Pipes, and cycle it back through, or modify the views query.
Tutorial: How to Group Fields in Views With a Div or Span Tag
This is a howto for wrapping a div around a few of your view fields (and not others). This is useful, for instance, for being able to group all one's content so that it floats left but does not float around an image.
EDIT: This technique is a good intro to views templates, however, an easier way exists which seems a little hackish, but would work for many use cases. Thanks to Sr. or Sra. Anonymous.
Group By in Views
Ok, So basically I had a listing of books set as a view. Some books were available in Hardcover, Paperback, and Digital. Unfortunately, the client wanted these books to have completely different information, except description, title, and image. In order to have that, we needed to create separate nodes for each version. This caused another problem.
Now in my listing, there were three nodes back to back with the same title, image and description. The client wanted these nodes to show as a single row in the view. I thought, easy enough, I will just add a group by statement. I know you are going to tell me I could have edited the query object, and I tried that... but apparently views disabled support for that. My solution, hijack the actual MySQL statement before it runs, and edit it.
Here is the snippet:
<?php
function publications_views_pre_execute(&$view){
if ($view->name == 'publications_category')
{
$search = array('ORDER BY');
$replace = array('GROUP BY node_title ORDER BY');
$view->build_info['query'] = str_replace($search,
$replace,
$view->build_info['query']);
$view->build_info['count_query'] = str_replace($search,
$replace,
$view->build_info['count_query']);
}
}
?>
function publications_views_pre_execute(&$view){
if ($view->name == 'publications_category')
{
$search = array('ORDER BY');
$replace = array('GROUP BY node_title ORDER BY');
$view->build_info['query'] = str_replace($search,
$replace,
$view->build_info['query']);
$view->build_info['count_query'] = str_replace($search,
$replace,
$view->build_info['count_query']);
}
}
?>
Lullabot On Improving Drupal
Any interested Drupalologist would do well to go read Jeff Robbins' take on how to improve Drupal. Okay, so it's a bit utopian — I think he's only half-kidding when he talks about Drupal "saving the world." But the guys at Lullabot know Drupal's strengths and weaknesses as well or better than anyone else.
I was particularly interested by the "What If..." section of the post. He phrases it a bit more politely, but Jeff's right: drupal.org and api.drupal.org are downright embarrassing when compared to other CMSes' sites. Providing the the code that comprises a function is not the same thing as documenting that function. And providing a boring, poorly-organized product site is no way to win converts.
For my own, selfish part, I'd just like to see some stability in the APIs. 4.7's Forms API changed everything; 5 changed much of it again. I've become a grudging convert to using CCK and Views for nearly everything — there are very good reasons for that design decision, made by developers smarter than I — but there's no question in my mind that it's made development slower. I'd like to see these projects remain in a stable place for a while, and try to consolidate rather than continuing to reinvent the wheel — the fact that CCK has its own pidgin DDL is something no one should be happy about.
