other modules cannot access <hidden> CCK fields

I've just tested it together with the latest token module and it's working fine!?
Are you using the latest CCK module and token module or a custom php snippet?

with which cck field you tried it?

I'd say it depends on the way these 'other modules' try to access the information.

If a field is marked 'Hidden' in the 'display fields' tab, then its 'output' (formatted) value won't be computed (saved unneeded processing time), and therefore is not available in $node->field_name[delta]['view'] nor $node->content['field_name]['#value'].

But the 'raw' value is in $node->field_name[delta], and modules can still call content_format to display the value for the formatter of their choice.

I think, best this would be fixed in CCK's token integration, which is part of the token module.
Perhaps we can detect hidden fields here and use content format instead or we find an even better solution...

Just want to add that when using auto_nodetitle, which uses the token module, any fields that are set to <hidden> cannot be used in the title. The simply never appear.

Me, too!

When I have a CCK field set to under the Label, Teaser, and Full columns of admin/content/types/contentTyle/display, its contents do not show up in a site search.

If I reset the display settings to default and reindex, they do show up.

I need this because this particular CCK type exists to store and present a PDF. I used a PDF to text converter to get a plain text export of the PDF and stuck it in a plain CCK text field with 10 rows. I want the search to key off this hidden text field.

I am running the latest Drupal and CCK as of now.

Correction: it does not seem logical that token has anything to do with search results directly against a CCK field. I will open up a separate bug in CCK if the one referenced above does not seem to match.

Hey all, I'm having some difficulties with token/CCK fields as well. With text fields, the fix is to simply use the raw field value per yched's suggestion above. Instead of field_foo-formatted, use field_foo-raw.

This fix does not work for nodereference fields (and possibly other field types too) because there is no raw view. From token_cck.inc:

<?php
  function nodereference_token_values($type, $object = NULL, $options = array()) {
    if ($type == 'field') {
      $item = $object[0];

      $tokens['nid']   = $item['nid'];
      $tokens['title'] = strip_tags($item['view']);
      $tokens['link']  = $item['view'];

      return $tokens;
    }
  }
?>

If the field is not 'viewable', the only value being returned here is $tokens['nid'], because title and link both rely on $item['view']. Do we need another database query in here to find the title?

Okay... I'm pretty sure this is the wrong way to do this, but I'm putting it out here because a) it works and b) somebody can correct my thinking. This patch adds a field_foo-raw token to nodereference fields to return the node title. I just stuck a node_load() in the nodereference_token_values() function which is likely too much overhead (?).

I much prefer fago's solution from 7:

Perhaps we can detect hidden fields here and use content format instead or we find an even better solution...

The reason I prefer it is because using the raw token may create an XSS vulnerability - please be sure that whichever module is using these tokens does its own filtering!

We probably need to address the lack of -raw for nodereference as well, though.

XSS should be prevented on the input side--i.e., Drupal shouldn't allow XSS code to be unintentionally added to the database. But if someone has a level of trust that allows him to input unfiltered code, then it's his own fault (or the site administrator's fault for giving him that level of access) if the site has an XSS vulnerability.

Given that, I hope that a fear of XSS wouldn't prevent this feature from working. As long as Drupal properly prevents XSS on the input side, then there should be no reason for XSS to happen when using the raw token.

@Aren Cambre - that is not the standard that Drupal follows. See the Writing Secure Code section of the handbook http://drupal.org/writing-secure-code Drupal´s standard is to filter on output, not input.

Since fago´s idea from #7 is filtered and allows the hidden fields to be rendered I see no reason to jump to the conclusion that fear of XSS will prevent this feature. Features must be implemented functionally and safely.

OK, I see what you mean. I guess you can filter on input and/or output, and it should be OK if either is practiced reliably.

I believe I have similar problem in that the Search module doesn't seem to be indexing CCK fields set to "hidden" (I had been bringing in those fields using a different template specifically written for that node type).

My work-around was to simply display those fields under "display fields" and then hide them using display:none in CSS which seems to have worked.

It bugs me in that it's not a particularly semantic solution, but it'll have to do for now.

This should probably be in 6.x where it's up to the different cck modules to fix it. I've forgetting anything I may have learned about this issue :/

see #310219: Extensible display contexts for a possible solution.
(+ removing CNW status, for the patch in #11 is not a real fix)

#310219: Extensible display contexts was included in CCK a long time ago. Clearing issue from the queue.