Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
For my current project I needed just a simple date-popup field to set the date. Unfortunately the date field is always rendered in the fieldset, what looks very ugly for some simple forms (a fieldset introduced just to keep a single date input). It should be possible to disable this 'fieldset' behaviour from config.
For my own purposes I patched the date field, introducing new 'simple' control. The patch is in attachment.
Comment | File | Size | Author |
---|---|---|---|
#169 | date field.png | 9.94 KB | karimiehsan1819 |
#168 | remove_loc_label_bug_when_using_reg_field.patch | 679 bytes | DuneBL |
#163 | Modified Date Setup.png | 65.01 KB | shaisamuel |
#157 | date-disable-fieldset-1467712-157-D7.patch | 8.14 KB | jibran |
#151 | date-disable-fieldset-1467712-151-D7.patch | 8.28 KB | ankur_novatree |
Comments
Comment #1
fehin CreditAttribution: fehin commentedThis will be great if it's possible.
Comment #2
puddyglumThis is exactly the problem I'm having. None of our fields have Fieldsets except the date, and it looks pretty clunky.
Comment #3
puddyglumI haven't had any problems after applying the patch you used, thanks!
Comment #4
puddyglumI've cleaned up the code and attached a proper patch.
Comment #6
puddyglumFixed the patch
Comment #7
puddyglumComment #9
puddyglumComment #10
Bronislovas CreditAttribution: Bronislovas commentedThanks jmonkfish it is really good patch!
Comment #11
meladawy CreditAttribution: meladawy commented#9: date-n1467712-9.patch queued for re-testing.
Comment #12
chertzogAwesome!!! Love this. Hope this gets committed. Looks good on my end.
Comment #13
meladawy CreditAttribution: meladawy commentedI don know ,
This patch didn't work for me but i hope that the developers of date module to remove this ugly fieldset :\
Comment #14
puddyglumbazo0oka, the patch adds a "Do not use fieldset" option on the field's edit page. You have to check it to make the fieldset go away for that field.
Comment #15
meladawy CreditAttribution: meladawy commentedK jmonkfish thanks :)
Comment #16
KarenS CreditAttribution: KarenS commentedThe fieldset is added in a theme. You can override the theme. If we add a setting for every single thing you might or might no want to see the settings page will be overwhelming.
What is wrong with using the theme system as it was designed?
Comment #17
puddyglumWell my angle on this is that the Date module has incorrectly wrapped date fields in a fieldset for a long time. Maybe the correct approach is to remove the fieldset altogether, and add an option: "Wrap the Date field in a fieldset"?
How easy is it for the non-Drupal developer to write a custom theme to eliminate the fieldset? It's quite a bit easier to simply check or un-check a fieldset.
I don't understand why the fieldset is the standard, default, and currently ONLY way to display a date without having to write custom code.
Comment #18
KarenS CreditAttribution: KarenS commentedThe fieldset is because we do in fact have a collection of fields, so it is not 'wrong' to use a fieldset. Depending on the type of date and its granularity there could be seven or eight floating date elements in each field. The fieldset also is needed to keep the 'All day' and 'End date' checkboxes from escaping. So removing the fieldsets only works if you are not using those and you have a small collection of date parts. If that applies to you you can fix that in your theme. If I make this a setting, I also have to provide solutions for all the things that will now break.
Comment #19
puddyglumBut since this is an important feature that I think many Drupal newbs will want, I see creating a simple toggle to turn it on or off as ideal.
Comment #20
anrikun CreditAttribution: anrikun commentedI hate this fieldset too. By default, date fields should be themed like other core fields, that is, using div instead of fieldset.
Besides,
theme_date_combo
states:So why is it used even when there is only a single date and not a combination?
Comment #21
anrikun CreditAttribution: anrikun commentedLook at the attached screenshot.
You can't tell that there is no problem here:
Whereas other fields are rendered as label/field (as expected), date field has no label but a fieldset with a legend.
This can even be considered as a bug.
Comment #22
chertzogI understand where @KarenS is coming from. When you don't use the popup calendar, and you use select widgets for the date, i can see where the fieldset could be desirable. But when you are using just a textfield or the the popup calendar (which i suspect most people are), the fieldset is unneeded. Could we compromise, and have an option to disable the fieldset when using the popup calendar? And leave it in place when using other widgets.
As someone who has used this module on many projects, starting before I even knew how to spell php, the fact that the fieldset is added in a theme, is irrelevant to people who dont understand how to override module provided templates and themes. For some of my earliest projects, just used css to hide all of the extra labels, fieldsets, padding, and margins.
just my $.02
Comment #23
anrikun CreditAttribution: anrikun commentedI have decided to file a separate issue for #21 as this is clearly a bug.
#1538072: Date field rendering does not conform to Drupal field standards
Comment #24
KarenS CreditAttribution: KarenS commentedI closed the other issue. This is not a bug. As noted on the other issue this field could potentially contain a lot of elements -- the all day checkbox, the end date checkbox, a field for the date, time, year, month, day, hour, minute, second, am/pm, and/or timezone. And all the sub-elements have to be floated to keep the form from being 5 miles long. So the fieldset serves a purpose -- to keep all this contained.
Even if there was an option to eliminate the fieldset no one has addressed the problem of how to manage all these sub-elements that are now going to render badly across themes. You guys only care if it works for your individual situation. I have to care that it is totally portable no matter what elements are included.
Adding in switches for different things to happen depending on how many sub-elements there are makes this code even more complex than it already is. Both the code to implement the alternatives and the field of settings that the admin has to wade through.
You can fix this relatively easily in the theme, which is the standard drupal way of fixing these things (since that related issue talks about 'the Drupal standard'). You want a non-standard solution -- a setting for something you can control in the theme.
I understand that not everyone likes the fieldset but it makes things work and I don't want to be responsible for the things that will break without it.
The one change I would consider is a single switch to eliminate the fieldset in the display. It needs to have a warning that whatever display problems there are from removing the fieldset are not 'bugs' and will not be supported. If you choose to get rid of it you are on your own to fix whatever the fallout is. That will not keep people from posting support questions and bug reports about it, which I will then have to process. So this is going to require more work from me. But if you provide a patch like that I will look at it.
Comment #25
arlinsandbulte CreditAttribution: arlinsandbulte commentedThere are some good points on both sides of the issue here. But first, we need to better evaluate what the current situation is and what (if any) changes should/could be made to improve that situation.
In another duplicte issue, anrikun attached a screenshot of 4 different field settings to try and make a point about the current situation. But, that screenshot does not consider all the various configurations of a date field. That all-inclusive list is very large.
Instead, attached is a list of settings I think are relevant to the discussion.
Comment #26
puddyglumThanks for your time on this! Jotting down what has been discussed so far:
Solutions so far:
Attached a patch for #2 which includes this warning: " WARNING: Some Date field configurations will not display correctly without being wrapped in a fieldset."
Comment #27
anrikun CreditAttribution: anrikun commentedHere is my patch as well.
I will post comments later as I need to return to real life for 2 hours :-)
But I have also attached a screenshot showing the result.
Comment #28
puddyglum#27 looks awesome! My only concern is that sites that already account for the Fieldset may have a new set of problems if it just disappears suddenly.
Attached are images of #26
Comment #29
KarenS CreditAttribution: KarenS commentedThe default behavior for any patch like this is that existing fields will be unaltered. I haven't reviewed the patch yet, just noting that.
Comment #30
anrikun CreditAttribution: anrikun commentedLet me explain what patch at #27 does. I would have prefered to submit it in the other issue, as it is not just a matter of removing the fieldset.
Anyway, the patch makes a date field look the way a Drupal user would expect a field to look like:
- It brings back theme_form_element so that field has a label (with required mark if necessary, thus fixing this bug), input elements, a description/help text
- When the field is multiple, each item is rendered inside a table cell, so it removes the unecessary fieldset. Patch also fixes the duplicate help text bug displayed both for the field itself and each item.
- input elements are still wrapped inside a container, but a div instead of a fieldset.
- patch detects if inputs inside the container are displayed on several lines, and if so, add an extra class to the div. By default, this extra class adds a border around inputs (see screenshot at #27). When inputs are displayed on only 1 line, there is no border.
- patch seems to work with any variation at #25 + supports date_repeat_field
@KarenS:
I understand your concern. If this patch has a chance to be committed, I'm OK to merge it with jmonkfish's one, so that by default fieldset is still used.
Comment #31
KarenS CreditAttribution: KarenS commentedOK, this patch is less invasive than I expected, which is good. We need to merge the ideas so that we have a warning and a default that leaves things alone. You should test that existing fields are unaltered even if no one has touched the field settings.
For the warning message, I might change "WARNING: Some Date field configurations will not display correctly without being wrapped in a fieldset." to "The date field elements are wrapped in a fieldset by default, and may not display well without it."
Comment #32
KarenS CreditAttribution: KarenS commentedComment #33
anrikun CreditAttribution: anrikun commentedHere is the merged patch:
- added the option to render the date field as a regular field (per instance setting, *unchecked by default*).
- rewrote my previous patch so that there are almost only additions.
- added a separate theme function to render the date field as a regular field. After applying the patch, theme registry must be rebuilt for this function to be detected.
*This patch leaves existing fields unchanged (tested).*
Comment #34
puddyglumPatch applied great, and I like the verbiage on the Edit Field screen.
The only problem I have is that there is still an extra label and an extra container with a border on it that doesn't flow well with a bunch of other regular fields and doesn't look like a regular field.
No fieldset, no container, no extra label:
No fieldset, extra container, extra label:
Is there a way to remove the extraneous container and label from a Date field that is a single date field?
Comment #35
anrikun CreditAttribution: anrikun commentedMaybe I forgot something.
What widget are you using? Date popup?
Comment #36
anrikun CreditAttribution: anrikun commentedTry this updated patch.
And edit your date field and set Position of date part labels to None under More settings and values > Advanced settings
Field should display as you expect then.
Comment #37
puddyglumYes, Pop-up calendar. Attached a screenshot of the settings.Okay, trying the patch
Comment #38
stompersly CreditAttribution: stompersly commentedThe patch in #36 works great. It took me a minute to see I needed to look under advanced options in the fields settings, but it works great thanks anrikun
Comment #39
puddyglum:) #36 works perfectly for me as well. Thanks anrikun!
Edit: actually, when I applied the patch it caused my main navigation to get moved around... I need to figure out if the patch really caused that, seems unrelated.Comment #40
puddyglumI still haven't figured out what's wrong, but after I applied the patch there are some non-ascii characters before the doctype tag and it's causing the browser to go into quirks mode. If I take away the patch the problem goes away.Update: Patch #36 is working great for me.
Comment #41
puddyglumCan anybody leave feedback or identify problems with implementing this patch? At first it sounded a little invasive, but it's looking very safe to apply right now.
Comment #42
loominade CreditAttribution: loominade commentedthe new option only removes the label, the fieldset is still there. is it what you wanted?
Comment #43
anrikun CreditAttribution: anrikun commented@loominade: no, the new option allow to render the date field as a regular field instead of a fieldset.
But after applying patch at #36, theme registry must be rebuilt for the new function to be detected.
(I had written this at #33.)
Comment #44
loominade CreditAttribution: loominade commented@anrikun yes, I flushed all the caches. but still I have a fieldset and a field without label.
I use the following field configuration:
Comment #45
anrikun CreditAttribution: anrikun commentedHave you checked the new option to render the date field as a regular field?
It doen't seem present in your config.
Comment #46
loominade CreditAttribution: loominade commentedI did. Its just not in the feature (code above)
Comment #47
anrikun CreditAttribution: anrikun commentedHow strange. Could you post a screenshot of your date field settings form?
Just to make sure that it looks the same as mine.
Comment #48
loominade CreditAttribution: loominade commentedComment #49
anrikun CreditAttribution: anrikun commentedPatch #36 does not seem applied on your site as your form is missing the new setting.
See below:
Comment #50
loominade CreditAttribution: loominade commentedah, sorry. now it works.
but the label is
<label for="edit-field-birthday-und-0">Birthday</label>
while the actual id of the input isedit-field-birthday-und-0-value-datepicker-popup-0
Comment #51
anrikun CreditAttribution: anrikun commentedI know but this is a different issue.
Whether applying the patch or not, date field breaks accessibility and W3C validation.
I have already posted an issue about this: #600236: Invalid XHTML "label for" when using popup
Current issue is only about allowing to render a date field as a regular field (Accessibility and validation problems should be addressed in the other issue).
If you think that it works, then feel free to mark this issue as RTBC.
Comment #52
puddyglumPatch #36 has been working very well for us in a production environment on several content types. We got positive feedback on it as well.
Comment #53
play4quarters CreditAttribution: play4quarters commentedHi,
following to see if this gets included in the module.
I appreciate everyone's work here, as the field sets are causing me problems with mobile theming.
thanks much.
Comment #54
anrikun CreditAttribution: anrikun commented@jmonkfish, play4quarters:
I guess it will never get committed if nobody marks it as RTBC first (as I wrote at #51).
Comment #55
puddyglumComment #56
KarenS CreditAttribution: KarenS commentedI tried this patch out and when I check that box the date completely disappears from the form. I cleared the caches several times. I tried all kinds of different date fields and none that use the Date Popup widget worked, all of those completely disappeared from the form. Dates that use the Date Select widget seem to be fine.
I can't get it working so marking this back to needs work.
Also I would like this moved to the 'Advanced settings' section. The Aquia UX team spent a lot of time simplifying the field form to keep it simple, and this makes it more confusing. It will still be available.
Comment #57
anrikun CreditAttribution: anrikun commented@KarenS: thanks for your review and explanations. I will have a look at this problem.
Comment #58
puddyglumDate fields with the Date Popup are working for me. I'll re-try from scratch.
Comment #59
anrikun CreditAttribution: anrikun commented@KarenS, jmonkfish: Date Popup fields are working for me too.
KarenS, did you configure some other setting (that I may not have tried)?
Comment #60
anrikun CreditAttribution: anrikun commentedIn the meantime, here is a new patch that moves the new setting to the 'Advanced settings' section.
To people who already use path at #36: beware that if you switch to this new patch, we will have to check the setting again for each date field.
Comment #61
Sinan Erdem CreditAttribution: Sinan Erdem commentedThe latest patch doesnt work for me. As KarenS stated on #56, the date field completely disappears if I check the option. It doesnt matter if I use popup or select list.
Comment #62
anrikun CreditAttribution: anrikun commented@etcetera9:
Have you cleared your theme registry cache after applying the patch?
What other settings did you set for your date field?
Comment #63
Sinan Erdem CreditAttribution: Sinan Erdem commentedYes, I cleared the caches many times, run the cron also.
Settings of my field is on the attachment.
Comment #64
Sinan Erdem CreditAttribution: Sinan Erdem commentedI think I found my problem. I am using the field inside a field collection (Field Collection module). Then it doesnt show it. On some normal date field, it works as suggested.
Comment #65
mgiffordSounds like this should be reviewed by WAVE, but better by a real person using AT.
Comment #66
mh86 CreditAttribution: mh86 commentedCurrently using patch from #60 and it works well
Comment #67
rbruhn CreditAttribution: rbruhn commentedThanks for this patch. Hope something can eventually be put into the module permanently. I was searching for this very solution, and saw KarenS mention doing it in the theme. So spent 3 hours searching the internet on how to do exactly that. Well, trying to find that answer was like having molars pulled without anesthesia.
I received an error when applying the patch in that it could not patch date.theme for some reason. I added the code by hand.
The only issue I have is while the old fieldset title is now showing for the field label, so is the Date label. Meaning, my field now looks like:
Date Collected
Date
[input field is here]
Edit: Nevermind. I see setting "Position of date part labels" to none fixes that.
Comment #68
mrmartin CreditAttribution: mrmartin commented#60 works well for me with 7.x-2.6 version.
Comment #69
jday CreditAttribution: jday commentedWorks for me too, (#60 on 7.x-2.6). I would also love a global setting, I have at least 50+ pop-up date fields and clicking through to each fields advanced setting to check that box is not so much fun but I'm glad to be rid of the fieldsets - Thanks anrikun!
Comment #70
arlinsandbulte CreditAttribution: arlinsandbulte commentedCopied from shane's post at the code karate blog:
http://codekarate.com/blog/removing-fieldset-drupal-7-date-field
This is a relatively easy one, but I found myself scratching my head at this for longer than was necessary. There are times in which you do not want a Drupal 7 date field to be added inside a fieldset. One discussion on Drupal.org (http://drupal.org/node/1467712) mentions applying a patch to the Date module. I think it is much better to just use the theme layer for it's intended purpose... overriding theme-able output. The main problem for a lot of people, is that they are just not as comfortable with PHP or are unsure which functions need to be overridden in your template.php to get the desired results.
So if you are looking for the simplest way to get your Drupal 7 date fields from displaying inside of a Fieldset, drop this code into your theme's template.php file (replacing MYTHEME with the name of your theme).
Just for reference, the original theme function was called theme_date_combo and is located in the date.theme file of the date module. Here is the original code:
It is almost too simple... you just need to know which function to override.
Comment #71
yannickooPatch from comment #60 works fine, thanks! I think we should commit the patch.
Comment #72
yannickooSorry, forgot to read the other comments. Does this patch has problems with field collection? With nodes it works fine.
Comment #73
Agileware CreditAttribution: Agileware commented#70 works for me, good one thanks for posting arlinsandbulte
Comment #74
MustangGB CreditAttribution: MustangGB commentedAnother @todo for #60, the following margin-bottom should be 0 when not in a fieldset.
Comment #75
trapper-1 CreditAttribution: trapper-1 commentedI am getting similar results as #56 and #61. When applying patch from #60 and changing field settings to 'render as a regular field' the entire field disappears from the forms (add/edit) completely.
Comment #76
balazswmann CreditAttribution: balazswmann commentedPatch in #60 works well for me. This is exactly what I need. Nice job! My module version is 7.x-2.6.
Comment #77
Frederic wbase CreditAttribution: Frederic wbase commentedi can confirm that the patch from #60 works like a charm. Thanks to everyone for this nice and hard work!
Comment #78
mautumn CreditAttribution: mautumn commented#70 works for me - both within a field collection and on its own. Thanks very much for the tip arlinsandbulte.
Comment #79
m@rtijn CreditAttribution: m@rtijn commentedI decided to override the theme_date_combo function mentioned in #70 to get rid of the fieldset of my basic date field. Can someone point me in the right direction to get rid of some div containers? I would like to accomplish the following:
Comment #80
KarenS CreditAttribution: KarenS commentedI just want to note that removing the fieldset has accessibility implications. See http://drupal.org/node/504962 and http://groups.drupal.org/node/19118.
Comment #81
msti#60: date_option_render_as_regular_field-1467712-60.patch queued for re-testing.
Comment #82
Dave.Ingram CreditAttribution: Dave.Ingram commentedJust came across this and would like to point out that if fieldsets are semantically correct but not pretty, they can be easily styled with css. Here's one approach which cleaned things up nicely on a particular theme I was working in, but should be a close approximation for what most seem to be trying to solve here:
Comment #83
KarenS CreditAttribution: KarenS commentedI am not going to add this change. As noted in #70, you can do this by overriding the theme, which is the normal way of handling things like this in Drupal. And as noted in #82, your can also override css to make it less obtrusive.
Making it into a UI option adds lots of overhead to an already complicated module. And the real deal-killer is that removing the fieldsets makes the field inaccessible. I'm working on Date in core for D8 and it looks like the fieldsets will be needed there, and they will definitely not be configurable in D8. Core only ships with accessible code. So you will need to either override the theme or the css in D8.
We should add some documentation somewhere about how to do this 'right' -- either by overriding the theme or the css. Let's change the patch to fix the documentation instead.
Comment #84
modulo CreditAttribution: modulo commentedsimple-date-control-7.2.1.patch queued for re-testing.
Comment #85
puddyglum@KarenS, can you explain why default Text fields in Drupal do not need fieldsets, but Date module fields do? Is it for the cases where there is both a "From" and "To" Date?
I see this module as fundamental for most Drupal sites, and the fact that its implementation sticks out like a sore thumb. Every single client says, "It looks great, but why does Date look different than all the other fields?" So it's back to implementing CSS & Template file fixes for all of the fields, when it really should be option to turn off the fieldset... or more realistically an option to turn it on.
Comment #86
Dave.Ingram CreditAttribution: Dave.Ingram commented@jmonkfish. Karen addressed this in comment #18. The date field may have quite a few different fields in it and therefore should logically have a fieldset around it.
Comment #87
puddyglumThanks Dave. I give up.
Comment #88
KarenS CreditAttribution: KarenS commentedAlso read #80 which tells you it is an accessibility issue. There are core patches that will require this fieldset coming.
Comment #89
anrikun CreditAttribution: anrikun commentedI seriously doubt that accessibility has ever been a priority of the Date module: bugs such as "label for" to non-existent IDs and duplicate IDs that break W3C validation have been around for years.
I did read #18 and #80. But have you read #30? My patch was not about simply removing the fieldset. It was fixing the missing "required" bug and the duplicate description bugs too. And it was removing the fieldset when date field was multiple, because why wrapping an extra fieldset when each item is already displayed inside a table cell? This patch was not perfect but it was made to be as less invasive as possible.
If you really want to stick to core, then date field should use theme_form_element() like any other field, even if there has to be a fieldset inside.
Anyway, I give up too :-(
Comment #90
eliaspallanzani CreditAttribution: eliaspallanzani commented+1 for an option to turn off the fieldset.
Comment #91
peteruithoven CreditAttribution: peteruithoven commentedI would personally suggest publishing a separate small module, something like Simple Date Widget. That would only allow a start date, no end date, no all day, no repeat rules. I imagine that in that case it won't brake accessibility issues? Why would you try to do all the possibilities with one widget anyway?
Comment #92
Sk8erPeter CreditAttribution: Sk8erPeter commented@peteruithoven: How is developing a less configurable (dumber) module related to the problem of making fieldset possible to be disabled at all? As it was mentioned earlier, you can override theme_date_combo in your own theme, and do the needed modifications. I think publishing a "separate small module" for the same task is simply useless.
Comment #93
peteruithoven CreditAttribution: peteruithoven commentedBecause you can make it without the fieldset to begin with? Without adding another exception to an already complicated widget element.
Comment #94
Sk8erPeter CreditAttribution: Sk8erPeter commented@peteruithoven: you have to make this exception in your theme only once if you want to do it for all the widgets, but you can always add an if statement if you realize the fieldset is still needed somewhere... without having to create another module for the very same task.
Comment #95
presleyd CreditAttribution: presleyd commentedI hope you will reconsider something like this Karen. Fieldsets ARE important for all the reasons you name but I would like to have control over grouping my fields and not have my date fields have an extra layer of fieldsets. I do not think the default behavior being in a fieldset is ideal for the most (likely) use case of wanting to store a single date. The 'to' date and repeat API features are great extras but are not core to the idea of a date field.
Comment #96
Countzero CreditAttribution: Countzero commentedJust wanted to add my vote for simplifying the basic use of a date field : storing and displaying dates as simply as possible. It's called Date, not 'Complex Dates Management Field'.
The current default display just feels like a plain anomaly : everybody in FAPI displays its stuff as simply as possible, except Date, which adds its own very special display.
Most of the time, one doesn't need all the Repeat and End Date stuff (which I was otherwise happy to find in some use cases), but just a plain dumb date. I find it hard to understand why anyonne should have to overwrite a theme function to downgrade a default behaviour.
I bet the vast majority of people using the date stuff will feel the same way. The idea of a simpler module seems sound to me. In fact, I think it should be the default, and the current Date module a valuable extra for people (me included) who sometimes need a more versatile solution.
But well ...
Comment #97
mgiffordThe Issue Summary might need to be revised, but I think the problem described so far is that folks don't like the look of the fieldset around the date input fields. If that's the case, shouldn't we just be looking for a CSS solution?
For accessibility it is important for the semantic relationship between the fields to be maintained. The only way to do this is through fieldsets at this point. Drupal 7 is using FIELDSETS badly and Drupal 8's largely moved to using DETAILS.
I don't see any reason to visually display a FIELDSET around a group of date elements. I also have yet to hear a reason why this markup should be excluded. I posted some links about why FIELDSETS are important #501428-107: Date and time field type in core there's also this issue here #504962: Provide a compound form element with accessible labels .
Comment #98
viadimezzo CreditAttribution: viadimezzo commented#70 awesome, thanks a lot arlinsandbulte
Comment #99
presleyd CreditAttribution: presleyd commentedIf there is no To date or repeat options, do we still need the fieldset? Nobody wants to break accessibility I think. #97 is correct that it really is just a display issue though. It's the little things like this that weird out new site builders or people coming in from Wordpress. 'Correct' functionality can't stomp out the user experience and theme overrides should be for doing 'different'. Not for trying to make Date look like every other field.
Comment #100
lipinponmala007 CreditAttribution: lipinponmala007 commentedI some how took it all and chande it it to a table
Comment #101
mmilano CreditAttribution: mmilano commentedIf you need to correct this from within a module, hook_theme_registry_alter() works well. Remember to flush the theme registry.
Comment #102
falcon03 CreditAttribution: falcon03 commentedFrom an A11Y point of view, this is "won't fix". The date widget is a compound form element, so it should be wrapped in a fieldset.
But I can understand that wrapping the date widget in a fieldset can alter the appearance of the date form. So, I would like to invite anyone to have a look (and eventually help with)
#1918994: Improve Datetime and Daterange Widget accessibility
so that we can add the needed fieldsets without altering the appearance of the date form.
Comment #103
puddyglumI'm still not understanding why there can't be an option to disable the fieldset element. Looking back through this issue's discussion it sounds like it became pushed aside when things got complicated.
I think the constructive idea of this issue is to add an option to disable the fieldset. Allowing the solution to be in the Field's UI instead of having to hand-code solutions for each theme/site would improve this module. Which would improve Drupal because there's no other Date module. ;)
Yes, it can be solved with CSS / Theme hooks / Module hooks / Hacking the module. But why not provide an option that can be consistently used and relied upon?
Not always, and, in my case, not very often. Please refer to:
So many other modules rely on and extend the Date module, it's not really feasible to create a new Module called "Simple Date" or "Date-lite".
The whole point of this issue is to alter the appearance of the Date form from how it currently is.
Comment #104
arlinsandbulte CreditAttribution: arlinsandbulte commentedAs I understand the issue, the 'extra' fieldset issue should only be a problem when using a simple, single text area for the date & time value and with no End Date.
In all other cases, the fieldset IS needed to properly group the related fields.
Comment #105
puddyglumIf there is a built-in option to simply hide the fieldset, that would probably be enough. I'm gathering that the fieldset is needed for accessibility, and that hiding the fieldset is not a problem.
I'll try and put together a solution that simply hides the fieldset when the "Display as a normal field" option is enabled.
Comment #106
trapper-1 CreditAttribution: trapper-1 commentedmy 2 cents....K.I.S.S.
Drupal core + contrib modules allow me to do anything and everything I want - I can build a learning management system, an ecommerce site, and custom in-house applications. I can do this because core and contrib modules are broken down to their basic components - this Date module (specifically the fieldset issue) goes "against the grain" in regards to core and most other contrib modules are built.
If I just need a date field I should be able to add one without a fieldset - "core" date functionality. Y'all got it right with the repeating dates and all-day functionality - to quote from the Date project page:
The fieldset that is required is because of the start/end date functionality that is still included as part of the date core, but I highly recommend y'all do the same as you did for repeating and all-day. make into it's own sub-module so that all of us who want a simple single-date field can quit hacking date core and/or writing custom CSS to get around this.
Also, the start/end date functionality is super, but goes against database normalization - storing more than 1 value in a single 'field' (I know the database actually stores this in separate fields). this funcationality makes it easy to implement a request that I am sure a lot of people have, but the 'correct' way to capture start/end dates would be to create a new content type with 2 fields 'start' and 'end', and then add an entity-reference field to your parent content type. the entity-reference field will handle the fieldset required.
how hard would it be to implement something like this?:
Comment #107
tregismoreira CreditAttribution: tregismoreira commented#60 works perfectly for me too. Thanks a lot! :D
Comment #108
DuaelFr#60 works pretty well but I faced an UI issue when I enabled it on a really simple date_popup field with date only and no end date.
The fact is that when you only have one component in the field, you have two labels and the first points to nothing. In this case we should hide the main one and copy its title to the component's.
That is what this patch adds. Just take a look at the interdiff.txt to see how I did it (less than 20 lines).
This patch is part of the #1day1patch initiative.
Comment #109
AaronBaumanReopening based on responses to #102
If accessibility is the issue, then:
a) if there's actually only one input field, a fieldset is unnecessary (per #103 and #99)
b) a js/css-based solution could preserve accessibility -- even for compound fields -- while granting finer control to form builders
Comment #110
mgifford@aaronbauman This seems reasonable. Certainly for a single field a fieldset isn't needed.
Comment #111
wismbuh CreditAttribution: wismbuh commentedsimple-date-control-7.2.1.patch queued for re-testing.
Comment #112
lazly CreditAttribution: lazly commentedIts sounds like incredible useful! Please commit it (if its working).
Comment #113
DuaelFrIt is still working :)
Comment #114
lazly CreditAttribution: lazly commentedThan an commit sound like an amazing idea ;)
I hate the independent patches in an armed system, because after it you'll cant upgrade simply, just if you always re-patch your code. And only few mounts, and you will forget it.
Comment #115
podarok#108 looks good
RTBC
Comment #116
vijaycs85Can be removed...
Missing check_plain here.
Comment #117
Anonymous (not verified) CreditAttribution: Anonymous commentedAgainst which version should this patch be applied?
Comment #118
flefle CreditAttribution: flefle commentedHad to update the patch changes above the latest version of Date module (dev version after 7.x-2.7).
The interdiff interdiff_7024.txt was already in the /date_option_render_as_regular_field-1467712-108.patch
Comment #119
flefle CreditAttribution: flefle commentedHad to adjust the line above the latest dev version of Date module from date_option_render_as_regular_field-1467712-108.patch. The interdiff_7024.txt is already included in the mentioned patch.
The patch changes are working like a charm. I had to clear cache to see the remove fieldset checkbox.
Comment #120
flefle CreditAttribution: flefle commentedFound out that a #description field is missing in date_elements.inc so I've updated the patch.
Comment #121
yannickooPlease use spaces instead of tabs.
Comment #122
podarok#120 needs work due to drupal code standards https://drupal.org/coding-standards#indenting
Comment #123
MustangGB CreditAttribution: MustangGB commentedComment #124
MustangGB CreditAttribution: MustangGB commentedWhoops
Comment #125
capellicI applied the patch, looks good! Thank you!
Comment #126
vijaycs85the patch made the date field disappear in content type. Please find the steps to reproduce:
Also adding Needs tests to cover the test case for the presence of a date field with new settings.
Comment #127
vijaycs85Attachment for above comment.
Comment #128
vijaycs85Comment #129
rphillipsfeynman CreditAttribution: rphillipsfeynman commentedI confirm that following the steps in #126 it works like charm. Thanks for this great work guys. Looking forward to see it included in the module.
Comment #130
MustangGB CreditAttribution: MustangGB commented#126: For me it re-appears if you clear your cache, or are you saying the patch should do this automatically?
Comment #131
vijaycs85#129: @rphillipsfeynman I'm afraid, it is not behaving how it suppose to
@akamustang, yes, it should be automatically updated.
Comment #132
thijsvdanker CreditAttribution: thijsvdanker commented@vijaycs85: Could you elaborate on what's not behaving how it's supposed to?
Comment #133
tregismoreira CreditAttribution: tregismoreira commentedThe patch #123 works greatly! Thanks a lot!
It is already committed to -dev branch?
Comment #134
gbirch CreditAttribution: gbirch commentedFor anyone banging their heads against this problem using the suggestions from comment #70:
1. Yes, you really do have to override theme_date_combo even when you have a simple, one-date field.
2. If you have many different kinds of date fields in your site, and want to override the theming only for the simple date case, you want to copy the theme_date_combo function (from date.theme), rename it, and add a bypass that applies only when the field is simple. By the way, if you go this route, remember to update your code any time the date module maintainers decide to update the theme_date_combo() function (even more fun than keeping track of patches):
3. But that override only lets you get rid of the fieldset. There are several layers of extraneous divs added by other functions. For a date popup field, you also need to override theme_date_popup() (found in date_popup/date_popup.module) The same caveats apply, and note that I have not tested this with a field that also gathers time values:
4. Finally, to suppress the "Date" label that the module adds to your simple date field, make sure that when configuring the field, you go into "More Settings and Values", "Date Entry", "Advanced Settings" and set the "Position of date part labels" to "None". This will at least hide the extra label, although it will still be there in the markup.
I hope this spares some poor sap some time. And it seems to serve as implicit answer to the observation by KarenS that one could/should just fix the markup "the standard drupal way".
Comment #135
mxlav CreditAttribution: mxlav commentedApplied #123, everything checks out, except if you enter some Help text, it doesn't get rendered. Turning off Render as a regular field will show the Help Text.
Comment #136
kevinsiji CreditAttribution: kevinsiji commentedNot trying to defeat the purpose of this issue.
Its easy to manage the date field using pure css. Below is what I've arrived at for a single element date field.
Original
Fixed in css
Comment #137
kevinsiji CreditAttribution: kevinsiji commentedDo not know why my images are not displayed.
Embedding here again:
Original
Fixed in css
Comment #138
nessunluogo CreditAttribution: nessunluogo commentedThanks everybody for the job on this issue!
Talking about the CSS alternative solution proposed by kevin, in my case I had to add some more CSS for my skeleton based theme. This is the code:
Comment #139
lavamind CreditAttribution: lavamind commented@mxlav, To restore the Help text when using patch #123, add the following line
right before
in the theme_date_form_element function.
Comment #140
lazly CreditAttribution: lazly commentedThis is mine CSS code, for this "bug". I'm using it for the "Seven" admin theme.
Comment #141
MustangGB CreditAttribution: MustangGB commentedCSS doesn't cut it, the bug is the additional markup.
Comment #144
ankur_novatree CreditAttribution: ankur_novatree commentedPatch submitted in #123 had gone stale and required a re-roll. It was an auto-merge. Submitting the re-rolled patch.
Comment #145
ankur_novatree CreditAttribution: ankur_novatree commentedComment #147
ankur_novatree CreditAttribution: ankur_novatree commentedComment #148
ankur_novatree CreditAttribution: ankur_novatree commentedI am really sorry for this trouble and inconvenience. I am contributing for the first time and learning applying and rerolling patches for the first time. Being a Windows user is making it a little more difficult.
Please ignore the file in #147 and bear with my mistakes for this time.
Comment #149
ankur_novatree CreditAttribution: ankur_novatree commentedComment #151
ankur_novatree CreditAttribution: ankur_novatree commentedComment #152
vorapoap CreditAttribution: vorapoap commentedThis is my css code for Open Atrium 2.0 under oa_radix theme (I put it to screen.css) modified from #138
I agree that toggling Date field to Regular Field must be put into core not patching like this.
Comment #153
emjayess CreditAttribution: emjayess commentedWow.
Sometimes my clients justifiably inquire as to why some things are so hard, or seem to take so long and be so obtuse and perplexing in Drupal... to which I just respond, "In Soviet Drupal, fieldset eliminates you". Then I tell them to read issue threads like this one. Then we begin evaluating CMS's that still suck at accessibility, but with which we can create aesthetically pleasing forms in a little less than 2 and a half years.
Comment #154
meecect CreditAttribution: meecect commented@emjayess no kidding. The sad thing is, I could point you to many other examples that are worse than this. I was just looking at an issue yesterday that had been going on for at least 4 years, about adding an option to show the label (or not) on boolean checkbox fields. I love Drupal, but sometimes I think the tagline should be:
Drupal --making me look stupid in front of my clients since 2004.
Comment #155
meecect CreditAttribution: meecect commentedsee also: removing N/A as an option to non-required radio buttons.
Comment #156
milos.kroulik CreditAttribution: milos.kroulik commentedHas anyone tested patch in #151, yet?
Comment #157
jibran#151 worked just fine. Here is the reroll version of the patch. Other then tests it is RTBC.
Comment #159
podarok2 years...
Let's make this patch in.
commited. Will be tagged in next upcoming beta release. Thanks for hard work on it.
Comment #161
Anonymous (not verified) CreditAttribution: Anonymous commentedJavaScript:
Comment #162
shaisamuel CreditAttribution: shaisamuel commentedI don't quite understand. I applied the patch (tried both #151 or #157), even added the css, and still nothing changed.
Can anyone help please, and explain what need to be done?
Comment #163
shaisamuel CreditAttribution: shaisamuel commentedOk, I found it, its in the field setup form.
Just needs to choose "Render as a regular field", and the magic happened...
Thank you !
Comment #164
AnybodyIt works great and it would be time to have this in a new stable release. Any plan or tag for that?
Comment #165
a.milkovsky+1 for new stable release.
Works good for me, a very good feature.
Comment #166
kopeboy CreditAttribution: kopeboy commentedWell.. the "Render as a regular field" cuts the fieldset (thanks!) but won't let the Help text show!
A regular field in Drupal should have the help text visible..
Comment #167
DuneBLThere is also another problem: when "regular field" is selected, the label of the field isn't localized as it should...
Comment #168
DuneBLhere is an ugly patch to have the labels translated...
Comment #169
karimiehsan1819 CreditAttribution: karimiehsan1819 commentedhi, i want hide or remove border of date field how i can do it ?
Comment #170
Zekvyrin CreditAttribution: Zekvyrin commentedI found another bug:
when the date field is required, the "fieldset title" appears (and the field title may or may not be rendered as it works as it should with the "Position of date part labels" setting).
Comment #171
dzy CreditAttribution: dzy commentedWhen "Position of date part labels" is None , should remove the label
<label class="control-label" for="edit-student-birthday-und-0-value"><span class="form-required" title="This field is required.">*</span></label>
Comment #172
frobAll these bugs really need to be entered as new issues, this patch/feature was already committed.
This issue should be closed(fixed) and all the bugs need to be entered as new issues.
Comment #173
MustangGB CreditAttribution: MustangGB commentedAgreed, restoring status, bugs/follow-ups should go in new issues.