coltrane’s picture

Status: Active » Needs work
1.67 KB

The attached module implements a Views filter for all CCK fields. It needs a lot of work.

Requirements and steps to use this filter:

1) CCK 2.x-dev
2) Multigroup and related patches. See for Markus' latest multigroup work (multigroup has its own requirements you must follow)
3) Views 2
4) Download this module and extract into sites/all/module (or where other contrib modules live), change the extension of tar file to ".tar.gz" before extracting.
5) Enable the module normally.

New filters will be available for all CCK fields you have created. These new filters have the suffix "delta".

6) Choose a filter and from the available options mark what other fields you wish to synchronize deltas with.
7) Set the view display row style to Fields and add the CCK fields that you have chosen and associated in step 6.
8) Make sure none of the CCK fields you're display are set to group.

Like I said, this needs a lot of work. In the end this shouldn't be a standalone module but I made it so for easier application till some of the details of multi-value delta association Views integration is worked out. Also, the workflow is odd: all CCK fields have a delta filter, and then you choose what other fields to associate.

The filter options also need to be limited to multi-value fields and those fields attached to the node type or part of a group. However, a point that's up for discussion is whether associating field deltas should be limited to multigroups. Is there value in any field? Probably.

coltrane’s picture

I think I found a bug, need to investigate more, but if a node has only one entry in each of its multi-value fields it is not returned with this View.

jcfiala’s picture

With Ben's request I looked over the code a little and did some tweaking.

One thing that we've run into is the issues of blank values. The patch for deltas #196421: Deleting unwanted multiple values / multiple values delta issues does two things - at comment 198 ( ) missing data is represented with NULL values in a row, where at comment 202 ( ) and on the patches represent blank data by having a missing row but maintaining the deltas. Unfortunately with the way that views puts together the queries, and with the way mysql treats the links in the WHERE clause (as opposed to the links between deltas being in ON clauses), the version at 202 will cause a multigroup with one missing value to entirely disappear from the view's results, where the patch at 198 works fine.

It's possible that more work on this filter could fix this - perhaps by using ensure_tables?

The two main improvements to the module at this point are in naming the multigroup field by the group name, instead of just by 'delta', as well as narrowing down the possible fields that you can link deltas to with the filter to unlimited cck fields in the same multigroup as the base field for the filter. Additional testing was also done, and the entire thing passes a coder review.

To need to use this as part of multigroups, you need to follow the following steps:

  1. Install cck module from head
  2. Install views normally
  3. Patch cck with the '198 patch' for handling missing data:
  4. Patch cck with the latest multigroup update - at the time of this writing I was using

    Note that that's not a classic patch - you basically unpack that file and overwrite the files at cck/modules/content_multigroup with it.

  5. And then install this module in the modules directory that you're using.
  6. Usual installation/configuration steps for cck, views, content_multi_delta. Don't forget to install the content_multigroup module.
  7. To use, just look in the content subsection of filters, and look for the ones that look like 'Content: Blah_field - group_blah' for your group_blah fields
coltrane’s picture

Version: 6.x-2.x-dev » 6.x-3.x-dev

Moving over to the new branch!

coltrane’s picture

Status: Needs work » Needs review

And updating status, I think this is ready for review but should it become a patch?

markus_petrux’s picture

Status: Needs review » Needs work

Yes, please. A patch is much easier to review and test. Thanks!

markus_petrux’s picture

I just marked the following issues as duplicates if this one:

- #495718: Multi display issues when using Views to display a field from a Multigroup
- #451390: groups & views

Since the code base has changed a little, it's hard to extract a patch from the above tars. Any chance to get a patch against a fresh 6.x-3.x checkout?

Edited to fix typo. Oops! (s/change/chance)

mcreature’s picture


coltrane’s picture

@markus_petrux, definitely, just haven't had a good chance to get back to this. I'll make it a patch for adding handlers to multigroup.

markus_petrux’s picture

@coltrane: Do you remember which were the files that you had to change? If you don't have the time, maybe I can take a look, but I think I need your assistance to help me focus on the changes that need to be adapted to the current state of CVS code, so we can test this, and so on... :)

coltrane’s picture

@markus_petrux, IIRC no multigroup files were required to change. The tarball in #3 is a standalone module so a patch just needs to written against CCK's views.

coltrane’s picture

Assigned: Unassigned » coltrane
7.28 KB

#3 now as a patch, still needs work cause there's some bad field references. I'll come back to this after I get some client work done!

markus_petrux’s picture

Wow, thanks!

May we implement this as a patch for content_multigroup module? I was looking at #1 and #3, and it seems to me this feature should be implemented for multigroups only, not for multiple value fields.

coltrane’s picture

Title: Synchronized deltas Views integration: Filter on equal deltas for multiple value fields » Synchronized deltas Views integration: Filter on equal deltas in multigroups

Sure, it currently assumes groups (multigroup I think) but that shouid be more clear, and the filter options should list groups instead of fields in a group.

coltrane’s picture

Alright, here it is against content_multgroup, adds files and Still need to move from listing fields to listing multigroups I think. Probably going to need some smart error checking.

This is reviewable but I'll leave it CNW. It definitely needs more commenting.

coltrane’s picture

Attached patch differs from that in #15 by titles and descriptions only, so just a bit of UI cleanup. I've been attempting to list multigroups instead of fields *in* a multigroup but am having trouble getting Views to list them. And since we don't ever join on the group tables it might not work.

In the two PNGs you can see the interface. I think testing with multiple multigroups on different node types needs to happen.

markus_petrux’s picture

Thank you very much for the job.

This starts to look like it could be committed to the 3.x branch, but I would prefer to wait a little to see if someone else can help testing the patch.

This way we don't generate too much noise for those following module updates from the nightly tarballs, which is the only way to get notifications when this experimental branch gets updates.

As per the project stats page, it looks like more than 1200 sites are using this branch, so let's hope someone else can chime in and provide feedback testing the patch. Thanks in advance for those who try it.

coltrane’s picture

Status: Needs review » Needs work

Ah, found a problem. Trying to add a field filter on a multigroup that shares a field in another multigroup didn't list it (the shared field that is).

coltrane’s picture

Status: Needs work » Needs review
7.88 KB

Patch removes node type from where clause of content_multigroup_handler_filter::_is_field_multigroup() which fixes the error in #18.

For discussion, for a View utilizing this filter to work the row style must be fields and the filtered fields must be outputted or else the query isn't created properly. Should, if possible, the multigroup view put more constraints in place?

Daniel A. Beilinson’s picture

Looks great! Everything working for me, multigroup has correct format and even shows in correct table with one row for one multigroup value, super!
I have only one question: is there a way to choose only one value of field - from last added multigroup value (row)?

coltrane’s picture

@La_ntegral, you can't do so with the current handler but that's a good idea! I'll check into the feasibility of that.

markus_petrux’s picture

Status: Needs review » Needs work

It seems to me it "needs work" now. Though, I believe we could be able to commit and proceed from there. Agree?

Daniel A. Beilinson’s picture

@coltrane, have you got any ideas?)

mcload’s picture

I tired the patch and it is working for me. Thanks.
I saw that in my case it is necessary to uncheck "Group multiple values" at Fields, otherwise it shows all the values in the multigroup, including unrelated values.

skybow’s picture

I tried the patch and it is working... almost.

In #494100-6: State of the multigroup module markus_petrux describes a situation, where we have three fields / columns in a multigroup configuration.

field_a  field_b  field_c   delta
-------  -------  -------   -----
aaaaaaa  bbbbbbb  ccccccc     0
ddddddd  --       eeeeeee     1
fffffff  ggggggg  hhhhhhh     2

As shown above, in column field_b there is one item not filled out, resulting in no database row for field_b the item with delta=1.

Now, let's create a view to show all three fields and use the filter from the patch for field_a with field_b and field_c enabled in order to filter out the duplicates.
With the current implementation (the patch in #19) of the filter, the line for delta=1 doesn't show up at all.

The SQL Code generated for this looks something like

SELECT [...]
FROM node a
  LEFT JOIN field_a f1 ON a.nid=f1.nid
  LEFT JOIN field_b f2 ON a.nid=f2.nid
  LEFT JOIN field_c f3 ON a.nid=f3.nid

The join in the WHERE clause does not take into account that field_b is missing one row, resulting in leaving out the row for delta=1.
I'm not very used to the JOIN syntax, but from reading some SQL docs, I came up with a solution for the SQL Statement, that does not suppress the row for delta=1:

SELECT [...]
FROM node a
  LEFT JOIN field_a f1 ON a.nid=f1.nid
  LEFT JOIN field_b f2 ON (a.nid=f2.nid and
  LEFT JOIN field_c f3 ON (a.nid=f3.nid and

Note that this solution assumes that there is one sort of mandatory field that has rows for all delta values (field_a in the sample), so chosing one field in the multigroup as masterfield that is responsible for removing the duplicates caused elsewhere is quite good.

One solution would be to insert NULL value fields instead of leaving out a delta value (@markus_petrux: is that an option?)
The other solution is to make the filter modify the way the join is made that it comes up with the above SQL.
Unfortunately I'm (still yet) lacking the PHP/CCK/VIEWS background in order to propose a patch to the filter code.

If this issue can be fixed within the filter handler (which I can't judge with my background), you may ignore the comments that follow. Don't get me wrong (this goes especially to coltrane who enabled me to complain at all - thanks for your work) but I wonder if this approach is going where it should:

As coltrane notes, the workflow of configuring the filter is a bit odd. You have to add the filter to remove the duplicates and you have to disable the grouping of multiple values caused be the handler in The filter fixes a problem that is caused by other handlers that don't know that we have multigroup fields. So it is a bit of a workaround rather than a clean solution to the original problem.

BTW: If the issue gets fixed, I'm happy to live with a workaround...

coltrane’s picture

Assigned: coltrane » Unassigned

Unassigning cause I won't be able to touch the code for a little while.

@skybow non-existent rows for deltas is certainly a problem for this handler, and something that will need to be corrected. Earlier in multigroup development NULL was stored in the database rather than removing the row. You can see #196421: Deleting unwanted multiple values / multiple values delta issues for that. I don't know if it's likely that multigroups could go back to that.

markus_petrux’s picture

Maybe one possible alternative would be to expose the Multigroup as a Views field, the whole multigroup as a whole. Such a *field*, could provide an options form where one could choose which fields in the multigroup need to be rendered, which deltas (as the grouping option for multiple value fields), formatting options as in "display fields" screen, etc. I'm not sure this could cover all use-cases.

markus_petrux’s picture

@coltrane #26 - Re: "I don't know if it's likely that multigroups could go back to that."

For the record: IIRC, this issue comes from yched's comment #8 in that issue:

I figure it out later in that issue, and I changed the multigroup implementation to skip NULL items at storage time:

If we get back to store empty items, we have 2 problems:

- existing installations would have to be upgraded to fill in the gaps.
- the empty/non-empty issue in Views for individual fields re-appears.

If we just look at this, honestly, I'm not really sure which is the best way to go.

However, Fields in D7 will allow a different storage method for fields in multigroups, and I think that means fields in multigroups will be stored in per-multigroup table. Back to D6, I opened the following issue just to try to implement this in D6: #520956: Add a new storage method for fields in multigroups

Once we have fields in multigroups in its own table, it would be the same as if we were storing NULL values for all items in separate per-field tables, and so we'll have the empty/non-empty issue in Views for individual fields again.

If #520956 is implemented, and it seems that's the way to go in D7, then we'll have to migrate existing installations to the new storage method. So I would not change multigroups to store NULLs now (fill in the gaps), provide migration path for existing installations, and then change storage method again to implement per-multigroup tables.

So it seems Views integration for fields in multigroups depends on #520956: Add a new storage method for fields in multigroups.

In the meantime, is "Multigroup as a Views field" as described in #27 an option? If so, this feature could also remain when per-multigroup storage is implemented.

Thoughts? Suggestions?

skybow’s picture

Hi every body

I changed the code in in order to achieve the JOIN I described in #25

  function query() {
    $base_alias = $this->ensure_my_table();
    foreach ($this->options['content_multigroup_fields'] as $option_table) {
      $alias = $this->query->ensure_table($option_table, $this->relationship);
      $this->query->table_queue[$option_table]['join']->extra = $base_alias  . ".delta = " . $alias . ".delta"; 
//      $this->query->add_where($this->options['group'], "$this-> =", $option_table);

What it does:
Instead of adding WHERE rules, which we don't want, it alters the JOIN relations by adding an extra value containing the definition we want. Since I can't be sure that the depending tables have already been processed, I call ensure_table for the tables in the options list first, which will build the JOIN relation. Then I can add the alteration to the JOIN.

Works for me in a quick test so far.
Is that somewhat the "official" way to alter a JOIN? How about the usage of alia?


PS: I modified the patch from #19 by hand, so could be someone so kind to check on this?

markus_petrux’s picture

I just committed hook_views_api() to the multigroup module (patch) and also created the views subdirectory with an empty file (patch) that can be used as a placeholder for what we do here.

Next, I'll try to re-roll the latest patch here. I'm guessing this is the one in #29. However, even if this approach goes in, I think it needs work as it seems to me class methods that do not add anything special can be removed, and maybe there's a better way to check if fields are part of a multigroup, etc.

Aside, I would like to explore the possibility to expose the multigroup as a whole to views. It may provide a settings form where you can choose which fields in the multigroup you want to render, and maybe a new method to render the multigroup here, so it can be easily adapted.

markus_petrux’s picture

Well, here it is a re-roll of the patch in #29.

One problem I see in this patch is that the name of the filter exposed to views is the group name, BUT... nothing in CCK prevents from creating more than one group with the same name in different content types, and this will lead to unexpected results here.

So, I'm going to rewrite this patch to use type_name + group_name for the filter name. This will have an additional advantage. We can get rid of the _is_field_multivalue() and _is_field_multigroup() methods in favor of content APIs to get the list of fields in that particular group for a that particular node type.

Thoughts and suggestions are welcome.

skybow’s picture

As I mentioned earlier, I agree that the current solution should be improved in terms of user interface.
However, I very much like the idea to add only a certain subset of the fields in a multigroup to the view. I also like the ability to change the order of these fields the way it can be done now, by simply dragging the fields around.
With a "multigroup as whole" solution, how would it be possible to let one handler show multiple fields and move them around? Is that possible with CCK?

I just browsed the code a bit and wanted to ask if the following outline would be a possible way to go:
From the UI perspective, we just add the member fields of the multigroup as usual.
When adding a multigroup field, use a content_handler_field_multigroup class instead of the content_handler_field_multiple for field representation.

With the first multigroup field included, automatically add an (implicit) content_handler_multigroup_shared class item. For all multigroup fields included, the instance of the content_handler_multigroup_shared will be referenced from within the content_handler_field_multigroup instances.
This way, the existence of multigroup fields control the implicit existence of some shared controller object that takes care of common tasks / options.

If options are necessary at all, the shared controller could show up explicetly in the field list (which I'd prefer not to) in order to present its own settings dialog. The settings of the shared controller could be appended to each multigroup field (which would result in duplicating the common options in each field)

In a simple setup, the content_handler_multigroup_shared would replace the content_multigroup_handler_filter code and show an option that defines the master multigroup field.

Any thoughts on this?

markus_petrux’s picture

Re: "use a content_handler_field_multigroup class instead of the content_handler_field_multiple for field representation"

This is an interesting approach. Maybe there's a way to alter the joins here to append deltas to the join conditions for the fields in the same multigroup.

I don't care much about how to choose a "master" field in the multigroup as we may add per-multigroup table storage for fields in multigroups. We would not need this either if all fields in the multigroup were storing the same exact number of deltas, even those that would be empty. See #28 above.

skybow’s picture

Re: master field

As long as one of the fields in a multigroup is marked required and chosen in the View, we're all set: the required fields can perfectly serve as master field because it ensures that all deltas are present.

@markus_petrux: do you think this can be done without an implicit shared multigroup handler?

markus_petrux’s picture

One caveat if we replace the content_handler_field_multiple handler with a new one for fields in multigroups is that we cannot target fields that override this handler, such as date, for example. We cannot dynamically tell a handler to extend another base handler. And we cannot create a handler class that extends another class dynamically. :(

So, I think I'll post here a new version of coltrane + skybow filter. And that's what we'll have for now, unless another idea shines.

markus_petrux’s picture

Patch re-rolled again.

Basic changes:
- This time hook_views_data_alter() uses content/fieldgroup APIs to obtain multigroups information.
- The name of the Views filter is type_name + group_name.
- The filter handler does not need private methods to find fields in the same multigroup as the master field.
- The filter is now exposed to the "Content multigroups" category, not the "Content" category.
- The labels and help text of the filter have been changed a little.

One more thing I would like to explore now is if we really need to ask for fields that are part of the multigroup in the filter options form. If we can obtains this information in the query() method, then we can simply alter the joins and go.

If that's possible, then I think this will be ready to be committed.

If one day we have per-multigroup storage, then this filter will not be needed at all.

markus_petrux’s picture

Status: Needs work » Needs review
6.63 KB

Re-rolled again. This time there's no filter options form. And I think this is now ready to be committed.

Please test and let me know. Thanks

markus_petrux’s picture

Yet another re-roll.

This time there's only one filter per multigroup, and there's an options form to allow users choose the master field, which will be used as the first join with the node table, without delta, and the other fields will be joined with this one, with deltas.

I like this approach better because if we change the code in the multigroup to store NULLs for all values, then the same filter will work, we could then remove the options form as any field can be used as master field, but the same filter will work.

Of course, this filter will not be needed at all if we add per-multigroup tables, but that's more complex and we may or may not have the time to do it in the short term.

I think this is the best we can do for now. Please test and let me know if you see room for improvements. Otherwise, I'll commit this soon. :)

In regards to options to filter by an arbitrary delta, I think this can be done in another issue. Please, see: #227129: Expose "delta" column in multiple value fields to Views

skybow’s picture

Status: Needs review » Needs work

On the other hand, the date module replaces the content_handler_field_multiple by date_handler_field_multiple, so we could provide a patch to do the same thing for date fields.
Nevertheless I agree to proceed by committing the code and revisiting this later.

skybow’s picture


Wanted to give you feedback to the patch from #38: Works great.

markus_petrux’s picture

Status: Needs work » Fixed

Ok, so I just have committed the patch in #38. I have also added a note in the README of multigroup module about Views integration.

Thank you very much to all who have helped here in one way or another!

Feel free to re-open (or open a separate issue) if Views integration in Multigroups needs more attention.

keenkei’s picture

Version: 6.x-3.x-dev » 6.x-2.5

i solve it by a simple non coding way,... (and waiting for better release)

if i get dublicates in views by multi field,...

in "views" "fields" "Configure" field:

- (X) "Rewrite the output of this field"

- set your field as "Replacement patterns" for example: "[field_interface_usb_value]"

- (X) "Group multiple values"

it works by me with text fields,...

not tested with "images" (not used by me) or "file fields"(solved with actual .dev)

is this way save ?????


s4j4n’s picture

How soon is the work in the patches actually reflected in the nightly dev build download for CKK 3.x? (i.e. when does it show up in here... )


markus_petrux’s picture

I think it happens twice a day. See:

Lasac’s picture

how could i use this patch.. i have looked at the drupal documentation on applying patches and watched a video but i do not have a terminal for my host. This topic is exactly what i need to fix and it has given me a headache for quite some time now.

markus_petrux’s picture

This feature is already available in the development snapshot of CCK3. It provides a filter that's available under "Content multigroup" in the list of filters in the Views UI.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

markus_petrux’s picture

Version: 6.x-2.5 » 6.x-3.x-dev
paganwinter’s picture

Worked of rme too.
But configuring multigroup fields in views is indeed a tough nut to crack...
someone should come up with some kind of a guide to doing this.

Thanks coltrane, skybow and markus for the efforts!

Unless you start building different kinds of sites, you don't realize what additional features are needed/can be built!
One more question, I have a MG with 2 fields, 2nd one being optional.
Now in my view I need a table of these 2 fields (which I have managed to get as I wanted), along with another field (single value).
But this single value field is appearing as many times as there are multigroup fields. Any way out of this? I CAN live with this though! :)

blueblade’s picture

Hi paganwinter,

Can you write us a summary of how to get it done please? I read the thread several times but am a little confused...many thanks.


blueblade’s picture

Do we still need those patches for Views 6.x-2.8?

paganwinter’s picture

From what I remeber, there are 2 additional things you need to do for such views:

1. Filter: Content multigroup > Select the field that you think is unique in the listing
2. Fields: Uncheck 'Group multiple values together'

Junro’s picture

Hello, I can't synchronize my fields in views

I'm using Taxonomy terms for my two fields with the filter Content multigroup.

Any idea?


ps: where is the option " Fields: Uncheck 'Group multiple values together'"?

for exemple:

Column 1 Column 2

My view will be:

Column 1 Column 2
................. Ford

Junro’s picture

Hum I tried another view with a node referrence field and a text field and it works very well even without using the content multigroup filter.

Maybe there is a problem using content multigroup with taxonomy, and particulary with autocomplete freetaging widget.

Anyone knows something about it?

Junro’s picture

Hum I don't have this problem anymore :)

TheodorosPloumis’s picture

This worked for me too. Using integer and text fields. Thank a lot.

TheodorosPloumis’s picture

Is the solution with CCK3 dev also working with views 3.x? Although I followed the instructions I get an error on SQL. I have separate fields for each node type.

user warning: Unknown column '' in 'on clause' query: SELECT DISTINCT node_data_field_age.field_age_value AS node_data_field_age_field_age_value, AS node_data_field_age_delta, node.type AS node_type, node.nid AS nid, node.vid AS node_vid, node_data_field_gender.field_gender_value AS node_data_field_gender_field_gender_value, AS node_data_field_gender_delta, node_data_field_bed.field_bed_value AS node_data_field_bed_field_bed_value, AS node_data_field_bed_delta, node_data_field_pay_health.field_pay_health_value AS node_data_field_pay_health_field_pay_health_value, AS node_data_field_pay_health_delta FROM node node LEFT JOIN content_field_age node_data_field_age ON node.vid = node_data_field_age.vid AND ( = INNER JOIN content_field_gender node_data_field_gender ON node.vid = node_data_field_gender.vid INNER JOIN content_field_bed node_data_field_bed ON node.vid = node_data_field_bed.vid AND ( = LEFT JOIN content_field_pay_health node_data_field_pay_health ON node.vid = node_data_field_pay_health.vid AND ( = WHERE (node.type in ('program_health')) AND (node_data_field_age.field_age_value = 20) AND (node_data_field_gender.field_gender_value = 'female') AND (node_data_field_bed.field_bed_value = '1bed') LIMIT 0, 1 in ..\sites\all\modules\views\plugins\ on line 1119.

I use the latest cck-6.x-3.x-dev and Views 6.x-3.x-dev.

TheodorosPloumis’s picture

Problem in #57Solved. I had to use the Content Multigroup filter before any other filters for single cck fields.

liquidcms’s picture

Status: Active » Closed (fixed)

does this work? or is my app different.. seems like it should be the same issue:

- i have a node type Video
- it has a mgroup ("guest") with fields name and position

my site has 2 video nodes, the 1st has 1 guest, the 2nd has 3 guests.

the best i can seem to get is this:

Title: Test Video 1
Pam Stewart, CTO

Title: Test Video 2
Rachel Morin, VP Operations

Title: Test Video 2
Carmela Manno, Senior VP Sales

Title: Test Video 2
Tom Smith, VP Production

should i not be able to expect this:

Title: Test Video 1
Pam Stewart, CTO

Title: Test Video 2
Rachel Morin, VP Operations
Carmela Manno, Senior VP Sales
Tom Smith, VP Production

i'm using:
6.x-3.x-dev (2011-Jun-04)

- i have done a re-write to combine the 2 fields from the group
- i use the multigroup filter (selecting Name as sync field)
- i do not check the Group multiple values option for either Name or Position fields.

liquidcms’s picture

Status: Closed (fixed) » Active

Status: Closed (fixed) » Active