Make Day/Month/Year Optional in Date Component

No, it's currently not possible to have a date component without a year. I'm moving this to a feature request. I'm not sure if we'll be able to use the date field provided by core for much longer, as it doesn't have the option for excluding the year either. However Webform already does quite a few tricks with the date field to change the year into a textfield, so I'm sure it'd be possible to remove the year entirely.

I am looking for this exact functionality as well (not having a Day field). I'm using version 3.6 and it doesn't appear to me that anything like this has been implemented...

I found this issue #121415: Month/Year field type and I am wondering if anyone has tried to implement this code with v3 yet?

*ignore this comment*

*ignore this comment*

I should test more before attaching these patches... too bad I can't delete previous comments.

This patch should actually save the dates in the database.

This is really useful. Any chance we can get this rolled in?

I don't know why the status of this topic hasn't been marked, "Needs Review" but it should be. Could someone update this patch to work for the newest versions of Webform?

I'm running 7.x-3.18 and get:

$ patch -p0 < webform_7.x_3.x_optional_day_2.patch
patching file components/date.inc
Hunk #1 succeeded at 21 with fuzz 2.
Hunk #2 FAILED at 89.
Hunk #3 succeeded at 212 with fuzz 2.
Hunk #4 FAILED at 289.
Hunk #5 succeeded at 331 with fuzz 1 (offset 19 lines).

Patch for optional day and year attached, rewritten for webform 7.x-3.18. Not sure if it's good enough to be reviewed, tested and committed, but it seems fairly harmless and works for me.

Caveat

• Popup calendar cannot change the assumed (default) values of the optional date components (e.g. if you set optional day, you can't use the popup calendar to change the day).

Patching the day as optional should remove the day from appearing in both the form and when viewing the results. Using the patch above, the day continues to show upon reading the results.

I am also getting the error upon editing a submission:
Notice: Undefined index: #attributes in form_process_date() (line 2944 of /includes/form.inc).

Can anyone help out here?

A PHP notice is harmless, but I agree with you that the results view should also hide the optional components. Other than that, does it behave like you expect?

Yes sir. However, if you or anyone knows of a way to also remove it from the results, please post an update! To allow the calendar on only month & year would be a bonus as well-- right now, the calendar date picker only selects the date once you choose a day. After these two fixes, this could then probably be added into Webform's next release.

Updated patch as per #13 to also format the results display properly.

Thanks for the update! I am using it with the Webform Table Element module.

I patched the original date.inc for Webform v7.x-3.18, cleared all caches, noticed you also added in an optional year check box, and upon trying it, the second date input with an optional day continues to give me an error upon submission:

(Which to me, doesn't make sense). I tried changing a value in red after it failed, (once changing the year in red and once changing the month in red) and both times it would submit on the 2nd try. Second attempt showing the results after getting the same behavior below:

As you can see, after both of them were submitted, the results continue to show the day as well.

Thanks for trying it out. It looks like I should test more combinations before posting. :) I'll see if I can reproduce the errors and rewrite the patch.

Hmm. It looks like there is an incompatibility with my patch and the webform_table_element module. I'll see if I can figure out something.

Keep in mind the patch you submitted in #10 worked with the Webform Table Element module without error-- the only issue was that it showed the "Day" in the results still.

The invalid date error from your optional_day_patch_2_results.png screenshot is probably because February 29th is an invalid date and you couldn't see the day (29) when you submitted the date.

I also need to adjust the patch to trim out [,-/] characters from the date display when optional day/year values are suppressed.

The results page's display issue is probably because webform_table_element overrides webform's built in date theming.

Another related issue is that webform_table_element module does not support required validation on date elements—e.g. if you leave the date blank and the element is required, the standard "this field is required" error is not generated. Without this being fixed, I doubt my patch will be compatible with the webform_table_element module. See #1462386: Validation not working for table element

Just a note: the validation is now working for dates in Webform's newest dev version.

I can verify that the date validation is working, however, I believe there is still a bug in webform_table_element display the date fields incorrectly. Ideally, it should use webform's theming so that I won't need to alter the patch to make the dates display correctly.

@jtwalters thanks for this cool patch, #14 works and displays on the Month and Year in the results view page, (attached screenshot: 1.png).
There are some issues:
1. The date field is now mandatory even though mandatory is not selected. I am unable to submit the form without selecting a date, this should not be the case.
2. the day appears when I download the submissions in Excel from the results page.
3. And also when displaying the results in a view, the Day appears (attached screenshot: 2.png).

Here's a slight update to the patch. Fixes (1) in comment #22. (can someone verify?)

RE: #22
(1) This patch should prevent date validation on non-required date fields
(2) You will probably have to use Excel to reformat the date display.
(3) In Views you should be able to format date fields with a custom date formatter. See admin/config/regional/date-time in your D7 admin.

@ jtwalters, thanks for the patch

#22
(1) is fixed.
(2) Not sure how to do this, the export still shows days for example, when submitted value is Jul 2009 the Excel displays it as 1 July 2009
(3) Not sure if this is a issue with the views, I cannot use custom format for "date fields" used in the webform, but can use custom date formats for "submitted date", "content updated date" etc...

And finally after applying the patch if I enter a correct date the submission and results are fine. but if I enter a random number like 2123, the form is submitted with some error messages (attached webform.png) and no data in the submissions page.
To recreate the steps are:
1. create the webform with date field and day optional.
2. Go to form and select a month and enter 2232 as year (year field is textfield)
3. submit the form.

@vishusrinivasan: That problem may be solved by this recent change: #1276550: Anonymous users do not use site default timezone. It'll be in the 3.19 and 4.0-alpha4 releases.

No new features are being added to the 3.x branch (which also means we don't need to backport this to D6).

If anyone is using Webform Table Element and wants to make the day optional, I got a hack working to strip it out.

Add this to a block in the administration theme for the results pages using wildcards:

jQuery(document).ready(function(){
	function fixDay () {
		jQuery("td").html(function(i, str) {
			return str.replace(/\/\d{2}\//g, "/");
		});
	}
    fixDay();
});

More info here: http://drupal.org/node/1762320

Hi all,

I have applied the patch on #14 for a D6 3.18 version of the module but an error pop up, here:

Notice: Undefined index: year_optional in webform_expand_date() (line 202 of /public_html/sites/all/modules/webform/components/date.inc).
Notice: Undefined index: day_optional in webform_expand_date() (line 207 of /public_html/sites/all/modules/webform/components/date.inc).
Notice: Undefined index: year_optional in webform_expand_date() (line 208 of /public_html/sites/all/modules/webform/components/date.inc).
Notice: Undefined index: day_optional in webform_expand_date() (line 234 of /public_html/sites/all/modules/webform/components/date.inc).
Notice: Undefined index: year_optional in webform_expand_date() (line 238 of /public_html/sites/all/modules/webform/components/date.inc).

Do you have any clue on how to fix this?

Thank you

Julian Mancera

Added on to patch in #23 to include month.

Note, this is for 3.x, and not meant to impede the 4.x progress. Just wanted to share :)

status

Hi guys, thanks for the work on this patch. This is the first time I've had an opportunity to look over the whole thing. Some feedback:

- This patch doesn't seem to affect the downloaded data through CSVs. I think it probably should, but is there a reason to include a full date?
- I'm a little nervous that this isn't really displaying all the data that's being stored. A month/year field isn't really a "date" any more. But I can see the usefulness of this patch and the overall approach looks pretty solid. Nice job.
- All code comments need to be formatted sentence case: starting with a capital letter and ending with a period.
- I'd prefer to make the setting name more representative of what the option does if "day_optional" is TRUE, it really means "day_hidden". It's not optional if you don't have the ability to fill it in.
- Related to the CSV problem, let's abstract this bit out to a dedicated function. This much logic in the theme function isn't ideal:

+    // modify the date display for optional year/day
+    if ($element['#webform_component']['extra']['year_optional']) {
+      // remove 2- or 4-digit year
+      $format = preg_replace('%[yY]%', '', $format);
+    }
+    if ($element['#webform_component']['extra']['month_optional']) {
+      // remove any month reference
+      $format = preg_replace('%[FMmn]%', '', $format);
+    }
+    if ($element['#webform_component']['extra']['day_optional']) {
+      // remove any day reference
+      $format = preg_replace('%[Ddj]%', '', $format);
+    }

A related patch that will probably end up affecting this one: #1346536: Make submission date display formats configurable. It doesn't look like this has been updated for 4.x, but I'm not sure many changes are necessary.

Nice looking patch overall. If some of the above things can be addressed I think we can include this in the project.

Hey guys,

This patch in #29 had a bug in which stopped optional 'day' working. Few minutes digging and found this group of code applying the new defaults on line 74;

+ 'day' => $element['#webform_component']['extra']['day_optional'] ? 1 : NULL,
+ 'day' => $element['#webform_component']['extra']['month_optional'] ? 1 : NULL,
+ 'year' => $element['#webform_component']['extra']['year_optional'] ? $assumed_year : NULL,

Noting the two occurances of 'day' so the functionality would work up until submission, where the form would still error.

+ 'day' => $element['#webform_component']['extra']['day_optional'] ? 1 : NULL,
+ 'month' => $element['#webform_component']['extra']['month_optional'] ? 1 : NULL,
+ 'year' => $element['#webform_component']['extra']['year_optional'] ? $assumed_year : NULL,

Have replaced with the following with new patch attached.

Update patch #32 to make it compatible with 4.x branch and fixed a typo on #default_value.

There was a typo in my last patch, attached the right one.

About patch #32 - great patch, just a few comments.
Anyway those few things are fixed on #33 and #34.

1. diff --git a/sites/all/modules/webform/components/date.inc b/sites/all/modules/webform/components/date.inc
   ...
   +      'day_optional' => FALSE,
   

   You should generate patches from the root of the module. Else it will be harder to apply it.

2. +++ b/sites/all/modules/webform/components/date.inc
   @@ -176,10 +207,14 @@ function webform_expand_date($element) {
   +      'day' => $element['#webform_component']['extra']['month_optional'] ? 1 : NULL,
   

   While you correctly described the fix it still with 'day' instead of 'month'

There was an issue in validation when selecting the first date and the month/day were marked as optional.
Now it's fxed with this patch

Patch in #36 contains:

diff --git a/components/date.inc b/components/date.inc
index b1b694d..10e1f52 100644
--- a/components/date.inc
+++ b/components/date.inc
@@ -15,7 +15,7 @@ function _webform_defaults_date() {
...
- 'required' => 0,
+ 'mandatory' => 0,

and consequently

@@ -122,15 +151,15 @@ function _webform_render_date($component, $value = NULL, $filter = TRUE) {
...
- '#required' => $component['required'],
+ '#required' => $component['mandatory'],

This causes all my date elements in my webforms to become optional even if Mandatory is set in the component since I'm using Beta version of webform.

May I skip this alterations and apply the rest of the patch to get it working in beta or shall I be forced to upgrade to dev versione?

Many thanks in advance.

May I skip this alterations and apply the rest of the patch to get it working in beta or shall I be forced to upgrade to dev versione?

This patch has not been applied to the project, so you should be able to modify the patch to get it working for you. After you've modified it, please create a new patch with what works for you. Eventually this may get into the project, but there are a number of issues outlined in #31 that haven't been taken care of yet.

I just rerolled the patch for the 7.x-3.x from #29 to be appliable to the latest stable release (7.x-3.20)
It might be usefull for somebody...

Updated #36 patch to make it compatible with 7.x-4.0-rc4 and removed duplicate slashes.

Could someone summarise what this patch does? I'm unclear, having read through this rather long thread, exactly what the goal is.
Also, is it planned to include it in the main module release?(Just noted comment #31)

Just tested #40 and it is working for vast majority of cases.
Just a few notes: The fields are indeed saving the entire data, no matter if it is a day only, month only, year only etc. But IMHO this is the intention of a date field where something is optional. Else it wouldn't be a date anymore. The developer using the data should be aware and threat it accordingly.
The webform results pages display the dates correctly, but the CSV and table don't.
See escreenshots of the scenarios.

I looked at this patch some.

I think the component definition and edit form can be worked out.
Conditionals will have to be taken into account, including browser-side and server-side versions.
I believe full dates should be exported to CSV, and certainly must be to Excel.
I don't feel strongly about reporting showing or hiding the suppressed portions of the date, although hiding is preferable.
The displayed submission clearly has to hide the suppressed portions of the date.

The patch above is very American-centric. It makes assumptions about the format and YMD order. http://en.wikipedia.org/wiki/Date_format_by_country

Assuming the above reference is accurate I do not believe that regular expressions can be used to remove suppressed portions of the date and work for all formats in all countries. There are simply too many variants. We do use regular expressions to remove the time from a date/time format, but that's a much easier problem. Times have many fewer formats and are kept separate from the date.

It might be that the best solution is to allow the override of the system-wide format for a particular date field. The user would have to create a date form of the type they want, without the undesired portions. Webform could then see what's missing from the format and omit those from the edit form as well.

Any other ideas?

I had some second thoughts. If a format string has its date / month / year formatting characters removed, along with the common extra characters after it (/-.,: ), and then the whole string is trimmed of these characters in case the removed characters were at the end, then the strategy of modifying the format will work.

I adapted the work in #40:

1. webform_date_format was updated to accept an array of day/month/year parts to be removed. This allows reuse of the static caching of the format.
2. The UI for the date component was adjusted. I used a single 'checkboxes' form element, which is cleaner.
3. Form validation ensures that you can't hide all three day/month/year, and you can't hide just the month (because it would be very confusing).
4. When a portion is hidden, the form element is set to be invisible, but still included in the form. This should eliminate potential theming and conditional logic issues that using a hidden field might cause.
5. The hiding is honor by the display of the submission and the results table, but not export.

Committed to 7.x-4.x.

I updated a website to the current dev version of webform and now I have these errors which seems to be related to this issue:

Notice : Undefined index: #exclude dans webform_expand_date() (ligne 251 dans .../drupal/sites/all/modules/webform/components/date.inc).
Warning : in_array() expects parameter 2 to be array, null given dans webform_expand_date() (ligne 251 dans .../drupal/sites/all/modules/webform/components/date.inc).
Notice : Undefined index: #exclude dans webform_expand_date() (ligne 251 dans .../drupal/sites/all/modules/webform/components/date.inc).
Warning : in_array() expects parameter 2 to be array, null given dans webform_expand_date() (ligne 251 dans .../drupal/sites/all/modules/webform/components/date.inc).
Notice : Undefined index: #exclude dans webform_expand_date() (ligne 251 dans .../drupal/sites/all/modules/webform/components/date.inc).
Warning : in_array() expects parameter 2 to be array, null given dans webform_expand_date() (ligne 251 dans .../drupal/sites/all/modules/webform/components/date.inc).

I've attached a very simple patch which fixes these warning.

@idflood -- Can you give me steps to reproduce this the warnings you are receiving. I don't understand how this is possible, unless some other code (outside of webform) is calling webform_expand_date. Are you using some custom code or other webform-related modules that has something to do with dates?

webform_expand_date is the #process function set in _webform_render_date. It isn't used anywhere else in webform. In _webform_render_date, $element['#exclude'] is always set. Therefore webform_expand_date can rely on it.

I don't want to add additional tests to the codebase unless/until we understand why they are needed. Thanks.

@idflood -- Any update? Are you still having the error? I'd like to address this before making a release, but I don't know if this is:

1. A problem in general that I've overlooked
2. A problem with some custom code that just needs updating
3. A problem with another module that needs updating
4. Or just an anomaly of how you updated -- for example a form that was in progress during the update.

Committed and pushed to 8.x-4.x. Thanks!