I have a view that lists a specified content type based on a Contextual filter that is numeric (List Stories on Page X) . On its own it seems to work fine based on the Preview.
I'm attempting to use that view as a field in another view (List Pages with Stories). I've put the view at the end of the field list to get the desired field as a Replacement Pattern. However, no matter what value I use ([field_page_number], [!field_page_number], [%field_page_number]) the field only outputs the title, "View:". I've tried using both the Block and Embed displays for the child view.
However, if I manually put a Contextual filter in (all, 1, 2, 3, etc), then the child View shows up as expected. I also have the child view set to display "No results found" if there isn't a valid filter so if any of the token variables weren't right, I would've expected to see that.
I found issue #1439672: Argument tokens are shown but not used, but I am using Views Field View 7.x-1.0 which looks like it already contains the fixes from that issue.
Additional Details: Drupal 7.15, Views 7.x-3.5
Any ideas? Am I doing something wrong or is this another bug? Thanks in advance.
| Comment | File | Size | Author |
|---|---|---|---|
| #14 | 1815000-14-views-replacement-token-type.patch | 1003 bytes | MorinLuc0 |
| list-stories-on-page-x.txt | 5.63 KB | cmarcera | |
| view_pages_with_stories.txt | 4.84 KB | cmarcera | |
| vfv-replacements.png | 34.8 KB | cmarcera |
Comments
Comment #1
cmarcera commentedAdditional Info from more testing:
I wanted to see if it was my content field that wasn't providing the right data, so I instead used the "Global: View result counter" which simply returns the number of the row I'm on. Using the field "[!counter]", I still get a blank result.
Comment #2
luksakI am having the same issue. Did you find a solution to this?
Changing the priority since i think this is about the main functionality of this module.
Comment #3
luksakComment #4
damiankloip commentedI guess a key piece of information here is that the fields you are trying to get the token for is a field api field?
Comment #5
luksakThat is true. In my case I am trying to use the nid. I tried these tokens: "[!nid]" and "[%nid]" I resolved it by just using "nid".
Comment #6
damiankloip commentedI don't think you are using a field api field with an alias of nid :) I think this is just the regular node:nid property :) I think @cam815's issue may be to do with fields though...
Comment #7
luksakNo i am not :) But why am I then not able to use the token replacements displayed? I have had this issue with fields as well. I think the token replacement inside views_field_view_handler_field_view::get_token_value() is not working properly. The code on Line 479 seems top be wrong:
$view->field[$arg]Comment #8
damiankloip commentedHow do you think this is wrong? This is using the value passed from the token, to then grab the appropriate field.
Comment #9
luksakWell, I expect the listed tokens to work like [!nid] and [%nid]. But they don't. Instead I have to use nid.
Comment #10
damiankloip commentedThat's not really what I asked. Usually they do work like that, so there could be a bug here.
Comment #11
luksakYes, I also think it is a bug. I don't remember the details anymore, but debugging the data going through that function looked wrong.
Comment #12
cmarcera commentedJust checking back in here - I was not able to resolve this issue and ended up using the Views PHP module to call the View instead:
print views_embed_view( 'list_stories_on_page_x', 'embed_1', $date, $page );I can revisit this if it'll help resolve the issue.
Comment #13
tmckeown commentedI can comfirm that dates passed as arguments to view field views are still an issue. #12 worked for me.
Comment #14
MorinLuc0 commentedI came across a scenario where the token replacement patterns was replacing static text. In my case I was passing in unique UUID and the replacement function would sometimes replace the UUID with the parameters being passed into the view.
[!nid]/1b845c06-ee7f-4e25-9cf3-5ce222206c1c <---- This would be replaced.
[!nid]/474a5042-885a-48bd-b2e2-dc40bbfb1337 <---- This would not be replaced.
After some trouble shooting I found the issue could be fixed by performing a check on the token type. I am not sure if there was a reason it was not being checked in the first place but here is a patch to fix that problem if anyone comes across this issue also.
Comment #15
vladimirausThank you for your contributions.
Drupal 7 is no longer supported.
Closing the issue.