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.
Hi,
In calendar views, the first field seems to always be displayed event if "Exclude from display" is checked.
Steps to reproduce the issue:
- Create a calendar view from template at admin/structure/views/add-template
- Add a field—I added a body field—and exclude it from display
- Rearrange the view: place excluded field in first position
- Preview or view the result: first field is displayed
Comments
Comment #1
Pomliane CreditAttribution: Pomliane commentedThe issue seems worse: the described behaviour in #1 seems to occur at any position except the last one.
There's also an odd behaviour for fields following the one which is hidden: when a long text field is checked to be excluded, all following fields are hidden but, if it's a nid field, they're not...
Comment #2
KarenS CreditAttribution: KarenS commentedSomething else is going on here, I cannot replicate this at all. Try again using the latest versions of both Date and Calendar. Also be sure you have the very latest version of Views. Finally be sure you clear your caches, including the Views cache (the Views cache clear is on the 'Tools' tab of Views.
Seeing a field you didn't expect to see is not a major bug that makes the code unusable. And I suspect this is actually a support question and not a bug at all because it is working fine for me.
Comment #3
Pomliane CreditAttribution: Pomliane commentedI'm using date-7.x-2.5, calendar-7.x-3.1 and views-7.x-3.3.
The calendar was functional until today's combined calendar + views updates.
The excluded trimmed body field was originally rewritten in a tooltip title attribute so it's not exactly critical but any advanced usage of fields in a calendar seems a bit compromised—at least on this install.
Not sure it's important but the site is multilingual.
Attached is an export of a curated version of the view with the same issue.
Comment #4
smalltalkman CreditAttribution: smalltalkman commentedI have the same problem: cannot exclude the date or any other field. Order does not matter. The label does not display properly.
The day page works fine. Month and week always display the date and do not display labels.
Calendar 7.x-3.2 Date 7.x-2.5 Views 7.x-3.3
only multi-day was a problem
Comment #5
KarenS CreditAttribution: KarenS commentedThe only place I see a problem is on the multiday rows, all other cells are rendered exactly as they should be. I fixed the problem on multiday rows in my commit to get Colorbox working.
You can't do a lot of advanced styling on the multiday rows, but all others defer completely to do whatever Views wants to do -- they will display exactly the same as if you displayed them in a table or list or any other type of display. I added a checkbox to allow you to choose which fields should be excluded on multiday rows so you can omit any that don't work right in the multiday format.
I just made this commit, so you'll need to have the latest dev code that contains it, which should be in the dev tarball tomorrow.
If there is a problem after that, I need steps to reproduce, because it's working fine for me.
Comment #6
heatherwoz CreditAttribution: heatherwoz commentedMake sure you clear your caches! I just upgraded to 7.x-3.3 and all my fields that were excluded from display were showing. I tried a number of things to fix it, but nothing worked til I cleared ALL my caches.
Comment #7
tjerkdekuijper CreditAttribution: tjerkdekuijper commentedI fixed this issue by changing line 540 in theme/theme.inc
in this:
Firstly I copied the entire calendar_preprocess_calendar_item function to my own template.php
Comment #8
jiisuominen CreditAttribution: jiisuominen commentedI can confirm both the problem, and the fix as in #7.
Calendar 7.x-3.4
Views 7.x-3.7
Comment #9
rbrownellI too am having the same problem. I can also confirm that #7 is fixing the problem for me.
Comment #10
Echofive CreditAttribution: Echofive commentedHello,
I too am having the same problem.
I can also confirm that #7 is fixing the problem for me.
I add a patch to do it properly...
Comment #11
skaduI was experiencing the same issue, the fix in #7 and the provided patch in #10 appear to fix the issue for me.
Thanks all.
Comment #12
hwasem CreditAttribution: hwasem commentedI can confirm this was an issue for us. We had multiday events with fields listed twice in the field list, but one instance was excluded. The hidden field was showing on the calendar.
We are using Colorbox to display the hidden field.
Patch in #10 and cache flush fixed the problem.
We are on:
Colorbox 7.x-2.9
Calendar 7.x-3.5
Date 7.x-2.9
Views 7.x-3.11
Comment #13
ron_s CreditAttribution: ron_s commentedWe found this issue on our own and solved it exactly as the patch in #10.
The reason why this problem seems to happen "intermittently" is it's dependent on having two fields with the same field name on the same view.
The way this can be replicated is add "
nid
" twice as a field on a calendar view. This is a common occurrence if needing to reference the content type on which the view is based, plus a referenced entity via relationships. For our use case, an additional step is enter the Style options settings (Format: Calendar | Settings), and select both "nid
" checkboxes in "Fields to hide in Multi-day rows". Bothnid
's should be hidden from view, but one is displayed.In the view, the fields will be stored as "
nid
" and "nid_1
". The problem with using$field->field
as the name to unset the rendered field is it's always going to be the actual name, which in this case is "nid
". The value stored in$vars['rendered_fields']
references the Views field name ("nid_1
") and not the actual field name ("nid
").Using
$id
, which references the name stored with the view, fixes this problem.Comment #14
lily.yan CreditAttribution: lily.yan commentedI found this issue on my own. I can also confirm that #7 is fixing the problem for me. I tried to apply a patch in #10, but got error. I made exactly the same change and created a new patch. Thus I am able to do it properly to solve my issue.
Comment #15
ron_s CreditAttribution: ron_s commented@lily.yan, the patch you created is identical to #10, other than your version doesn't include the "index" line. I don't see a reason why another patch is necessary.
Are you sure you are applying the patch to 7.x-3.x-dev? It cannot be applied to the release version of the module.
Comment #16
lily.yan CreditAttribution: lily.yan commented@ron_s,
Yes, I am sure that I am applying the patch in #10 to 7.x-3.x(aafe5ae), and I am getting errors (error: patch failed: theme/theme.inc:540 and error: theme/theme.inc: patch does not apply). I also compared the difference between #10 and #14.
#14 has 'index 82fb5fb..e12b350 100644' and #10 doesn't have.
#14 has '@@ -540,7 +540,7 @@ function template_preprocess_calendar_item(&$vars) {',
but #10 has '@@ -540,7 +540,7 @@'.
I applied the patch in #14 to 7.x-3.x(aafe5ae) successfully.
Thanks
Comment #17
kpaxman CreditAttribution: kpaxman commentedI can confirm that the patch in #10 does not apply to the latest 7.x-3.x.
Steps to reproduce:
The result of the attempt to apply the patch:
Comment #18
kpaxman CreditAttribution: kpaxman commentedReroll of patch from #10 against latest 7.x-3.x dev is attached.
Comment #19
ron_s CreditAttribution: ron_s commentedJust tested, and patch #10 still works against the latest 7.x-3.x-dev. But if re-rolling makes some difference for you... makes no difference to me.
Comment #20
kpaxman CreditAttribution: kpaxman commented@ron_s How are you applying the patch? I'm following the official instructions, as noted in my comment, and getting an error message, which is why I rerolled.
Of course, if we could just get this patch into the module all would be moot. :)
Comment #21
ron_s CreditAttribution: ron_s commented@kpaxman, there are multiple ways to patch. If you look at the "official instructions" (https://www.drupal.org/patch/apply), the method you chose is not the only option.
It works for me both from the command line, and applying the patch directly from the IDE:
Comment #22
kpaxman CreditAttribution: kpaxman commented@ron_s Ah, I was looking here - https://www.drupal.org/project/calendar/git-instructions - which only lists the method I used.
Comment #23
wylbur CreditAttribution: wylbur commentedComment #25
Neslee Canil PintoCommitted, Thanks.