Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
While previewing a services display, the values of custom fields in the array output is inappropriate. It displays the node id value instead of the actual value of the field. See attached screenshot.
This is not the case with predefined fields like title, body, published date, etc. It's a critical issue as it makes it difficult to preview the view you are developing.
Comment | File | Size | Author |
---|---|---|---|
drupal_services_views_preview_bug.png | 236.42 KB | dayson |
Comments
Comment #1
ygerasimov CreditAttribution: ygerasimov commentedYou are completely right. I have implemented displaying output same was as it is handled by services. So now preview should work better.
Please test and reopen this issue if you still have any problems.
Comment #2
RogerRogers CreditAttribution: RogerRogers commentedI just tested for both dev and beta versions and this is still a problem. I setup a service view and try to add a description field but the output title is 'nid' and value is the nid.
Comment #3
ygerasimov CreditAttribution: ygerasimov commented@RogerRogers please advise the type of the description field. Also what formatter do you use in your Services display?
Comment #4
grasmash CreditAttribution: grasmash commentedI'm also experiencing this issue with many field types, including: taxonomy terms, body field, phone, addressfield, etc.
It looks like the Views query is wrong:
The non-working fields are simply selected as 'node' rather than node.field_name.
Comment #5
grasmash CreditAttribution: grasmash commentedThis actually appears to be fixed in the latest dev.
Comment #6
mototribe CreditAttribution: mototribe commentedthe dev version fixed this problem for me as well. Thanks!
Comment #7
ygerasimov CreditAttribution: ygerasimov commentedComment #8
mototribe CreditAttribution: mototribe commentedI came across another bug with the dev version that seems to confirm the original issue:
when I set a "custom value key" and the value starts with a lowercase character it will just show the nid value in the output.
When I change it to start in uppercase it works correctly. Took me lots of trial and error to find that one ;-)
I also noticed that when you add the field "Comment Count" it always uses the value key "node_comment_statistics_comment_count", even when it's set manually.
Cheers
Comment #9
ygerasimov CreditAttribution: ygerasimov commented@mototribe can you advise what field, what formatter you get this problem? I am trying to reproduce the situation with node's body field but everything works fine.
Comment #10
mototribe CreditAttribution: mototribe commentedI have a field "model_id" added to a vocabulary.
When I create a view of to show "term tid" and "model_id" it will show the tid value instead of the model_id.
When I change the label to "Model_id" it will show the correct value.
Comment #11
skyredwangConfirmed this bug with Content: All taxonomy terms (terms)
If the custom value key is set to "terms", then the output is the value of nid.
If no custom value key, then the label of the "All taxonomy terms (terms)" is called "nid", and the value is nid as well
Comment #12
eliasdc CreditAttribution: eliasdc commentedI can confirm that with the latest 7.x-1.x-dev the preview works for services views, except for field Content: All taxonomy terms (terms).
When using "Content: All taxonomy terms (terms)" with a lower case custom value key the label is correct in preview and the service. But the value is still the nid of the node in the request and in preview. I would like to have a comma separated simple list of all taxonomy terms (custom text is not working in services display).
Comment #13
matt2000 CreditAttribution: matt2000 commentedThis bit me today, and the dev release fixed it. Can we get a new beta release?
Comment #14
jbeuckm CreditAttribution: jbeuckm commentedSame as what matt2000 said in #13. 5/13/13 + 8/13/13 = 13/13/13! new beta?
Comment #15
kylebrowning CreditAttribution: kylebrowning commented