Right now it's very difficult to create any sort of hierarchical view, meaning galleries, forums, etc

We can allready group by one field but we should be able to group by multiple field.

eg.
Monday
-Morning Session (9-noon)
--Event, room
--Event, room
--Event, room
-Afternoon Session (1-4)
--Event, room
--Event, room
--Event, room

would be:
Group by Day
Group by Session
Sort by Day, Session, Event

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

dawehner’s picture

I'm wondering whether http://drupal.org/project/views_tree would be enough?

Could you try out this module?

YK85’s picture

subscribing

MBroberg’s picture

I have been looking at Views Tree but cannot get it working.
It seems like you have to have a pointer to some sort of parent field.

What I want is to be able to select a bunch of fields for display, then group them in any fashion that makes sens to me at the time.
For example in one view I might have:

Monday
-Room 1
--Event, time
--Event, time
-Room 2
--Event, time
--Event, time
Tuesday...

while in another display I might want:
Monday
-Morning Session (9-noon)
--Event, room
--Event, room
--Event, room
-Afternoon Session (1-4)
--Event, room
--Event, room
--Event, room

and in another view I might want:
Instructor 1
-Monday
--Event, location, time, room
--Event, location, time, room
--Event, location, time, room
Tuesday
--Event, location, time, room
--Event, location, time, room

So I need unlimited nesting levels with the ability to choose a "group by" for each level from any field that is currently in the field list.
It should ideally be very similar to the current "Group By" function, only allowing more grouping levels. Perhaps the "group by this field" should be a setting for the field, or put grouping in an area similar to "Sort Criteria" so that you could drag and drop the grouping levels in a similar manner to sorting levels.

sime’s picture

I would do this by ordering nodes by event date and adding grouping for some of the fields:

eg.
Monday
-Morning Session (9-noon)
--Event, room
--Event, room
--Event, room
-Afternoon Session (1-4)
--Event, room
--Event, room
--Event, room

would be:

Group by Day
Group by Session
Sort by Day, Session, Event

MBroberg’s picture

Yes that is what I want too but how do you do "group by" field 1 and then "group by" field 2?
There is only one "group by" in the display settings.

sime’s picture

It's not simple to have two grouping fields (as far as I know). The best way I can recommend is:

1. The first two Fields are your grouping fields. But remove their labels and set them to "Exclude from display"
2. Your third Field choose the group "Global" and add "Global: custom text". With this field you set the Text to the combined output of the first to Fields.:

[replacement-token-field1] [replacement-token-field2]

3. Go into your display settings and select this third field as the group-by field.
4. Add whatever other fields there are.

Another approach is to have a view as the display for each major node type. So on full/teaser view of the "Instructor" node type, you display a view that shows day/event information. Obviously creating the views is pretty easy and you'd have to work out the best way to add these to the node view (which is outside the scope of the views issue queue).

MBroberg’s picture

Thank you, I have been using both suggestions as a work-around but neither gives me true nested grouping, so it is still a "feature request" if it ever becomes possible.

Method # 1 gives me a single "group by" field with multiple fields in it, which is OK as a temporary solution but still repeats data in each header and does not allow indenting.

So I get:
Monday Morning
-event
-event
-event
Monday Afternoon
-event
-event
-event

and what I really want is
Monday
-Morning
--event
--event
--event
-Afternoon
--event
--event
--event

Thanks anyway for your suggestions.

dawehner’s picture

I wrote a basic patch which allows to group by more then one field, but it's not ready yet

dawehner’s picture

Status: Active » Needs review
FileSize
6.89 KB

So here is a initial not full working version

twistedindustries’s picture

Doesn't work for me, or at least not the way I had expected. When I apply two grouping fields it always ignores one. I am trying to accomplish this with two date fields.

tomdisher’s picture

Subscribing.

alex.skrypnyk’s picture

Subscribing

anivad’s picture

+1 subscribe

merlinofchaos’s picture

Status: Needs review » Needs work

The approach seems okay. In an ideal UI, maybe what we would have is where the user enters a number and clicks update and then it comes back with the right number of fieldsets.

The @todo definitely needs to be completed for that to work, since that means an arbitrary number of recursions in order to group properly.

Fannon’s picture

+1

Would love to see this in Views!

zeezhao’s picture

+1

topmet’s picture

+1

Shadlington’s picture

Subbing

arx-e’s picture

Subscribing

dawehner’s picture

Here a question from mail, because the user didn't posted in the issue queue but i think that's interesting for everyone.


I came across your patch for grouping by multiple fields in views at
http://drupal.org/node/477338 and have tried applying it to a dev build of
views 3. I notice that you mention it's not a fully working patch and I am
experiencing the same results as one of the posters on the thread, that it
seems to still just group by one of the selected fields.

I was wondering whether you could help at all. What features of the patch are
supposed to work and which are unfinished? Have you done any more recent work
on this? It seems to be frequently requested and I think there are a lot of
people who would be incredibly grateful for this feature. I can't really
offer to help complete it myself as I'm more of a drupal user than a
developer, but I would really appreciate your input on this.

I don't know anymore what worked on the patch, but i guess it's more
an api level change at the moment. From reading the patch i would guess the Idea exist, but not sure how far it is.

One part which definitive have to be done is a actualy way to alter the behaviour via a template. There should be template for render multiple views.

If you want to complain about my ignorance, think that this patch is nearly one year old....

If there would be more recent work, i would have posted it here. There are probably some other issues which i worked on in the meantime instead. In general there are always a lot people involved when it comes to views wishes/bugs/features/tasks etc.

gagarine’s picture

- double post -

gagarine’s picture

I adapted the patch to be able to use it in template.php via theme_views_view_list.

/**
* overwrite theme_views_view_list
*
* Group more than one fields in a view
*
*/
function template_views_view_list__VIEWNAME($view, $group, $row) {
  //the field we want to group
  $grouping_fields = array('node_node_data_field_mon_field', 'node_node_data_field_mon_field_2');

  //Arrange in a nice array
  foreach ($view->result as $index => $row) {
    $grouping = array();
    if (isset($view->result[$index]->$grouping_fields[0])) {
      $grouping[0] = $view->result[$index]->$grouping_fields[0];
    }
    if (isset($view->result[$index]->$grouping_fields[1])) {
      $grouping[1] = $view->result[$index]->$grouping_fields[1];
    }
    $sets[$grouping[0]][$grouping[1]][$index] = $grouping[1];
  }

  $sets_sets_sets = $sets;
  $list = array();

  //Go down the array and prepare a list
  foreach ($sets_sets_sets as $main_group => $sets_sets) {
    $group = array();
    foreach ($sets_sets as $sets) {
      $subgroup = array();
      foreach ($sets as $sub_group => $title) {
        //create a row
        $row = '';
        foreach ($view->field as $id => $handler) {
          $row .= '<div>' . $view->style_plugin->rendered_fields[$sub_group][$id] . '</div>';
        }
        //add the row in the group
        $subgroup[] = array('data' => $row);
      }
      $group[] = array($title, 'children' => $subgroup);
    }
    $list[] = array($main_group, 'children' => $group);
  }

  return theme('item_list', $list);
}

also on https://gist.github.com/1172621

#673982: Group by several fields at the same time was closed as a duplicate.

jdufaur’s picture

Title: Hierarchical views » Multiple group: group by more than one field
Version: 6.x-3.x-dev » 7.x-3.x-dev

Subscribing

AlternateRoute’s picture

Subscribing

FreeFox’s picture

Hi all,

I hope this is the right issue to add this because there are about a dozen of issues about "GROUP BY".

After reading all the issues and other posts about "GROUP BY", including about 8 hours of testing the "Use Aggregation" I want to propose my idea of adding 1 option to the "Sort criteria" dialog. Now you have "O Sort asc" and "O Sort desc" ... What about a 3rd option => "O Group by". (see a visualization in attached image).

This would make grouping by 1 field very easy and I guess it would help many users.

Hope this gets a chance ^^
Thanks in advance
Freefox

gagarine’s picture

@Freefox group by on one field is not a problem and is an existing feature, this issue is about grouping by more than one field...

FreeFox’s picture

@gagarine: if you put multiple field in the sort criteria you could group by multiple fields

Except for the table view where you can group, how can I group by 1 field? More in detail, I need it in the JSON export format.

gagarine’s picture

@FreeFox

if you put multiple field in the sort criteria you could group by multiple fields

Nop you can't group (like in a list). I updated the issue description to make it clearer.

Except for the table view where you can group, how can I group by 1 field?

please google it or open a new issue.

patoshi’s picture

i'm also running into this same issue. From my research so far, it seems the only to do this effectively is to create nested views by using this module: http://drupal.org/project/views_field_view

In effect you would get an output like this: http://prntscr.com/4fvu2

This seems a bit cumbersome if you nest 3+ views together. How can this be resolved with a single view?

Also another problem I noticed with the default group by settings in views 3.x is that the "group by" field is repeated on every result and I dont see any way of disabling it besides creating a tpl or hide it with css.

gagarine’s picture

@duckx what about the "solution" I explain in #22?

casey’s picture

Status: Needs work » Needs review
FileSize
12.92 KB

Used patch of dereine in #9 as a base.

I think it is fully backward compatible. This patch allows you to use a unlimited number of groupings.

Configuration form could use some ajax (now you need to save and reopen the style options form for an extra grouping field).

casey’s picture

FileSize
13.01 KB

Minor improvement

dawehner’s picture

Status: Needs review » Needs work

Nice! Thanks for working on this feature, really like it already sadly there are some parts.

Did you runned the simpletest for the groupby?

+++ b/plugins/views_plugin_style.incundefined
@@ -173,19 +171,34 @@ class views_plugin_style extends views_plugin {
+        unset($form['group_rendered']);

Why does the $form have to be unset here? Isn't the form not rendered yet?

+++ b/plugins/views_plugin_style.incundefined
@@ -173,19 +171,34 @@ class views_plugin_style extends views_plugin {
+          $this->options['grouping'] = array(array('field' => $this->options['grouping']));
...
+          $this->options['grouping'][0]['rendered'] = $this->options['group_rendered'];

Could both parts use the [0]['field'] syntax? This shows a bit better what's done here.

+++ b/plugins/views_plugin_style.incundefined
@@ -173,19 +171,34 @@ class views_plugin_style extends views_plugin {
+        for ($i = 0, $c = count($this->options['grouping']); $i <= $c; $i++) {

What's the reason to add $c = ... if $c is not used somewhere else? This syntax might be known by less developers. If the $c is needed move it one row up ...

+++ b/plugins/views_plugin_style.incundefined
@@ -237,36 +259,63 @@ class views_plugin_style extends views_plugin {
+  function render_grouping_sets($sets, $level = 0) {

I like it that the parts are seperated better then before

+++ b/plugins/views_plugin_style.incundefined
@@ -237,36 +259,63 @@ class views_plugin_style extends views_plugin {
+        $output .= theme(views_theme_functions('views_view_grouping', $this->view, $this->display),
+            array(
+                'view' => $this->view,
+                'grouping' => $this->options['grouping'][$level],
+                'grouping_level' => $level,
+                'rows' => $set['rows'],
+                'title' => $set['group'])

The indentation looks a bit odd here.

+++ b/plugins/views_plugin_style.incundefined
@@ -237,36 +259,63 @@ class views_plugin_style extends views_plugin {
+            array(
+                'view' => $this->view,
+                'options' => $this->options,
+                'grouping_level' => $level,
+                'rows' => $set['rows'],
+                'title' => $set['group'])

here as well

+++ b/plugins/views_plugin_style.incundefined
@@ -277,42 +326,93 @@ class views_plugin_style extends views_plugin {
+  function render_grouping($records, $groupings = array(), $group_rendered = NULL) {

I'm not really sure whether we should change the arguments of this function at that point ... You know people might rely on that in their style plugins. Let's discuss about that as every change creates a shitstorm

+++ b/plugins/views_plugin_style.incundefined
@@ -277,42 +326,93 @@ class views_plugin_style extends views_plugin {
+    // This is for backward compability, when $groupings was a string containing
+    // the ID of a single field.
+    if (is_string($groupings)) {
+      $groupings = array(array('field' => $groupings, 'rendered' => TRUE));

Oh i didn't saw that, this looks fine! Forgot my last comment :)

+++ b/theme/theme.incundefined
@@ -307,6 +307,29 @@ function template_preprocess_views_view_fields(&$vars) {
+function theme_views_view_grouping($vars) {
+  $view = $vars['view'];
+  $title = $vars['title'];
+  $content = $vars['content'];
+
+  $output = '<div class="view-grouping">';
+  $output .= '<div class="view-grouping-header">' . $title . '</div>';
+  $output .= '<div class="view-grouping-content">' . $content . '</div>' ;
+  $output .= '</div>';
+
+  return $output;

I'm wondering whether it would make sense to add another template here as views theming is done nearly all the times with templates.

Btw. why is $view needed here?

dawehner’s picture

The test is "Views plugins -> Styles"

casey’s picture

Status: Needs work » Needs review
FileSize
20.11 KB

- Altered code according your comments.
- Fixed styles test.
- Renamed ViewsPluginStyleTestCase::testGroupBy to ViewsPluginStyleTestCase::testGroupingLegacy
- Added a new test ViewsPluginStyleTestCase::testGrouping testing multiple groupings.

Reg’s picture

I just came across a simpler form of the same problem and was referred here. I came up with a possible solution and thought I would link over to it just in case someone else can benefit from it (not sure if it will be a good solution yet but but it might help someone). Here's the issue: http://drupal.org/node/1383696#comment-5400920 .

Reg’s picture

FYI: I tried this workaround and it worked well for me: http://drupal.org/node/1383696#comment-5401116 . You could theoretically have as many subgroups as desired (only needed one) and you can theme it properly because there is now HTML distinction between the levels.

casey’s picture

@Reg, sure that's another solution, but way more inefficient.

Reg’s picture

@casey Agreed it is probably less efficient, how much so I have not tested but it certainly creates more HTML (there are modules to cut down the HTML views creates) than I would like and probably more queries. On the other hand how much are your displaying? If you are pulling up 3 records from the outer group it's probably insignificant in extra overhead.

However, it does allow you to solve a problem without a patch and right now there is no in-built working methodology so having alternatives to choose from is certainly a good thing.

casey’s picture

FileSize
20.58 KB

Changed test to use two different fields for grouping

dawehner’s picture

Version: 7.x-3.x-dev » 6.x-3.x-dev
Status: Needs review » Patch (to be ported)

Thanks!

Made another final review and decided to commit it, maybe it's worth to backport it.
For follow ups please open new issues.

casey’s picture

Version: 6.x-3.x-dev » 7.x-3.x-dev
Status: Patch (to be ported) » Reviewed & tested by the community

Looks like you forgot the new views-view-grouping.tpl.php

dawehner’s picture

Version: 7.x-3.x-dev » 6.x-3.x-dev
Status: Reviewed & tested by the community » Patch (to be ported)

OH yes, thanks!

philsward’s picture

While I haven't tried out the patches, this appears to be along the lines of some issues I ran into and started thinking "Fields should be organized by groups". Thinking about it and doing some research in the issue queue, I've realized that "Groups" is a term that is overused with Views and should be left to the existing uses. I think a better term would be "Clusters".

What I imagine, is by default, there is one cluster of fields (which is how views works now) but you could add in a second cluster with specific fields and maybe even a third cluster. Each cluster would be independent of each other but the output would all be on the same page.

Example:
Field Cluster 1
- Node: Title
- Node: Teaser
Field Cluster 2
- Node: Title
- Node: User

Now, what I also envision, is that these clusters, being independent of each other, could be stylized independently of each other. For example Cluster 1 could be displayed as a table and Cluster 2 could be a grid. Also, these clusters could be included into the arguments so that if cluster 1 doesn't validate, then show cluster 2 instead. Each cluster should also be allowed to be filtered and sorted independent of each other.

This type of setup would allow for much greater display of data within a page. Especially when utilizing arguments. As it is, if an argument doesn't validate, the current options are very limited on how to display the data.

---
The only other way I can think of to accomplish this type of setup, would be to join two view displays together, something I don't think is possible right now but I also personally think this would create more overhead on the view. I've thought something like this could be accomplished also by using panels, but that also seems like a lot more work and system overhead than really necessary.

---

Another use case scenario that got me thinking about the need for this, was trying to use "Views Slideshow" to accomplish a "tabbed ajax display". In my dealings, I realized that this isn't possible because there was no way to separate the fields for views slideshow to independently scroll through three different cck fields on the same node. (Each field is a text field with unlimited addons) I basically have "Specifications, Features & Options" cck fields and I wanted to use the views slideshow pager to scroll through each field for that node. It's easy with arguments to only show the fields for the respective node, but the way views is designed now, it's either all of the fields show up or nothing. The existing format lumps all of the fields into one single cluster.

---

I'm sharing my thoughts in hopes that it will help open the doors to some of the possibilities of what I believe this issue is modestly trying to accomplish. Some might say "just throw some PHP code at it to get it to do what you want". I am speaking for the group of people who can't code. The one's who use Drupal out of the box and if it doesn't do it out of the box, we find another way of doing it or don't mess with it at all.

Thoughts?

trofimchouk’s picture

Hello! Is there any patch for 6.x-3.x version?

patoshi’s picture

so i came up with something else using the global php field. please let me know if this way is inefficient or not compared to the patch you guys have:

i tried other methods but this seems to be the best method as it seems. the problem from wat i remember was that you had to keep track of the previous views-row data to see if it matches the current month/day its processing.

i got it working like this:

http://prntscr.com/5qexn

views page: http://prntscr.com/5qeyj

my global PHP field: http://prntscr.com/5qf0a (you will need to re-purpose this for your own use.)

page styles settings: http://prntscr.com/5qf34

please do tell, if you find a better solution without the custom php.

As requested by lancelot:

<?php 
global $prev_month;
global $prev_days;
if(!is_array($prev_month)) { $prev_month = array(); }
if(!is_array($prev_days)) { $prev_days = array(); }
global $month;

$var = $data->field_field_date_2[0]['raw']['value'];
$var_date = date('F Y', strtotime($var));
$var_day = date('l, F jS', strtotime($var));

if(!in_array($var_date, $prev_month))
{ 
//open h3 tags are to cancel out the h3's that get wrapped. with this.
  $month = '</h3><h4>'. $var_date .'</h4><h3>'; 
  $prev_month[] = $var_date;
} 
else 
{ $month = ''; }

if(!in_array($var_day, $prev_days))
{ 
  $days = '</h3><h5>'. $var_day .'</h5><h3>';
  $prev_days[] = $var_day;
} 
else 
{ $days = ''; }

print($month . $days);
?>
fabsor’s picture

Status: Patch (to be ported) » Needs review
FileSize
12.44 KB

Here is a first try at getting this to work in Drupal 6. A few notes:

* There were no tests for styles at all in 6.x so I skipped this in this version.
* I do a render in the theme function, since the preprocess is not called. We might want to do that in some other way.

fabsor’s picture

Oops, that patch failed on everything but grouped views. Here is a better one =)

mikolaskova’s picture

Hi fabsor,

I installed the dev-Version for applying your patch, but now I don't see how to make use of it.

Grouping is activated, the fields are set to "group results together" but nothing happens.

I found the grouping settings in the table-settings (which I used before), with your patch there are more options now, but when I use two grouping options, everything disapears.

(Its a view about school events, I want to group them by month and day, so that all events on the same date are grouped by this date, all events of the same month are grouped together)

Thank you

regards

Adriana

giorgio79’s picture

#41 I don't see any commits for this issue for 7x at http://drupal.org/node/38878/commits?

dawehner’s picture

#50

This is a really old commit: aa67578160d87ae994748abcd52a5035dcc57ccb

giorgio79’s picture

Thanks, much appreciated.

dawehner’s picture

To be honest I don't think that now nearly one year later someone cares that much about Drupal 6 that it's worth to add the feature in there. It would require additional testing etc. so it seems to be better a won't fix for 6.x-3.x.

philsward’s picture

@dawehner I guessing because of views attachments and the use of other workarounds like panels kind of makes this issue somewhat obsolete...? Just my guess...

dawehner’s picture

I'm not sure how to use panels/views attachments to achieve this behavior, well maybe it's possible with views_field_view :)

alexh58’s picture

Just an FYI to anyone who chooses to use the patch in #48:

It breaks CCK 2.9 nodereference select fields (that use the views module, as the selector).

I believe this is because of how the results variable is setup and that it gets split into groupings and rows. Anywho—for those who are using this wonder grouping patch and want their nodereference select fields to remain working, I'm attaching a patch that just changes a one line in the nodereference module and that respects this new format.

alexh58’s picture

Issue summary: View changes

Updated issue summary.

MustangGB’s picture

Issue summary: View changes
Status: Needs review » Closed (won't fix)