[Calendar Views] Replacement patterns don't work if referencing a field excluded from display

This is already fixed in -dev.

Also, active (needs more info) is used to indicate that the issue queue maintainers need info from the poster, so setting your issue to this status can cause it to be ignored.

Thanks for your help. I cleared my cache, uninstalled the old views (using uninstall then removing the views dir), rebuilt menus (not that I think I'd have to for this), then updated to the latest dev version of views...but I still have the same problem. Please see the attached screenshots. Thanks.

What, you didn't think the fact that you're using a calendar style was relevant?

Especially with this in the release notes:

A minor change in the API now requires that styles that render fields MUST
render them in order, first by row and then by field ID. Not doing so will
cause the token expansion to fail.

Please doublecheck this problem in a core Views style. If it doesn't appear there, then it's not a Views bug, and you should refile against calendar.

Please see the above posts...

kcolbe: which version of PHP are you using?
Probably duplicate of: #442768: Replacement pattern [nid] doesn't work on PHP4

Im using 5.2.6

I've encountered exactly the same issue as original post -
I see a field disappears from output by replacement patterns if is checked "Exclude from display" with all the latest -dev versions:

Calendar 6.x-2.x-dev 2009-Jul-29
Views 6.x-2.x-dev 2009-Jul-27
Token 6.x-1.x-dev 2009-Jul-21
PHP 5.2.9
MySQL 5.0.67

Reopening. Also, raising priority because it makes calendar.module 99% useless for any of my sites.

Patch is attached against Calendar 6.x-2.x-dev 2009-Jul-29.

I traced the problem to function template_preprocess_calendar() in theme/theme.inc. It erases the 'exclude'd field on the first pass through the fields. That makes the field not available for the subsequent replacement patterns in other fields. The patch changes it to two-pass, with 'exclude' in the second pass.

That fixes the problem for me. Please review for commit to -dev.

I was uneasy about #1 by merlinofchaos, stating that it was already fixed in -dev, so I kept looking at the code in question, trying to understand why the fix I did actually makes a difference.

I noticed that there is a call to drupal_clone() used to create $copy that is passed to $field->theme($copy). I recognize the intent to operate on object's copy, so unset() that is called on the target 'exclude'd field will not affect pattern replacement. Should be working without my patch... Hm.

However, I followed into drupal_clone(), which in turn calls PHP 5 clone. Its doc page mentions (see http://us3.php.net/clone) "When an object is cloned, PHP 5 will perform a shallow copy of all of the object's properties. Any properties that are references to other variables, will remain references.". Maybe that was the culprit of the original code not working. If the fields are references, then unsetting it may affect the original.

I didn't have enough time to dig into that too much, but I can re-confirm the fact that the above patch indeed fixes the problem. If I remove the patch, the problem returns.

The patch works for me. Thanks a lot.

For clarification (at least I didn't get that at first), the patch is to be applied against theme.inc in the mentioned calendar package.

This patch works for me, and I need it. :-) Nice work, iva2k.

Confirmed too. Patch #10 works.

great... #10 works also for me :-) Thank you so much!

Note: Marked #540388: rewrite fields do not show if field is set to exclude as a duplicate of this issue

I can also confirm the #10 patch works.

I confirm too, the #10 patch work for me, please integrate it on the release/dev.
many thanks iva2k.

Thanks a million, iva2k. I appreciate the research into php5's object cloning behavior.

The patch at #10 does the trick for me (using Calendar 6.x-2.2 release).