I created a new calendar view by copying the default calendar view.
After making all the changes I wanted and tested that it worked properly, I exported the view.
I then deleted the view I just exported and then imported it.

After the import, I began getting the following error messages from the month, week, day, and year displays.
Notice: Undefined index: year in template_preprocess_date_views_pager() (line 151 of /var/www/html/sites/all/modules/date/date_views/theme/theme.inc)
With year being replaced by the equivalent name for each display.

If I change the page from "Page by date" to something else the error goes away and also comes back when I change the pager back to "Page by date".
All of the settings in the view look correct.

I am using Date 7.x-2.x-dev (2011-Jul-29)
(I am using views 7.x-3.x this time and not 7.x-2.x as I had done in my previous bug report)

Comments

timwoolsey’s picture

I also have this issue. It only appears when I add an external taxonomy filter.

paranormals’s picture

I also get this error when adding an external taxonomy filter.

karens’s picture

Status: Active » Fixed

I cannot replicate any problem in the latest code. Make sure you have the latest dev of Date, Calendar, Views, and CTools since there have been changes to the way exporting works in later versions of Views and CTools.

I have no idea what an 'external' taxonomy filter is. I know what a taxonomy filter is and that works.

paranormals’s picture

Status: Fixed » Active

I am on the latest version of Drupal and the latest dev versions of Date, Calendar, Views and CTools modules as of today and am still seeing this issue. When I add a taxonomy filter I start to get the error described on each page of the view. In this case.. the week view... "Notice: Undefined index: week in template_preprocess_date_views_pager() (line 151 of /Applications/MAMP/Sites/local7/sites/all/modules/date/date_views/theme/theme.inc)."

I should mention mine is not an imported view as the original poster and is a clone of the default calendar view provided with the latest version of Calendar.

I wonder if its conflict with another module? I am seeing an issue with trying to add legend coloring also. I will add an appropriate thread here in a minute for if I dont find a current one.

Thanks

paranormals’s picture

I did a clean install of D7.7 with the dev versions of the 4 modules from yesterday and still see this warning when adding an taxonomy filter (term) "Taxonomy term: Vocabulary (exposed)" to the calendar view.

mcauley.16’s picture

I also have a new core install of 7.7 from a few days ago, all dev versions of the four modules, and yet I get the same message when adding an exposed taxonomy filter.

pepe roni’s picture

I have the same problem. It applies to taxonomy term fields (content: term name) also if the filter is exposed. If it is not exposed, the notice does not occur. You don't need to add a taxonomy term relationship!

yareckon’s picture

Subscribe. Also affected here as of 5 mins ago.

drush dl ctools-7.x-1.x-dev date-7.x-2.x-dev calendar-7.x-3.x-dev views-7.x-3.x-dev

Take any date pager view and add a taxonomy term exposed filter to it and you get the error.

The code around there is:

  if (!empty($input)) {
    $id = $plugin->options['date_id'];
    $view->args[$pos] = $input[$id];
  }

$id is declared to be the user entered pager identifier. By default it is 'date'.

Looks like these lines throw an error, because $input here is not any pager input, but the exposed filter taxonomy input, so there is no $input[$id]. , just $input['field_my_taxonomy_term'].

Looks like this code is either assuming 1) that the pager argument gets passed into $input ( which it doesn't ),or 2) is handling a strange case where there is both a pager and a date exposed filter.

Maybe then:

  if (!empty($input)) {
    $id = $plugin->options['date_id'];
    if (isset ($input[$id])) {
        $view->args[$pos] = $input[$id];
    }
  }

If 1) the code needs to do something else, cause the pager arguments are not in $input at all.

yareckon’s picture

Title: Undefined index for page date identifier on imported calendar views » Date pager throws undefined index notice with exposed filters in template_preprocess_date_views_pager()

changing title

WorldsEndless’s picture

Same problem.

pbirk’s picture

Also experiencing issue. Followed steps at http://drupal.org/node/755312 to no avail.

Issue only appears when exposing a taxonomy filter. Removing the filter or removing the "Page by date" pager clears the error.

Using all latest versions of -dev:
ctools 7.x-1.x-dev
date 7.x-2.x-dev
calendar 7.x-3.x-dev
views 7.x-3.x-dev

karens’s picture

Status: Active » Fixed

OK, I think I figured this out. It is actually a Date issue. The pager is assuming that the $input passed to it by Views is its own $input, but it contains input for other filters as well. This needs a test to be sure the Date value is available in the input.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

finn lewis’s picture

This appears to be fixed in the latest dev release of Date 7.x-2.x-dev (2011-Sep-08)

Kabokey’s picture

Is there any way how we can manually fix this problem?

cesabal’s picture

This issue is not fixed in the 7.x-2.x-dev version becouse i have this version and i have the same problem, but karen have a reason it is a issue of date module.

cesabal’s picture

Project: Calendar » Date
Version: 7.x-3.x-dev » 7.x-2.x-dev
Component: Miscellaneous » Views Filter
cesabal’s picture

Status: Closed (fixed) » Needs review
sandwormblues’s picture

I've got the exact same problem in date 7.x-2.0-alpha4

jfaldmo’s picture

Has a solution been posted for this? How do you "upgrade" to the dev version? Since I have the alpha version, when I try to install it it says that Date is already installed.

karens’s picture

Status: Needs review » Fixed

It is fixed in the dev version. To upgrade to the dev version you just switch in the code from the dev version instead of whatever you are using now.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.