There's an edge case where the truncation of long field aliases in Views (committed to 3, and on it's way in 2) is causing some of the code in template_preprocess_calendar() not to work any more.
http://drupal.org/node/571548

The $calendar_fields variable seems to get the untruncated aliases, but is checked against the $view->result[n] keys which are the truncated aliases. So all fields are rejected as being non-calendar fields in if (in_array($key, $calendar_fields)) {

  // Render each field into an output array. We have to do the rendering
  // here because we don't apppear to have full access to the view 
  // handlers in the theme functions.
  $items = array();
  $calendar_fields = date_api_fields($view->base_table);
  $calendar_fields = array_keys($calendar_fields['alias']);
  
  foreach ($result as $num => $row) {
    $copy = drupal_clone($row);
    $items[$num] = $row;
    $items[$num]->raw = $copy;
    $items[$num]->calendar_fields = new stdClass();
    
    foreach ($row as $key => $value) {
      if (in_array($key, $calendar_fields)) {
        $items[$num]->calendar_fields->$key = $value;
      }
    }

This also impacts on calendar-6.x-2.4 when used with views 3.
This is a far more common issue in Drupal 7.x with the length of aliases growing exponentially due to the field api.

CommentFileSizeAuthor
#18 calendar-alias_truncation-1038486.patch1.17 KBhnln
#8 calendar-7.x-2.x-dev-truncate-alias.patch1.94 KBlarowlan

Comments

jm.federico’s picture

jm.federico commented

#1043476: Calendar not showing any events is a dup of this one

hnln’s picture

hnln commented

sub

muhleder’s picture

muhleder commented

If two $keys share the same truncated name, they have a '_1', '_2' etc added.

I'd guess we'd need to grab the piece of views code that does the truncation naming, and use that on each value in the $calendar_fields array. Hopefully it's a function we can test for the existence of, and then use, rather than copying and pasting code?

hnln’s picture

hnln commented

Doesn't look like there is an easy function to grab from views, but the view query object does hold all the fields with a reference to the original cck field name, so when using above $row => $key, $key should somehow be matched to the orginal field through the query fields array ?

Shouldn't this be marked as critical since this views patch will also make it's way into views 2 and thus make all calendar with long field names unusable.

muhleder’s picture

muhleder commented

You're probably right about it being critical.

I wonder if we could get a change into views that would allow us to support both both the truncated and non-truncated versions of views.

There seem to have been a few other people running into the same issue, and there are some patches in the queue at
http://drupal.org/node/571548
regarding this.

jm.federico’s picture

jm.federico commented
Priority: Normal » Critical

Marking as critical

ayukko’s picture

ayukko commented

Subscribe

larowlan’s picture

larowlan
Location 🇦🇺🏝.au GMT+10
commented
Version: 6.x-2.4 » 7.x-2.x-dev
Status: Active » Needs review
Issue tags: +Needs backport to D6
StatusFileSize
new calendar-7.x-2.x-dev-truncate-alias.patch1.94 KB

This also impacts on 7.x-2.x-dev.
Here's the patch for that - tagging as needs backport to 6.x

karens’s picture

karens commented
Version: 7.x-2.x-dev » 7.x-3.x-dev
Status: Needs review » Needs work

This needs to be adjusted for the 7.3 version of calendar, I am making no more changes to 7.2.

I tried to see what needs to be changed in 7.3 but couldn't figure it out.

gribnif’s picture

gribnif commented

The patch in #8 will not work 100% of the time, and in fact doesn't for my own tests. That's because the current views beta not only truncates the aliases, it keeps track of which ones have already been used and adds a counter to the end if the truncated version is used more than once. Therefore, any patch to calendar cannot simply truncate, it has to take the counter into account--something which is impossible to do properly at this point in the code.

IMHO, either views needs to include a function call that can be used to query the remapping, or some other, deterministic method of calculating the truncated name needs to be worked out.

El Bandito’s picture

El Bandito commented

I've hit this problem with Calendar 6.x-2.4 and Views 6.x-3.0-rc1. My CCK have names like "field_task_target_dates". Is there a safe length for the field names that will avoid the truncation problem ?

Thanks

El Bandito’s picture

El Bandito commented

To possibly answer my own question this post http://drupal.org/node/1043476#comment-4024170 suggests that 19 characters for the field length is the critical length.

karens’s picture

karens commented
Status: Needs work » Active

We have a patch for D6 in a D7 issue. That's going to confuse the heck out of people. The comment about the patch not working all the time is odd, because the patch is totally unusable in D7, so I'm guessing that comment is referring to D6 even though this issue was already marked as a D7 issue.

We need a completely different patch for D7, so this is 'active', not 'needs work'.

I have no idea how to solve this problem at the moment.

karens’s picture

karens commented
Status: Active » Postponed (maintainer needs more info)

I'm actually having trouble re-creating any problem. The maximum length for a field name is 32 characters, so I created a field name that long. The maximum length for a content type name is also 32 characters. Put them together and the maximum length for an alias is 65 characters (32 + 32 + the period). I agree that long field names can be common, but it seems like it would be much less common to have excessively long content type names, and the maximum field name length would not get truncated unless the content type name was also excessively long.

It looks like Views only truncates when the alias is over 60 characters long. And so far I can't get anything set up locally that breaks, even when using a 32 character field name and a 32 character content type name, even with the latest dev version of Views.

I guess I need more information on how to replicate the problem.

karens’s picture

karens commented
Priority: Critical » Major

I'm going to downgrade an edge case that I can't replicate. If someone can provide steps to recreate in D7 and I can replicate it we can upgrade the status.

karens’s picture

karens commented
Status: Postponed (maintainer needs more info) » Closed (cannot reproduce)

No response, assuming fixed.

terbs’s picture

terbs commented

This is still a critical error in calendar 6.x-2.4. I just spent 3 days trying to figure out why certain date fields were showing and others weren't. I finally popped open the stack and traced the views result only to discover this same bug. The supplied patch did fix the problem, it would be super if that patch could be committed or at least rolled into the dev version. This was a super aggravating bug that most people won't be able to solve on their own. I'm going to go ahead and make a new issue for d6 and attach this patch.

hnln’s picture

hnln commented
Status: Closed (cannot reproduce) » Active
StatusFileSize
new calendar-alias_truncation-1038486.patch1.17 KB

Problem still persists for me as well in 6.x, attached my go at a patch, it's different as the patch in #8 as it loops the view's query fields to check if there are any truncated aliases and then updates $items[$num]->calendar_fields accordingly. This is a patch against the latest 6.x-2.x-dev for multiday (as that is where I had the problem).

Not sure if I should change the issue number.

Encarte’s picture

Encarte commented
Status: Active » Needs review

Patch in #18 against 6.x-2.x-dev

karens’s picture

karens commented
Status: Needs review » Closed (cannot reproduce)

This was changed to a D7 issue and closed because it cannot be reproduced in D7. Sticking a D6 patch on this issue and re-opening it is just confusing to everyone. I'm not going to review a D6 patch on a D7 issue.

terbs’s picture

terbs commented

Here's the related Drupal 6 issue: http://drupal.org/node/1469158

terbs’s picture

terbs commented
Issue summary: View changes

Added summary