We don't currently discriminate between Null and empty with respect to fields and default values.
Currently:
When you add a field to a bundle NULL is populated to the DB and when you edit or view that content the default value is not displayed or prefilled into the edit form.
Steps to reproduce:
Proposed solution:
Use NULL to store default value and "" to store empty values. This allows us to inject the default value from the field definition on field_view_field(). If you take a step back it is exactly what a user would expect when defining a new field. It is also very beneficial to downstream modules like token and views.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | Screenshot at 2012-02-23 12:19:33.png | 23.46 KB | rogical |
Comments
Comment #1
rogical commentedCan you give some screenshots?
I'm not sure if you're talking about this.
Comment #2
Draven_Caine commentedNo, i mean add any field to panels, that has a default value. The default value is added in the fields API at /admin/structure/content-types/...
If the default value is suppose to show, it doesn't. It doesn't even render. So default value = no rendering
Comment #3
Draven_Caine commentedAs always forget to change the status /sigh
Comment #4
merlinofchaos commentedPanels is using core's render method.
Does this default value appear on the node?
Is the default value added after the node is created? Default values are not retroactive, for example.
Comment #5
Draven_Caine commentedthe default value works int he node and in views. Its from a new node. Now what i am meaning is if you use %node:picture (or whatever field) not pulling the field itself, if you get my meaning there. its the "context words" i think they are the % placeholders.
Comment #6
merlinofchaos commentedThose are handled by token.module and passed through into CTools' keyword system. I'm afraid I have no control over what they actually output.
Comment #7
Draven_Caine commentedTossing it over to tokens than.
Comment #8
dave reidI have no idea what the actual bug is here, sorry.
Comment #9
Draven_Caine commentedIn panels there are "contextual keywords" for example %node:picture.
Now in this sense if i use a contextual keyword to grab the field value of %node:picture and the field has a value the it shows, but if the field is empty, the field does not fall back on the default value as specified in your field settings (use to be cck).
Comment #10
michaelfavia commented@Draven: Earl, Dave and i spoke about this in irc and the conclusion is a little jargony but useful.
In short what you are expecting is totally understandable and we (im roughly speaking for them only in so far as we seemed to agree) think it is probably the way things should work. Unfortunately they don't work this way, but for good reason that is embedded in cores field api.
The long description:
When rendering tokens, the token module just calls field_view_field() on the field you've requested to get the token value.
By default drupal stores NULL as that fields its value on every piece of content when you created the field. Drupal interprets that NULL as empty when viewing or editing so nothing displays.
This can be confirmed by adding a field to an existing bundle (content type) and then editing/viewing the a node of the content type in question. You'll notice the default value is neither displayed nor added to the default value for the form.
In fact, the ONLY time the default value comes into play is in populating the entity creation form (node, term, user). In that case the formstate is populated appropriately and rendered with the defaults in there as you and I would expect.
In my opinion this is a bug. We should store "" on purposefully emptied fields and NULL on undefined (aka default) fields. If we did that we could very easily populate the "default value" from the fields definition when it is rendered by field_api and NULL comes up as its value.
The consequences of this are all beneficial.
When you add a field to an existing bundle (content type) all of the cotnent of that bundle gets the default value which most of the time will be empty. When you want a specifically empty field you just delete the default value out of the populated form item and save. The null will turn into a "" and drupal will know you dont want anything there.
Id also like to extend this to the imagefield so that it can benefit from the non exclusive nature of "default value and "empty". Ill try and make a case and a patch if i have time this weekend.
In the end every field should have a default value that is used if nothing has ever been specified for that content when it is rendered. And that default value should be able to be overridden with something or nothing as the user desires. If this is fixed upstream token can just keep doing its thing. Views might need a little love to make it work on filter and sort though says earl.
Comment #11
michaelfavia commentedMoving to field api. Id like to ask yched if he knows why things aren't this way before i get hacking down an alley that's been down before.
Comment #11.0
michaelfavia commentedUpdate to the real issue.
Comment #18
martijn de witComment #22
pameeela commentedThis drives me nuts but I never thought to log it as a bug! I've updated the issue summary with steps to reproduce.
Comment #23
pameeela commentedComment #24
quietone commentedClosed #2603626: Apply default values when existing value is NULL as a duplicate.