1

BACKGROUND: Site is using content types which are auto-created through Rules, called CT-A and CT-B. CT-B represents a full URL, and CT-A represents that URL domain. CT-A is always created via Rules only once, the first time a content type CT-B is created. Both content types share a field (field_domain) specifying the domain. The original content is user entered, so it isn't possible to predict the value of field_domain in advance.

ISSUE: I need to display a simple 'related content' type view in CT-A, showing all nodes of type CT-B which match the value for field_domain. The value for field_domain cannot be pre-defined, and needs to be provided program / systematically, either by being taken from the field in the node, or as a token (same difference).

APPROACHES: I am assuming the answer is in Views. Specifying a value for field_domain doesn't work, because the value changes based on user entry. I've tried Global: Field Comparison, but it doesn't seem to be possible to compare both the current node's field_domain and that same field in the nodes displayed in Views. I have tried using Views Panes to pass the argument for the current node's field_domain into the pane display, but it also didn't return results. I have seen various Contextual Filter PHP solutions, but they also don't seem to work (the most promising one is https://www.drupal.org/node/1006484#comment-4990312 , but this returns the following error: https://www.drupal.org/node/829250).

Taxonomy hasn't worked, because of the auto-create nature. It doesn't seem to be possible to create unique TermID by passing values in Rules - the Term name will be the same, but the TermID is different, and Views judges the Term based on its ID. It isn't possible to auto-create a Term Vocabulary in Rules due to a bug with assigning the machine name.

Entity Reference also has problems with the auto-create nature. I haven't figured out a way in Rules to reference the two types according to field_domain value, and not sure if there is one.

Search API Tried this approach (compare the search index) suggested in the link below, but again it doesn't work unless you have a predefined value for field_domain, as it requires setting the value manually.

The most obvious approach seems to be "Views filter display all nodes with same field value. But despite being obvious, this doesn't seem to be easily possible. Perhaps there is a non-Views way which I haven't considered?

Related questions to this (all seem to be unsolved):

[apologies, I'm limited by reputation...but there are at least 4 open questions in related questions to the right which are still unsolved]

Throwing it open...seems like a few people have run up against this problem. Any new ideas out there?

|improve this question
1

The way I've always handled this is to build the view in question using the "field value to match" as a Contextual Filter. For the Contextual Filter's settings, choose "Provide default value", for the type choose "PHP Code", and for the "PHP contextual filter code", load the current node and grab it's field value,

$node = menu_get_object();
return $node->field_domain['und'][0]['value'];
|improve this answer
  • Thanks for answering sgorneau. Thats almost exactly how I have it set up for other views, like showing content from the same author. However, in this case, those precise steps above aren't returning anything on the page. If I remove the contextual filter the whole content type displays fine, but with the filter nothing matches. Equally, if I set a manual filter (Fields; Filter; Field -> equal to -> "domain.com") to the value of field_domain, it will show all nodes matching that value - but that will mean a lot of manual admin. But automatically getting the value seems to fail somewhere. – Sarastro Sep 11 '17 at 15:38
  • Clarification: is "field value to match" an actual setting somewhere, or simply describing the function of the contextual filter? – Sarastro Sep 11 '17 at 15:40
  • Sorry, "field value to match" simply means whatever field you're trying to match the value on. Is it safe to assume that field_domain is a text field and not a select/check/radio with key values? – sgorneau Sep 11 '17 at 16:30
  • That's correct, plaintext with no formatting. – Sarastro Sep 11 '17 at 18:30
  • Hmm, my original answer is pretty straight forward and should provide the desired results ... so something else must at play here. Safe to assume 1. There are no other filters in use? 2. All nodes have a value for this field? Also, can dpm( $node ) or mail( 'youremail', '$node' , print_r( $node , 1 ) ) (to yourself) the $node object from menu_get_object() to see what value it's passing to the view? – sgorneau Sep 11 '17 at 19:27
0

** !! SOLUTION !! **

A version of Sgorneau's suggestion worked. For some reason, a contextual filter comparing the node field (e.g. the page in which the view is displaying) with the same field in the displayed nodes (e.g. the nodes in the view) was not working for me. As a test, I created an identical field value in both types of node and compared those fields to each other. This now works in the View as desired. Steps for anyone trying to replicate:

Create a mirror field for the field you want to view (Rules -> Event: after saving / updating content -> Condition: has "field_domain"-> Action: Set data value: Set "field_domain_copy" using value for "field_domain".

Views -> Create -> Content -> Content type Contextual Filter -> Content:domain (field_domain) -> When filter not available provide default value. Select PHP, enter this code:

$node = menu_get_object();
return $node->field_domain_copy['und'][0]['value'];

Filter -> Content:Type -> select content type to display if appropriate

So in effect, although comparing the value for the same field wasn't working for me, for some reason, comparing the actual value from a different field works fine. No idea why this is, whether it is a problem with my individual build or more widespread, but in case anyone finds the same problem, you can try this workaround.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.