Comments

jenlampton’s picture

+1 yes please :)

sbilde’s picture

Issue summary: View changes

+1 Would be really awesome. - Will totally eliminate the need for field collection for me, if this was possible.

Would this also make it possible to aggregate the individual sub-field values?

Dave Reid’s picture

Assigned: Unassigned » Dave Reid

I started working on this on the last weekend and tried a couple of 'easy' things to make Views support which didn't pan out. It looks like I need to write my own Views field handler that works similarly to views_handler_field_field. I started work in a branch but it's not at all ready yet even for alpha testing. But just confirming this is on my radar and something I want included in the next release.

sbilde’s picture

Sounds great. - Whenever you have something ready for test, just say the word :)

filijonka’s picture

perhaps you consider it to early but it would be interesting to see it on the repos. then if other have time they might already now be able to ship in some time on it.

doub1ejack’s picture

+1 & Following. Tested out this module and it works very nicely for my simple, text-field-only, scenario. The only thing holding me back is an inability to access the data in views.

trainingcity’s picture

Very interested in this module as a replacement for Field Collections.

Only feature gating factor I can think of is robust Views support for the sub fields. Being able to access the content from views is critical.

The single instance of each sub field is fairly minor.

Heihachi88’s picture

Any updates on this?

FreeXenon’s picture

Yea, I this has been my big bugbear too!

I would just use Field Collections, but there is no View Support.
You have some which is awesome, and I cannot wait until it does.
As trainingcity said above access to field values in views is critical.

Keep up the good work.

attiks’s picture

attiks’s picture

I thought about this a bit, and it sounds similar to the views integration for addressfield, only differences are that the composition is dynamic and it uses real field formatters, but it might be a good starting point?

attiks’s picture

FileSize
2.53 KB

Attached patch is against the views-integration branch, it makes the sub field show up so they are selectable, the views options are using the right hanlders, but no data is outputted.

Uploading here so maybe somebody else might find it usefull.

attiks’s picture

Alternative solution (untested) might be to define a new table definition in views with the subfields and define a new relation between the entity base table and the field_data table

Jelle_S’s picture

Status: Active » Needs review
FileSize
8.31 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch i2041533-14.patch. Unable to apply patch. See the log in the details link for more information. View

Patch based on #12. Field values are now displayed. I'm not exactly sure how robust this approach is. I tested it with taxonomy:

  • Field was displayed correctly.
  • Sort handler produced a correct query.
  • Filter handler produced a correct query (and the correct options list to choose a term from).
  • Argument handler produced a correct query (contextual filter).
  • Relationship handler produced a correct query (relation to the taxonomy_term_data table).

Status: Needs review » Needs work

The last submitted patch, 14: i2041533-14.patch, failed testing.

Jelle_S’s picture

Ah yes, the patch was made against the views-integration branch, as @attiks did, so it will probably not apply to 7.x-1.x...

Jelle_S’s picture

FileSize
9.44 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch i2041533-17.patch. Unable to apply patch. See the log in the details link for more information. View

New patch with some cleanup & using the handler @Dave Reid had already started writing. (Patch is again against views-integration branch)

attiks’s picture

We're getting closer, field is showing data, but if you select to show them on separate rows, it shows all values on all rows

attiks’s picture

FileSize
10.32 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch i2041533-19.patch. Unable to apply patch. See the log in the details link for more information. View
1.23 KB

New patch with support for multiple records

attiks’s picture

FileSize
10.31 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch i2041533-20.patch. Unable to apply patch. See the log in the details link for more information. View
545 bytes

working patch

PS: rewrite result is not working, and multi lingual is not tested.

Jelle_S’s picture

FileSize
13.23 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch i2041533-21.patch. Unable to apply patch. See the log in the details link for more information. View
4.62 KB

Fixes rewriting results & click sort

Jelle_S’s picture

FileSize
13.71 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch i2041533-22.patch. Unable to apply patch. See the log in the details link for more information. View
1.18 KB

Fixes another issue where rewriting results was working in preview, but not when actually viewing the view.

Kokosnoot’s picture

Sorry, but I do not have the following file in my multifield module: /MultifieldViewsHandler.php. Where can I find this?

Sorry for my answer, I have found the git link.

Patch works fine here, subfields can be added in Views now.

drupauler’s picture

Hello Chaps, I'v been having a play. Mega Kudos to all involved.

My use case is to create a multifield for location information which is presented in a views table, and for that the patch seems to works fine.

However, when I build a view to display the geofield locations with format geofield map, I'm stymied because geofield map is looking for a field of type geofield and what it is presented with is a field of type multifield:geofield.

I suspect this an issue for geofield_map rather than multifield but I mention it here as it could be a generic problem.

Thanks again

attiks’s picture

#24: Yes, known problem (for now), we're facing the same with date fields in combination with full calendar module, would be nice if we could solve this in the multifield module

Update: problem was related to the date module, so your problem is probably something else, you could check the code to see how they decide if a field is appropriate or not. FYI date fields in views are using a key "is date" in the definition.

attiks’s picture

Status: Needs work » Reviewed & tested by the community

Marking as RTBC, since marking as NR will trigger the testbot

The last submitted patch, 17: i2041533-17.patch, failed testing.

The last submitted patch, 19: i2041533-19.patch, failed testing.

The last submitted patch, 20: i2041533-20.patch, failed testing.

The last submitted patch, 21: i2041533-21.patch, failed testing.

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 22: i2041533-22.patch, failed testing.

Jelle_S’s picture

Status: Needs work » Needs review
FileSize
39.7 KB
PASSED: [[SimpleTest]]: [MySQL] 96 pass(es). View

Patch against 7.x-1.x-dev so the testbot is happy again.
Works exactly the same as the patch against the views-integration branch from #22

Jelle_S’s picture

FileSize
39.73 KB
PASSED: [[SimpleTest]]: [MySQL] 96 pass(es). View

This patch works better with date and fullcalendar. The field_info property of the MultifieldViewsHandler now contains the field_info of the subfield.

Jelle_S’s picture

FileSize
39.82 KB
PASSED: [[SimpleTest]]: [MySQL] 96 pass(es). View
609 bytes

Improved patch for rendering the multifield subfield values in views.

aburrows’s picture

Tested patch and it shows missing handler error in views

attiks’s picture

Did you clear all caches (drush cc all) and the views cache (drush cc views)?

PieterWintmolders’s picture

Same problem here; Broken/missing handler.
Views 7.x-3.7
Notice: Undefined index: element_type_enable in views_handler_field->options_submit()
Notice: Undefined index: element_label_type_enable in views_handler_field->options_submit()
Notice: Undefined index: element_wrapper_type_enable in views_handler_field->options_submit()
Notice: Undefined index: element_class_enable in views_handler_field->options_submit()

PieterWintmolders’s picture

Found the issue
Had to add 'files[] = MultifieldViewsHandler.php' to the multifield.info.

Works like a charm now, thanks!

attiks’s picture

I should be there, how did you apply the patch?

diff --git a/multifield.info b/multifield.info
index 4e50a68..09d2dac 100644
--- a/multifield.info
+++ b/multifield.info
@@ -6,6 +6,7 @@ dependencies[] = ctools
 dependencies[] = field
 configure = admin/structure/multifield
 files[] = MultifieldEntityController.php
+files[] = MultifieldViewsHandler.php
 files[] = tests/MultifieldAdministrationTestCase.test
 files[] = tests/MultifieldDevelGenerateTestCase.test
 files[] = tests/MultifieldEntityTranslationTestCase.test
PieterWintmolders’s picture

I think the problem is that I started with the '7.x-1.0-unstable9'-version.

That multifield.info doesn't contain 'files[] = tests/MultifieldDevelGenerateTestCase.test' and made the patch ignore the info-file?

attiks’s picture

#40: That explains a lot, you always have to start from the dev version if you want to apply a patch

attiks’s picture

Status: Needs review » Reviewed & tested by the community

AFAIK this is RTBC

Dave Reid’s picture

Reviewing today.

Molfar’s picture

So, is there any progress with views integration? At project's page a links to this issue marked as green. What does it mean?

Dave Reid’s picture

Status: Reviewed & tested by the community » Needs review
FileSize
41.35 KB
PASSED: [[SimpleTest]]: [MySQL] 97 pass(es). View

Re-rolled, updated, and fixed variables names. Moved Views hooks to multifield.views.inc. Can someone confirm if this updated patch is still working as before?

mihai_brb’s picture

This was exactly what I was looking for!
I don't know how it worked before. I just tested with a multifield of entityreference and some other decimal/text fields and it worked. All sub-fields show up in views.

Thanks,
Mihai

attiks’s picture

Status: Needs review » Reviewed & tested by the community

Mihai, if it works you can mark it RTBC

attiks’s picture

@jelle_s can you do a quick test?

Jelle_S’s picture

Status: Reviewed & tested by the community » Needs review
FileSize
41.08 KB
PASSED: [[SimpleTest]]: [MySQL] 97 pass(es). View
1.54 KB

Small fix and a bit of cleanup.

Dave Reid’s picture

attiks’s picture

Dave Reid’s picture

I didn't see anything specifically that needed to be changed in this patch as a result of #2234769: Should multifield types be represented as separate field types, or just one 'Multifield' field type?. That's the beauty of having all the wrapper APIs available.

Jelle_S’s picture

@Dave: I combined the patch from #2234769: Should multifield types be represented as separate field types, or just one 'Multifield' field type? with this one in that issue. Some changes were needed as in the views handler class $field['type'] was called directly in stead of multifield_extract_multifield_machine_name. And it needed a reroll anyway since it didn't apply anymore after applying the patch from #2234769.

Dave Reid’s picture

Let's not combine the patches please and update this one assuming that 2234769 will be committed.

Dave Reid’s picture

@Jelle_S: I'm seeing multifield_extract_multifield_machine_name() being used properly multifield_field_views_data and related function in the latest patch here, I'm not sure what you mean.

Jelle_S’s picture

@Dave

  1. +++ b/MultifieldViewsHandler.php
    @@ -0,0 +1,909 @@
    +    foreach ($multifield_items as $multifield_item) {
    +      $multifield = _multifield_field_item_to_entity($this->multifield_info['type'], $multifield_item, array('machine_name' => $this->multifield_info['type']));
    +      $subfield_langcode = $this->field_language('multifield', $multifield);
    +      if (empty($render_array)) {
    

    This is the one I was talking about.

  2. +++ b/multifield.module
    @@ -516,3 +518,94 @@ function multifield_admin_menu_map() {
    +function _multifield_subfield_views_data($field) {
    +  $data = array();
    +  foreach (multifield_type_get_subfields($field['type']) as $subfield_name) {
    +    $subfield = field_info_field($subfield_name);
    

    This one as well.

Dave Reid’s picture

Status: Needs review » Needs work

Yeah, those should definitely be using the API and should be fixed in this issue.

Jelle_S’s picture

Status: Needs work » Needs review
FileSize
41.1 KB
PASSED: [[SimpleTest]]: [MySQL] 97 pass(es). View
1.12 KB

New patch that fixes the issues from #56

Jelle_S’s picture

FileSize
41.16 KB
PASSED: [[SimpleTest]]: [MySQL] 185 pass(es). View

Rerolled patch (patch will fail because current dev without this patch fails as well: https://www.drupal.org/node/1992610/qa)

bigpun6681’s picture

Hello Jelle_S,

i used your patch and everything works fine. Thanks a lot for that great patch.

If the first value in the column is empty it's not printed. Is it possible to implement an option, to print the first value even it's empty. An answer would help me so much.

Greetings

René

BenVercammen’s picture

I've applied 2041533-59-views-integration.patch and can now successfully use a contextual filter on multifield subfields in my views. Thanks!

0nly_tom’s picture

Thank you very much for this patch.

imclean’s picture

Trying this out but running into a situation where MultifieldViewsHandler::post_execute is firing 14 times.

This iterates over the values and executes set_items() each time. Not so bad with a small number but we have one with 185 fields, which leads to 2,590 calls to set_items! Very slow.

I'm not sure why this is happening yet, or if it's something specific to our set up.

imclean’s picture

14 is how many sub fields we have.

So, post_execute is getting called for each sub field, then calling set_items() for all rows each time.

imclean’s picture

Ok, I'm a bit slow here. Clearly each subfield needs to be set for each row.

mkinnan’s picture

When I filter by a multifield subfield of type date, I get the following error:

Notice: Undefined index: tz_handling in date_views_filter_handler_simple->init() (line 21 of /var/www/html/sites/all/modules/date/date_views/includes/date_views_filter_handler_simple.inc).

I add the subfield to the filter section. As soon as I do that, I see the error messages in the drupal log. It does not seem to matter what the filter settings are for the date field.

TazimHossain’s picture

FileSize
15.06 KB
23.53 KB
23.96 KB
26.94 KB

Hi,
when i try to display my multifield field in views, after patched #59, views say "Broken/missing handler".

please...
can anyone help me...

waiting for any response.
Thanx.

deanflory’s picture

Maybe try editing the individual fields in the View and just saving them, sometimes that updates code. Then save the View. Just a thought.

bellagio’s picture

After applying #59 patch, i get Warning: array_walk() expects parameter 1 to be array, boolean given in MultifieldViewsHandler->set_items() (line 849 of ..\multifield\MultifieldViewsHandler.php).
Warning: Invalid argument supplied for foreach() in MultifieldViewsHandler->set_items() (line 851 of ..\multifield\MultifieldViewsHandler.php), only when i added the newly available 'multifield: myfield_name' to the fields.

MustangGB’s picture

I have a problem with #59 caused by:

public function __call($name, $arguments) {
  return call_user_func_array(array($this->fieldHandler, $name), $arguments);
}

It's kicking out the following warnings:

Warning: call_user_func_array() expects parameter 1 to be a valid callback, class 'views_handler_field_field' does not have a method 'php_pre_execute' in MultifieldViewsHandler->__call() (line 907 of sites/all/modules/multifield/MultifieldViewsHandler.php).

php_pre_execute seems to be something used by views_php

MustangGB’s picture

Status: Needs review » Needs work
MustangGB’s picture

Okay so the "problem" is __call() responds true to is_callable(), I think the best thing to do is to check our method is callable as well.

i.e.

public function __call($name, $arguments) {
  if (is_callable(array($this->fieldHandler, $name))) {
    return call_user_func_array(array($this->fieldHandler, $name), $arguments);
  }
}
dobe’s picture

I applied the patch and everything seems good so far. I am also exposing this to services and the services raw output works nicely.

-Jesse

loparr’s picture

Patch throws
Warning: array_walk() expects parameter 1 to be array, boolean given in MultifieldViewsHandler->set_items() (line 849 of /sites/all/modules/multifield/MultifieldViewsHandler.php).
Warning: Invalid argument supplied for foreach() in MultifieldViewsHandler->set_items() (line 851 of /web/sites/all/modules/multifield/MultifieldViewsHandler.php).

Hovewer, the error is not shown if I display results inside view (using argument)

epringi’s picture

#59 works like a charm, thanks guys! :)

MustangGB’s picture

Found another issue, filtering by a multifield subfield that is a list complains that is can't find it's allowed_values.

Bensbury’s picture

I applied the patch from #59 and seems to have worked fine for subfields that are text format and term reference.
Only minor thing is they are not sortable to a Table Display, but can use javascript for that.

MustangGB’s picture

Following on from #76, if we want to use the original filter handler for subfields rather than our write own then in the case of lists at least the field_name must be correct so it can load the allowed_values, the following changes to the patch in #59 solved it for me:

multifield.views.inc

 function multifield_field_views_data($field) {
   ...
   foreach (array('argument', 'filter', 'sort') as $handler) {
     if (isset($subfield_data['field_data_' . $subfield_name][$source_field][$handler]) && isset($table[$f_data['field']['additional fields'][$index]][$handler])) {
+      // Overwrite field_name.
+      $table[$f_data['field']['additional fields'][$index]][$handler]['field_name'] = $subfield_data['field_data_' . $subfield_name][$source_field][$handler]['field_name'];
       // Overwrite handler.
       $table[$f_data['field']['additional fields'][$index]][$handler]['handler'] = $subfield_data['field_data_' . $subfield_name][$source_field][$handler]['handler'];
-      // Add additional options without overwriting table, field_name etc.
+      // Add additional options without overwriting table etc.
       $table[$f_data['field']['additional fields'][$index]][$handler] += $subfield_data['field_data_' . $subfield_name][$source_field][$handler];
     }
   }
   ...
 }
osopolar’s picture

FileSize
41.42 KB
PASSED: [[SimpleTest]]: [MySQL] 185 pass(es). View

The warnings in #69 and #70 will appear, when a multifield is empty. See field_get_items, which returns false if $entity->{$field_name}[$langcode] is not set.

I changed the patch from #59 to check if the $multifield_items variable is an array. If not I set it to an empty array.

Interdiff:

-    $multifield_items = field_get_items($entity_type, $entity, $this->definition['field_name'], $langcode);
+    $multifield_items = field_get_items($entity_type, $entity, $this->definition['field_name'], $langcode);
+
+    if (is_array($multifield_items)) {
+      array_walk($multifield_items, 'multifield_item_unserialize', multifield_extract_multifield_machine_name($this->multifield_info));
+    }
+    else {
+      $multifield_items = array();
+    }

About the error in #70: I can't reproduce that. But maybe it's because I don't use multifield-fields as filter or sort criteria. I also can't see who is trying to call php_pre_execute, maybe it's a error of that module calling non existing/registered functions?

I am not familiar with __call function. I haven't seen the proposed check is_callable anywhere else in __call methods. But I found a post from Larry Garfield (Crell) from about 8 years ago, called Magical PHP: __call(), where the dynamic methods have to be registered before they could be used. Maybe this should be used here too?

osopolar’s picture

Status: Needs work » Needs review
akumajo’s picture

#79 works fine with dozen of subfields...
any ETA for a new release ? would love to use this KICKASS module for new projects

bkat’s picture

This patch is working pretty well. However, I'm trying to use editablefields with subfields contained in multifield. I have editablefields working on node edit with a change I submitted. https://www.drupal.org/node/2643362

However with editablefields its not working correctly. I'm not entirely sure if editablefields or this patch is making poor assumptions.

It looks like we need the entity to be the editablefields pseudo entity. However, when rendering an editablefields in a view, editablefields_field_formatter_view calls

 // Load the original (unrendered) entity from the cache of the Field API views handler.
 $entity = $view->result[$row_id]->_field_data[$views_field->field_alias]['entity'];

This is called when MultifieldViewsHandler calls

$render_array = field_view_field('multifield', $multifield, $this->definition['subfield_name'], $display, $subfield_langcode);

Which replaces the $entity passed in with the parent node (in all my cases) but the entity_type remains 'multifield'.

For now, I just wrapped the editablefields code in a check for multifield

 // Load the original (unrendered) entity from the cache of the Field API views handler.
 if ($entity_type != 'multifield') {
    $entity = $view->result[$row_id]->_field_data[$views_field->field_alias]['entity'];
 }

But that's not a real solution. I can raise an issue with editable fields as well.

edysmp’s picture

FileSize
41.48 KB
1.23 KB

Apply change from #78, it this work for filter criteria.

attiks’s picture

Status: Needs review » Reviewed & tested by the community
kansaj’s picture

Probably it should be

// Multifield subfields are always single value.
		if (isset($subfield_render_array[0])) {
        $render_array[] = $subfield_render_array[0];
		}
paulwdru’s picture

Issue summary: View changes

Hi,

I'm totally lost, which patch shall apply to which version ?

Thanks

paulwdru’s picture

Hi,

I apply patch #83 to 7.x-1.x-dev successfully, it resolves Select Text List field in exposed filter with options display, however Entity Reference field (referencing taxonomy) is still unable to be used as Filter Criteria.

I did try adding whatsoever relationships following the normal practice with Entity Reference but it still does not show up in Filter Criteria.

Any idea ? Thanks

vblanco7’s picture

I apply patch #83 it's work!!

thanks!!

attiks’s picture

Status: Reviewed & tested by the community » Needs work

So back to needs work, or we handle Entity reference in a follow up

MustangGB’s picture

Priority: Normal » Major

Based on this issue's popularity and that it's a release blocker hopefully no-one minds bumping the priority up a little.

glynster’s picture

@MustangGB RTBC +1 Please commit!

MustangGB’s picture

Issue summary: View changes
Status: Needs work » Needs review
FileSize
42.41 KB

Straight re-roll of #83, NR for tests.

MustangGB’s picture

Issue summary: View changes

Whoops, wrong textarea, didn't mean to edit IS.

Status: Needs review » Needs work

The last submitted patch, 92: multifield-2041533-92.patch, failed testing.

The last submitted patch, 92: multifield-2041533-92.patch, failed testing.

MustangGB’s picture

Status: Needs review » Needs work

The last submitted patch, 96: multifield-2041533-96.patch, failed testing.

The last submitted patch, 96: multifield-2041533-96.patch, failed testing.

The last submitted patch, 83: multifield-views-integration-2041533-83.patch, failed testing.

MustangGB’s picture

Strange, tests are passing fine for me locally.

The last submitted patch, 96: multifield-2041533-96.patch, failed testing.

Dave Reid’s picture

Status: Needs work » Needs review

Test failure is a recent change in Drupal 7 that added the 'administer fields' permission. I fixed this with #2737837: Update tests for new 'administer fields' permission.

Lingaraj_M’s picture

#96 Works like a charm now, thank you.

darol100’s picture

Status: Needs review » Reviewed & tested by the community

I can confirm that the patch from #96 works fine.

glynster’s picture

RTBC +1 Please commit for the next release!

glynster’s picture

Looks like this did not make it into the Alpha 4 release :(

glynster’s picture

Patch #96 still works well against Alpha 4 release! RTBC +1

Anybody’s picture

+1 for a commit soon!! :)

crawcole’s picture

Working well except for filtering by Entity Reference, which is a major downside.

MustangGB’s picture

I re-found the view that was causing the problems for me in #70.

Can handle it here or as a follow-up, I'm not really fussed.