Conditions:
Create a date field and make it render as regular field (using the checkbox provided in the advanced settings). On "date attributes to collect", only choose year.

Result: The field is rendered without a label.

If you either choose to render as fieldset (clearing checkbox to render as regular field), or if you add month to the data attributes to collect, the label shows fine.

I don't think I had this problem with 2.8 version, so I suppose this bug was introduced in 2.9.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

pedrogk created an issue. See original summary.

hgoto’s picture

I also met this issue.

The field label is not displayed when we use only year-month-date. After researching it, I found that this bug occurs only with the widget type `date_popup`. Other widget types in date module such as `date_text` and `date_select` don't have this issue at least in my environment.

The steps to reproduce the bug:

1. Install and enable the date and date_popup modules.
2. Create a field with date type for a content type.
3. Configure the settings for the field as following:
- Check only Year, Month and Day in "Date attributes to collect". Make Hour, Minute and Second checkbox unchecked.
- Check "Render as a regular field" checkbox on. It is in the "ADVANCED SETTINGS" part in the "SHOW MORE SETTINGS AND VALUES".
4. Open a content add page with the date_popup field created above attached.
5. You cannot see the label for the date_popup field (This is not an intended behavior, I believe).

Here is a patch. The patch's approach is based on the approach of date module. I just applied it to date_popup.

I'd like someone to test/review it. Thank you in advance.

(It may be better to change the issue title if my recognition is correct (if this issue is only for date_popup).)

hgoto’s picture

Version: 7.x-2.9 » 7.x-2.x-dev
Component: Code » Date Popup
Chris Matthews’s picture

I was easily able to reproduce this issue using the detailed steps to reproduce, thank you! The 3 year old patch in #2 to date_popup.module still applies cleanly to the latest 7.x-2.x-dev and fixes this issue for me for date_popup.

FireHawkX’s picture

Sorry if i reply to an old thread, but I am using the Date Module with only Year, also rendered as a regular field.

I tried applying this patch, which applied to latest date module perfectly, but the problem is not fixed in my case.

I am using the Select List widget (In the content type manage fields, i only have select list or text field as widget)

Yet the label still does not appear...

If i go to the Advanced settings and set "Position of date part labels", those works, but thats not what I need sadly...

I have another date as select list which has year, month, day, hour, minute, and that one always worked and the label displays properly...

Any suggestion on how i can fix it on my end?

If I should have made a new bug report or anything differently please let me know so I can improve! :)
Thank you very much for your time and have a nice day!

aurelianzaha’s picture

FileSize
946 bytes

Hi,

I had a bit different issue, but the attached patch might solve the original problem as well.
The issue that I had is that the label of the main field was not rendering when granularity of date only was selected, although the 'Position of date part labels' was none.

klausi’s picture

Status: Needs review » Needs work

I think this makes sense in principle.

+++ b/date.theme
@@ -463,7 +463,15 @@ function theme_date_form_element($variables) {
+    $field_info = field_info_instance($element['#entity_type'], $element['#field_name'], $element['#bundle']);

I think we should not call field_info_instance() in a theme function. Instead all necessary variables should be prepared before either in a preprocess or as theme variables.

Maybe we can't change that at this point? Would that be an API change in date module?

+++ b/date.theme
@@ -463,7 +463,15 @@ function theme_date_form_element($variables) {
+    $original_title_display = $element['#title_display'];
     $element['#title_display'] = 'none';

the logic is a bit weird. First it is set to 'none' and then that might be reversed. Can we move the setting to 'none' down in an else{}? Then we don't need $original_title_display.

aurelianzaha’s picture

Thanks @klausi for feedback, I had a closer look at the $variables array and it contains the field instance, so no need to load it.
Attached the updated patch.

aurelianzaha’s picture

Status: Needs work » Needs review
klausi’s picture

Status: Needs review » Reviewed & tested by the community

Looks good to me now, thanks!

ahmed_h’s picture

DamienMcKenna’s picture

Status: Reviewed & tested by the community » Fixed

Committed. Thank you.

  • DamienMcKenna committed e6660a1 on 7.x-2.x authored by hgoto
    Issue #2595957 by aurelianzaha, DamienMcKenna, hgoto, klausi, pedrogk,...

Status: Fixed » Closed (fixed)

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