Errors when using Profile 2 with Date module

same here...

I get the same php notices with slightly different field settings:
- Default display: short

The notices are also thrown on user/register

The patch fixes the problem for me too.

This actually might be a core bug, depending on your point of view -- if the field is not added to the registration form the field module still passes it to hook_field_validate.

I added a test for an empty value for now.

Might be worth investigating. Having to explicitly check this is definitely counter-intuitive.

Currently, the user registration form includes all user fields, and marks #access = FALSE on those that are not configured to appear. This does mean that field values go through validate - however, on registration form (user creation, not edition), and unless I'm mistaken, those 'values' ($items) should be just an empty array.

Or is there a default value set for the date field ?

Sorry for reopening this issue again. The problem still exists for user date fields administrated by the administrator only. When the administrator changes the values of such fields where the user is not able to look at, the message will be displayed.

I also have this bug, even with the patch installed and the latest dev module.

Subscribing, bug still exist even with patch above

and instead of

if (is_array($item)) {

what i originally have is

if (is_array($item) && !empty($item)) {

This error pops up when editing profile 2 fields and saving.

Same for me !!!

Same here. Subscribing.

Same here with any date field within profile 2.

I only get the error about the timezone though - with date granularity of MM/YYYY

Notice: Undefined index: timezone in date_field_validate() (line 311 of /../date.field.inc)
Notice: Undefined index: timezone in date_field_validate() (line 316 /../date.field.inc)

I'm getting the same error, but not with registration/profile. On a fresh install and using stable versions of Date, Calendar, & Views (among others), I created a new content type, event, and added one field, Datetime, with start and optional end. I initially set it up to use the popup calendar with repeating and then after creating one piece of content, removed the repeating (doesn't go away). I worked with Calendar to show events and then created several events. I got errors similar errors to whose below. After reading this forum, I downloaded the dev build 2/25 and tried again with 2 events. Below are the errors; looks like 3 lines for each content type. Calendar attempts to show published events with start time (datetime) greater than or equal to now() + 1 sorted by start time. Yes, it seems like something, core?, is not creating all that it needs to create.

* Notice: Undefined index: value in date_field_validate() (line 310 of /Library/WebServer/Documents/drupal-7.0/sites/all/modules/date/date.field.inc).
* Notice: Undefined index: timezone in date_field_validate() (line 310 of /Library/WebServer/Documents/drupal-7.0/sites/all/modules/date/date.field.inc).
* Notice: Undefined index: value2 in date_field_validate() (line 311 of /Library/WebServer/Documents/drupal-7.0/sites/all/modules/date/date.field.inc).
* Notice: Undefined index: value in date_field_validate() (line 310 of /Library/WebServer/Documents/drupal-7.0/sites/all/modules/date/date.field.inc).
* Notice: Undefined index: timezone in date_field_validate() (line 310 of /Library/WebServer/Documents/drupal-7.0/sites/all/modules/date/date.field.inc).
* Notice: Undefined index: value2 in date_field_validate() (line 311 of /Library/WebServer/Documents/drupal-7.0/sites/all/modules/date/date.field.inc).

I am having quite a bit of difficulty with the date module. I have a fresh install of Drupal 7. I am running the most up-to-date dev and still having problems.

I am trying to use the module, in conjunction with the registration form and Profile2. I have two date fields on my form. One is day, month and year. The other field is just collecting the year. The field that has day/month/year, has a problem capturing the right date. It is one day behind. The one that is just collecting the year, it doesn't matter what I enter, it collects 1969.

I have tried several browsers, just in case too.

I am getting the following errors, when trying to edit the profile page for the user:

•Notice: Undefined index: timezone in date_field_validate() (line 310 of /home/myuserid/public_html/sites/all/modules/date/date.field.inc).
•Notice: Undefined index: value2 in date_field_validate() (line 311 of /home/myuserid/public_html/sites/all/modules/date/date.field.inc).
•Notice: Undefined index: timezone in date_field_validate() (line 310 of /home/myuserid/public_html/sites/all/modules/date/date.field.inc).
•Notice: Undefined index: value2 in date_field_validate() (line 311 of /home/myuserid/public_html/sites/all/modules/date/date.field.inc).

and I am getting the following errors (as well) on registration:

•Notice: Undefined index: timezone in date_field_validate() (line 310 of /home/myuserid/public_html/sites/all/modules/date/date.field.inc).
•Notice: Undefined index: value2 in date_field_validate() (line 311 of /home/myuserid/public_html/sites/all/modules/date/date.field.inc).
•Notice: Undefined index: timezone in date_field_validate() (line 310 of /home/myuserid/public_html/sites/all/modules/date/date.field.inc).
•Notice: Undefined index: value2 in date_field_validate() (line 311 of /home/myuserid/public_html/sites/all/modules/date/date.field.inc).

...This is my first post on Drupal, and it's for a bug report. But, I love Drupal 7 and I do love the Date module!

Is there a way to donate to the module owner, to ensure that the development moves forward at lightening speed, for this module and others they develop?

EDIT:
PS - the field is only capturing the values that I described upon submit. So, I am able to "chose" the right dates with the picker, but upon submit, the first field is a day behind and the other one only collects 1969.

Is anyone looking at this?

Same. Subscribing too.

* Notice: Undefined index: timezone in date_field_validate() (line 310 of C:\wamp\www\drupal7\sites\all\modules\date\date.field.inc).
* Notice: Undefined index: value2 in date_field_validate() (line 311 of C:\wamp\www\drupal7\sites\all\modules\date\date.field.inc).

Granularity set to year/month/day only -- therefore no time zone conversion. This is on Drupal 7.

Still getting these errors in the new 2.0 series:

Error message
Notice: Undefined index: timezone in date_field_validate() (line 310 of /home/myid/public_html/sites/all/modules/date/date.field.inc).
Notice: Undefined index: value2 in date_field_validate() (line 311 of /home/myid/public_html/sites/all/modules/date/date.field.inc).
Notice: Undefined index: timezone in date_field_validate() (line 310 of /home/myid/public_html/sites/all/modules/date/date.field.inc).
Notice: Undefined index: value2 in date_field_validate() (line 311 of /home/myid/public_html/sites/all/modules/date/date.field.inc).

I can't even start my site, without having this fixed. For one, right on the registration, potential users would see these error messages, when they submit the registration form. For two, it is collecting the information incorrectly. I see Karen must be fast and furious at work, based on the activity here in the code-base, but I don't see anyone really answering or addressing the issue here.

As I said, I would gladly donate to this project, if I know to whom and where, to ensure that these issues all get fixed, ASAP. I have an urgent project that I am trying to start and I don't want to have to go back to Drupal 6.

I tried a fresh, fresh installation, from scratch, only installing basic modules (views, ctools, entity, profile2, date), all the latest and greatest, and even only added one basic date field, with drop downs, yet still got this error message when the user tries to register:

Notice: Undefined index: field_user_dob in date_combo_validate() (line 332 of /home/myuserid/public_html/sites/all/modules/date/date_elements.inc).
Notice: Undefined index: field_user_dob in date_combo_validate() (line 333 of /home/myuserid/public_html/sites/all/modules/date/date_elements.inc).

Really, is anyone paying attention to this? I have even offered to donate, to get this moving faster and fixed! Money doesn't even motivate?!

I cannot replicate this problem when adding a date field directly to a user, which was the original report. There is no patch needed, I did not use the patch in this report.

If there is a problem when using Profile 2, that is a different problem that is specific to that module, so it needs its own issue.

This problem is fixed, as I noted earlier, unless someone can give me an example of a way that something fails when following the steps in the original issue.

You guys should have opened a new issue for this instead of piling in with other errors, but it's already done so I'm going to re-name it and keep it.

I installed Profile 2 to see what the problem is because it only happens when using that module. The problem is a Profile 2 bug I believe. The Date module is adding values to the entity using hook_entity_load() and they are available when validating a node or a user but missing when validating a profile, causing these errors. I think Profile 2 is skipping the entity_load somehow, which it should not do.

I'm going to move this issue over there to see if they have any ideas.

For more clarity.

Digging in further, Date does not implement entity_load(), it implements hook_field_load() and adds values there that are available to the validator on nodes and users, but not on profiles.

Thanks, Karen, for digging into this! It is much appreciated! You're hitting the nail on the head now, it seems! A fix would be amazing and greatly appreciated!

Hoping someone from Profile2 is looking at this. It's definitely a major issue with a major conflict with another major module.

+1

I've compared saving a node that has a date field with saving a profile that has a date field.

Both get to field_attach_form_validate() [http://api.drupal.org/api/drupal/modules--field--field.attach.inc/functi..., but with the node, in $form_state['values'][DATEFIELD]... I find an array with the date, timezone, etc, whereas with profile2, in $form_state['values'][DATEFIELD]... there is just the date.

@KarenS: How do those extra elements get loaded into the form state for the node? As far as I can tell, date_field_load() does that, but it's called *after* we've been to field_attach_form_validate() when I save a node.

Have the same issue

Hmm, load is called after validate? That seems odd. I guess we need to identify what hooks fire when so we can figure out the right way to get this working.

I did an exercise with FAPI back in Drupal 6 where I just put a dsm($op, NAME OF MODULE) in every FAPI hook to try to sort out what hooks fired when, and which modules came before/after others. I don't have time to do this right now, but if someone who wants this fixed could do try this and report back it would help. We want to mark any field hooks managed by Date and Profile2 and see exactly what ops happen in which order and which module gets in there first for each one. If I can see what is happening maybe I can find a different way to accomplish our goals. We want more than just the validate and load hooks, I want to see if there are others that might be a better fit. There are various 'pre-' and 'after-' hooks that might be useful, as well as the standard ones.

I also am curious why this hasn't been an issue for node and user, which also do validation. I tried to figure out what the Profile module is doing, but there's a lot of code and I haven't had time to dig into it.

> I also am curious why this hasn't been an issue for node and user, which also do validation.

Yes, I've been wondering that too!

Possibilities that have come to mind:

- Profile2 takes you back to the form rather than to a saved entity -- not a problem, I think, as I tried putting a $form_state['redirect'] = 'node' and still got the error.
- Profile2 forms are secretly user edit forms due to the way the user edit category system is made by core.
- The mydatefield key is not at the top level of the $form the way it is for a node -- it's $form['PROFILETYPE']['mydatefield'], as can be seen at the end of profile2_form_user_profile_form_alter(). This is a consequence of the above point, I think.

So possible hiccups that might cause: does date module assume it will find $form['mydatefield']? does it do some interrogating of the FieldAPI system based on, say, finding $form['#user']?

The other avenue is that EntityAPI module does a fair amount of work for Profile2. Are there any other modules that rely on EntityAPI yet? Could someone try out one of those to see if there's a problem there?

Does anyone have a fix?

Re: #23:

How do those extra elements get loaded into the form state for the node? As far as I can tell, date_field_load() does that...

I did some debugging and I don't think date_field_load() is how this is happening. Seems to be happening somewhere else.

Sorry, I meant to mention this last week...

There is a similar problem with nodereference fields: #1113390: Validation issue with node reference autocomplete.

Given the similarity of the error messages, I suspect it's the same problem. Nodereference is almost certainly a simple module than Date, so investigating that first might be a good bet.

Looking at date module, there might be a couple issues with the way date widgets use $form_state.

In short, after #942310: Field form cannot be attached more than once, which got in late in the D7 cycle, widgets shouldn't refer to $form_state directly to store or retrieve data about the field - which it seems date widgets do. It works for basic entity forms, but will/might cause issues when fields are attached to a nested form, such as field_collection, or possibly (dunno) profile2.
Noderef had the same issue until very recently : #1126566: autocomplete widget doesn't work in field_collection widget

Instead, the field_form_get_state(), field_form_set_state() accessors should be used. But if it's only so that widget FAPI helpers (#element_validate, #process, etc) can retrieve the $field and $instance, field_widget_field() and field_widget_instance() will do that simply- see #950138-27: Abstract Field API $form_state usage into an API function.

I'll try to look more precisely at the date code, but it might not be before a couple days.

I have found a similar issue when using field collection, because the date field doesn't get attached to the root of the form, and because of some of the validation code in date module assume that date fields are attached to the root of the form this would cause notices in date_field_validate later in processing.

I've posted a patch in date module's issue queue over here:
#998220: Undefined index notices in field validation

I'm not 100% familiar with the ins and out of this issue, but it looks like this one should be marked as a duplicate of #998220 if it solves the problem for you.

subscribe.

Confirm this is fixed with patch to #998220: Undefined index notices in field validation, which has now been committed. Thanks all!

So, is the issue we've been addressing fixed? Should I try another go at this? Or was something else, not totally related fixed? ...I am very encouraged, to see all of this productive teamwork and activity! Great, everyone!!

I just installed a fresh copy of Drupal 7 and the latest dev for the Date module, with Profile2 beta 2. The date is now properly working in the registration form and profile! Woo-hoo! No errors and the proper date is getting saved! That's major progress!