[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.

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.

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

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).

nag nag

Also can confirm that patch in #10 works.

Same problem, #10 works. Thanks!

#10 Worked here.

worked for me

Patch works for me.

Please commit!

Works fine for me, too.

subscribing

subscribing

subscribing

According to http://drupal.org/node/156119, "patch (to be ported)" has the following defenition:

The patch has been successfully committed to a branch of the project, and still needs to be committed to another, but the current patch doesn't apply to the target branch and needs to be modified in order to do so.

So to be marked "patch (to be ported)," the patch first must be committed to the 6.x-2.x-dev branch.
THEN, if there is interest in applying the same patch to another branch (like the 5.x-2.x-dev or 7.x-1.x-dev) it should be marked as "patch (to be ported)"

Patch #10 was against an older -dev (2009-Jul-29.) version. Does anyone know if it works against the current -dev (2010-Aug-22) ?

Sorry but my comment didn't post with #34. So here is the message...

Patch #10 works against the current calendar-6.x-2.x-dev (2010-Aug-22) file but had a redundant foreach loop at end. The conditions just needed to be rearranged with in the same foreach. Attached is the updated version of the patch in #10 for review and verification.

subscribing...

[#34] works for me and is very helpful. Please submit to the main code line!

[34] works for me as well and is very helpful too.

I'd also like to see this commited to the main code line.

Thank your for you work!

#34 works for me too.

[34] This patch worked for me, but it seemed to re-create this issue: https://drupal.org/node/575532. Now that I have added the Node ID to the view (excluded from display but used in rewriting the output as a link to event/[nid]), I only have one event appearing per month. Anyone else have this problem?

I committed #34. Please start a followup issue if there is some problem with using nid.

#34 working fine for me and i didn't had the bug of #40.
definitely it should be applied.
thanks