I have a date CCK field (using the date_popup widget) used by two different content types. It allows for an optional end date, meaning the form fields are displayed in a fieldset on the node add/edit pages.
Each content type uses a different label for that field: "Event Dates" and "Program Dates". However, on the node add/edit forms, only the first label ("Event Dates") is being used as the fieldset legend for both types. Each content type is supposed to display it's own unique field label as the #title (which translates into a legend tag), but instead they're using the same one.
I checked the database, and content_node_field_instance correctly lists this field once for each content type. And they both have a different label column value.
So I can only assume the database query is just taking the label of the first instance of the field instead of matching by the correct type_name. But I can't seem to find where this exists in the code. This site runs PHP 5.2 site.
Attached is a screenshot of the database fields, and the fieldsets (the 2nd one is supposed to say "Program Date(s)").
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | 406976.patch | 853 bytes | dopry |
| #2 | CCK Existing Fields.png | 37.56 KB | noahterp |
| Content Type 2.png | 7.73 KB | noahterp | |
| Content Type 1.png | 11.78 KB | noahterp | |
| Database Labels.png | 20.16 KB | noahterp |
Comments
Comment #1
arlinsandbulte commentedLooks like the problem is that both your fields have the same name (field_multidates).
Not sure how that happened... it should not LET you do that. This is either a bug in cck or date... not sure which.
I just tried; Drupal would not let me create a field with the same name.
Try updating cck and date to the latest releases. If that does not work, try the latest -devs.
I am using Drupal 6. Looks like you might be using D5, correct? If so, update the version info in this issue.
Comment #2
noahterp commentedI wasn't creating a new field with the same name... I was using an existing field. CCK is supposed to let you reuse/share fields between multiple content types. That's what the Add "Existing field" option is for on the Manage Fields pages (see attached).
So in this case, the field_multidates field is shared between two content types. And that's how CCK promotes the type to its own table (versus being a column in the individual node's table).
This site runs PHP 5.2 and Drupal 6.10.
Comment #3
arlinsandbulte commentednoahterp: Did you fix or work around your issue? Can this issue be closed out?
Comment #4
noahterp commentedMy current workaround is to use JavaScript to rewrite that
legendupon page load for those forms.Another workaround I explored was to create completely separate CCK fields for the various dates. While this works, it prevented any easy View integration between the types (I would have to use a Computed Field to grab the date value of each field).
So any thoughts on fixing this output bug so I can reuse the same CCK field? Do I need to explain how to recreate this bug in more detail?
Comment #5
arlinsandbulte commented@noahterp: any update? What if you update to the latest version of all modules?
Comment #6
noahterp commentedThe bug still exists in the latest versions. Here are the steps to reproduce so a maintainer can figure out where the problem in the code sits.
Confirmed to be buggy in the latest versions: Drupal 6, CCK 2.5 and Date 2.4.
1. Create two new content types. For example: Event and Course
2. In the Event type, add a Date CCK field with a start and optional end date. Label it "Event Dates".
3. Create a new node of this Event type. You'll see on that form, there are two input fields (From date and To date) in a fieldset with an "Event Dates" legend.
4. In the Course content type, add that same "Event Dates" CCK field into the Existing Field area. But give this one a label of "Program Dates" (the rest of the options can stay the same).
5. Create a new node of this Course type. You'll see on that form there are two input fields (From date and To date) in a fieldset with a "Program Dates" legend.
Good so far, but…
6. Go back to create a new Event node again. The date fieldset's legend has now changed to "Program Dates". That legend should have remained as "Event Dates".
Note this problem is only on the node create and edit forms. The admin Manage Fields area
and node output both show the correct legend/label. So this low-priority bug just affects content contributors, not site visitors.
Walk through the steps and let me know if you have problems recreating the bug. Any ideas where in the module code this comes from?
Comment #7
noahterp commentedThe bug still exists in the latest versions. Here are the steps to reproduce so a maintainer can figure out where the problem in the code sits.
Confirmed to be buggy in the latest versions: Drupal 6, CCK 2.5 and Date 2.4.
1. Create two new content types. For example: Event and Course
2. In the Event type, add a Date CCK field with a start and optional end date. Label it "Event Dates".
3. Create a new node of this Event type. You'll see on that form, there are two input fields (From date and To date) in a fieldset with an "Event Dates" legend.
4. In the Course content type, add that same "Event Dates" CCK field into the Existing Field area. But give this one a label of "Program Dates" (the rest of the options can stay the same).
5. Create a new node of this Course type. You'll see on that form there are two input fields (From date and To date) in a fieldset with a "Program Dates" legend.
Good so far, but…
6. Go back to create a new Event node again. The date fieldset's legend has now changed to "Program Dates". That legend should have remained as "Event Dates".
Note this problem is only on the node create and edit forms. The admin Manage Fields area
and node output both show the correct legend/label. So this low-priority bug just affects content contributors, not site visitors.
Walk through the steps and let me know if you have problems recreating the bug. Any ideas where in the module code this comes from?
Comment #8
dopry commentedThe theme function only calls content_fields() without specifying the field_type and content_type so the content_type specific widget settings are not loaded, the first widget for the field is used instead. See patch. please test.
Comment #9
ssemigr commentedsubscribing
Comment #10
karens commentedYeah, @dopry is right about the fix. This doesn't apply to the D7 version since there we have much better distinction between instances of fields.