I've come across an odd problem where if I don't display the node->nid, nodes will be dropped from the calendar page view.

Actual display of each calendar item is done via some PHP code in a Customfield; as I need to have some node types displayed as links and some not.

I've worked around it by adding a views theme override for the nid field as follows:

<span style='display: none';><?php print $output; ?></span>

That works, but makes Views output horribly invalid HTML, so it's not ideal.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

drupal_jon’s picture

Can confirm the same issue as soon as nid is added as a field but excluded. Resorted to CSS for now as well.

MBroberg’s picture

Me too.
When NID is not in the field list, I can see all of the events.
When NID is a displayed field I can see all of the events.
When NID is in the list but excluded, I cannot see some of the events and it seems random.

I can't figure out a pattern. Some events have a start but no end date, some have both.
Some have repeat rules, some do not. Some are the first instance and some are recurring. In each case I see certain ones and not others.

This happens in week view and month view - not tested on other views yet.

ericfaucon’s picture

I have that problem too.
All my events have a date with day granularity.
Displaying the Nid is ok, but as soon as I exclude it from display, I only have one event displayed, based on the sort criteria.
Running the query in MySQL returns ALL the results.

penguin25’s picture

Title: Items from from calendar page view when nid field hidden from display » Items missing from calendar page view when nid field hidden from display
FileSize
1.02 KB

I'm suffering from the same problem: items are missing from the calendar if the nid is excluded from the display.

I've done a bit of investigation, and discovered that the items are dropped in includes/calendar.inc, and the relevant lines of code are lines 366 and 379 (in version 6.x-2.2). A unique id for every item is set up at line 366, and then tested at line 379 to make sure that items aren't included in the calendar more than once.

The unique id is based on $item->{$view->base_field}. I don't understand Views enough to know what $view->base_field is, but in my case, it was set to 'nid' - so the unique ID was based on $item->nid. Unfortunately, $item->nid has been removed from $item because it's excluded from the display. This means every item gets the same unique ID, so the test at line 379 only passes for one item (or possibly one for each delta value if your time fields have multiple values).

I've hacked together a very quick workaround, which uses $item->raw->nid instead of $item->nid if $view->base_field=='nid'. I don't consider this to be a proper fix, but it made all the items appear in the calendar for me.

Of course, nothing is ever that simple - having got the items to appear, I then ran into another bug: #382852: [Calendar Views] Replacement patterns don't work if referencing a field excluded from display. There is a patch in comment 10 of that issue which I also had to apply to make everything work correctly.

Perhaps somebody who understands Views a bit more than I do, and knows the significance of $view->base_field, could comment further on the validity of my patch? As I said, I don't consider it to be a proper fix.

penguin25’s picture

My patch in #4 breaks ical feeds, where it seems that $item->raw->nid is not a valid value, but bizarrely, $item->nid doesn't get removed from $item (I really don't understand what's going on now!).

So I've changed my patch to add $item->raw->nid to the unique id, keeping $item->nid as well, rather than just replacing it. At least one of the two values always seems to be there, so you always get a valid unique id.

As I said before, comments from someone who understands this code base a bit more than I do would be welcome!

penguin25’s picture

Trying again ... I've got too many patch files floating around! Ignore the patch in comment 5 - it's the same as the one in comment 4 (and I can't seem to find a way to delete them).

This is definitely the patch to use. Sorry for the confusion!

mbakunas’s picture

I've applied the patches in #4 and #6, but neither fix the issue for me (on both Calendar 6.x-2.2 and 6.x-2.x-dev).

penguin25’s picture

That's interesting, and slightly disappointing :-(
Have you also applied the patch in comment 10 of #382852: [Calendar Views] Replacement patterns don't work if referencing a field excluded from display, which is needed in addition to my patch?

If so, all I can suggest is adding a bit of debug info to your installation, to see if your problem has the same root cause as mine. Try adding the following two lines to calendar/includes/calendar.inc, just after the $id variable has been written to (that's after line 368 in version 2.2 with my patch, or after line 366 in version 2.2 without my patch).

drupal_set_message($id);
drupal_set_message($item->calendar_fields->$alias);

When you reload the calendar page, you should get lines of debug info on your page as follows, two lines for each event that should appear on the calendar:

calendar:261::field_event_time:0
2010-02-03 19:00:00
calendar:259::field_event_time:0
2010-02-03 20:00:00

Basically, items will be omitted from the calendar if either:

1) Any of the lines that start with "calendar:" are repeated.
2) Any of the lines that contain a date and time are instead blank.

The problem I was seeing was that the "calendar:" lines were being repeated due to a bug I don't fully understand, so I hacked in a fix to make them unique again. If all your "calendar:" lines are unique (before my patch is applied), or items that should be being displayed are missing from this debug output, then I'm afraid you have a different problem to me, and so my patch won't help you - sorry.

mbakunas’s picture

I agree that it's slightly disappointing, but I've been looking for an excuse to dig into the guts of Drupal. ;-)

BTW, I actually found the patch in comment #10 of #382852: [Calendar Views] Replacement patterns don't work if referencing a field excluded from display before I found your patch.

Ok, so I applied the debug code, and I found a difference between my results and the results you listed. On the first line of the debug output, you have:

calendar:261::field_event_time:0

whereas I have:

calendar::field_trip_date:0

Do you know what the number represents and why it might be missing from my display?

mbakunas’s picture

I figured out the number is {$view->base_field}. Maybe the patch isn't applying correctly? I'm going to try applying the patch again.

mbakunas’s picture

While I never could get your patch to work, you did help me quite a bit. I simply used $item->raw->nid in place of $item->{$view->base_field} in line 366, and now all of my events are showing in the calendar.

Old 366:
$id = 'calendar:'. $item->{$view->base_field} .':'. $real_field .':'. $delta;

New 366:
$id = 'calendar:'. $item->raw->nid .':'. $real_field .':'. $delta;

I appreciate your help with this.

penguin25’s picture

Strange ... that's basically exactly what my patch does. Note that if you use iCal feeds, I think your change might have broken them - you need to add $item->raw->nid into the existing $id, rather than replacing $item->{$view->base_field} with $item->raw->nid. This is something I changed between the patch in comment 4 and the patch in comment 6.

My patch does include an extra sanity check that $item->{$view->base_field} is set to "nid", and only adds $item->raw->nid if it is (since I'm not clear of the purpose of $view->base_field, and I thought it might be bad to add the nid into $id if something else wasn't expecting it). Perhaps in your case $view->base_field is set to something other than "nid" for some reason, which is why my patch appeared to do nothing?

tnightingale’s picture

Struck this issue today.
Subscribing

mrtorrent’s picture

penguin25's patch at #6 works for me -- thanks

penguin25’s picture

Version: 6.x-2.2 » 6.x-2.4
Status: Active » Needs review
FileSize
1.13 KB

Updated the patch so that it applies cleanly on the 6.x-2.4 release.

I'd still appreciate any comments from anybody who might be able to explain in more detail exactly what's going on with this bug.

potassiumchloride’s picture

Having the same problem. Only one event shows up per month when I exclude nid from display. Will try the patch and post feedback.

potassiumchloride’s picture

patch in #15 worked perfectly.

felipe’s picture

#15 works for me too. Thanks.

refman1073’s picture

I have a similar problem with a table I created and consider it a base table. When the base field is excluded from display, only one calendar entry shows. After reading a lot of code I discovered that the alias for the base table's base field is not prefixed with the table name. If you look at line 703 in 6.x-2.4 you have the following:

$delta = !empty($field['delta_field']) && !empty($item->{$field['delta_field']}) ? $item->{$field['delta_field']} : 0;

The problem is that the excluded field is not in the $item object, however it is in the $item->raw object. Thus I believe the correct code should be:

$delta = !empty($field['delta_field']) && !empty($item->raw->{$field['delta_field']}) ? $item->raw->{$field['delta_field']} : 0;

This has solved my problem.

I noticed that when Node is the base table, the delta_field is not set. I believe all base tables should set the delta field to the base field. I suspect that would solve the nid issue above as well. I am not sure where that default is set.

athanor’s picture

You are right, refman1073. Your change plus one more in the line below brought back to calendar items which disappeared when I added excluded field to the calendar view.

shashankmestry’s picture

#15 works for me too . Thank you very much.

pbeakley’s picture

subscribe

alex.a’s picture

This is still an issue with 6.x-2.4.
It took me a long time to figure out that the hidden nid was causing it.
My workaround is to remove it altogether. I only needed it to display another field instead of the node title and link it to the node.

nerdoc’s picture

Is there a chance that this is fixed? Even when the patch works, we have to apply it to every new update.

WorldFallz’s picture

can confirm that patch in #20 fixes the issue.

apaderno’s picture

Version: 6.x-2.4 » 6.x-2.x-dev
Issue summary: View changes
Status: Needs review » Closed (outdated)

I am closing this issue, since it's for a Drupal version no longer supported.