Default values for fields

Currently no, this is not yet implemented. And I see there is no feature request for it yet, so this is it!

+1 on this idea. I can see lots of uses for it and I don't think it would be all that hard to implement -- just one more selection in the widget or field settings. So one question is, should this be a widget setting (content type-specific value) or a field setting (use the same value no matter what content type is used)? I'm thinking the first makes the most sense, or at least offers the most flexibility.

I wanted to submit this feature request by myself, but here it is...

+1 to this of course

i long everyday more to know how to code..! Will buy a php handbook as soon as i will be online with my first Drupal site, promise ;)

+1 It's been requested again here http://drupal.org/node/79122 (marked as a dup of this one).

it'd be useful.

yeah, I agree that this would be a useful feature.
It would be nice to have it configurable for each content type.

i created a patch, which offers the possibility to set default values in the widget settings. At the moment it includes the most importent cck field modules, as text, number, optionwidgets, nodereference and userreference module.
Note: you have to run the content update number 9 before you can use this feature.

patch for 4.7. version

very, very useful! would need it for date fields too...

works great, thanks!

I don't have time to propose fixes right now, but wanted to comment while I'm thinking about it. I think we need to take into account the ability to have a null default value and do some checking whether a field is required or not before filling in a default value. For instance. a number field that is not required would end up getting defaulted to zero with this code, but it should probably be a null value. The ability to properly store null values for non-required fields requires the patch at http://drupal.org/node/85929, which hasn't gotten much attention :-(

Hello,

has this issue been forgotten? The flexinode fields do have "default value", so it would be nice to get this functionality into CCK.

this has my vote. I can also see lots of uses for it. In my top three wishes for cck

I started working on this and have several issues to address before this will work:

1) The enclosed patch creates a new field in the database, but I don't think that's necessary. We can add this to either the widget or field settings without creating a new field, which will eliminate the need to patch content.module and content.install

2) It seems to make sense to create a default value as a widget item, since the widget is actually going to place the value into the form, and that's easy enough to do. The question is how do you run validation on the default value when the user fills that value out in the widget settings? We need to validate the value that is submitted or we could corrupt the database, and I don't immediately see a way to do that when you save the widget settings. The validation done by both the widget and the field needs to get triggered somehow on the submitted value to make sure the default value is valid.

3) As I noted in an earlier item, we also need to watch for whether the field is required or not and whether it has multiple values or not. Do you put in a default value if the field is not required? Do you put it into every empty field if the field is multiple (causing all those fields to be saved since they are not empty)?

I need some feedback on these issues to take this any further.

Recategorizing this. The code definitely needs work, but I would agree that this is an important feature.

Karen, I'd love to help you on this - it would be a nice feature to add
Unfortunately I'm currently over-busy for the next 10 days...

Here are my remarks on the points you mention :
1/
definitely

2/
you're right, and I don't know how we can do that simply either + no time to dig in the code right now :-(

3/
IMO for multiple values the default value can only be set on the first entry. I'm afraid that in the current model this has to be left out for field modules to decide. It's part of the "multiple fields" stuff I wish could be harwired into content.module.
About 'default value' wrt to 'required / not required' : Would it be a problem if these two settings were decorrelated ?
If non required and a default value is specified, the the form gets pre-filled with the default value, and the user can always emprty it before submitting ?

BTW, I think this 'default value' for fields should not be related to the 'default' param in the db columns definition, which, as I see it, is more about what get stored in the db when no value is specified (empty field).

Hi!

That's really a important feature for cck! At the moment I'm using my posted patch - works great.

Every cck field type should support default values, so my decision was to make some changes in content.module and content_admin.inc. The other way would be to implement the same code in every cck field module, which is in my point of view unnecessary, if we can implement default values only by adding some lines to the content.module and content_admin.inc.

Concerning the validation, this is still a topic for me. At the moment, I added some lines to each cck field module. Maybe there is a more general approach.

Would be great if we find some solutions soon! I'll help, if possible!

@mh86 you are misunderstanding the comment about content.module. The code in this patch for content.module creates a new field, which is not necessary. The current system of storing field and widget settings will do this just fine without a new field. So this is not a discussion about taking the code in content module patch and duplicating it in every module, it is that that part of the code is not needed at all.

The validation is a critical issue that can't be ignored, and we can't add this feature without thinking that through because otherwise we might add it in and have people start using it and then find it has to be done completely differently for validation to work, which will then create havoc. It is better to think it through now and implement this the best possible way.

Anyway, I don't disagree that this patch will work in at least some situations, but it still needs work because it doesn't address the issues I raised in my earlier post.

ad 3)
I would agree to just put the default value in the first field. Probably the most useful variant.
I agree with yched on filling in default values for not required fields as it's that what the user has configured. If he doesn't like it he could still change the setting.

It's great to see someone working on this.
Thanks KarenS!

I have an idea I'm working on, not sure yet if it will work. Basically I am going to let you use the widget itself to select the default value. That will provide an appropriate list of options if you have $allowed_values in a select list and an interface that makes sense for the specific field. Then when the field settings form is saved, I'll run that default value through the normal widget and field validation before saving it. My plan is to do this all in the content module rather than in the field modules, but allow a way for a field module to 'opt out' of this handling by setting a hidden value for the field, which tells the content module not to do anything with the default value. The field modules would then be responsible for inserting the default value in the right place, since there is no standard for how the various modules have their forms configured, but that's the only thing they would need to do.

It is looking promising, but I'm trying to find a way to keep the code nice and simple for future maintainance.

Anyway, I'm assigning myself to this for now.

subscribing

subscribing

+1

and I got a request to specifiy run-time php code to use as a default value, i.e.

- the value of a cookie (for hidden fields to store affiliate program referals in a node or user profile)
- the current date
- any kind of result from an online-http request

etc.etc

what are your thoughts on that?

+1 on making the default capable of running php. Maybe as simple as a the return from a single function.

What is the status of this?

tryed mh86's patch against latest 4.7 CCK (non-dev):

UI for adding default value looks fine and no errors are thrown, but the default value fails to show on final node..

I'd be willing to pay $ to someone to get this done timely since i personally need it very soon for a site.

cheers

+1 on this one, would be really nice.

Also the possibility to compute the default value would be nice. Maybe this additional feature could be done with an integration with Computed Field module?

One of the many possible uses (what I need it for right now): having a content type about someone doing something, and having a field for who does it, defaulting to the author of the post...

I'm just getting ready to work on this again and hope to have something soon.

I'm not yet sure this is the best way to do this, but here is a patch. When you start digging into it there are dozens of issues - do you set an array as a multiple value for a multiple value field? If you use php code do you execute it when the settings are saved or when the node is edited? Lots more issues like that.

Anyway, I created a way that the content module will insert a default value option into any field that hasn't indicated it will handle them. It provides two ways to do it, a textfield or a box where you can put some php code. The values you submit are run through the field validation procedure, so for now the php code has to return something meaningful at the time the field settings are created, but is executed when the node is edited. That may not be the best way to go, we can discuss that. The default value then is stored as a part of the widget_settings.

I tried initially to have the content module insert the default value into the form, but that was just too hard since there are countless ways forms could be structured, so I left it up to the fields to insert the value, but I did provide a helper function they can use to get it (content_default_value($field)). So I have included in this patch changes to the field modules to use that value.

The problems of special handling for arrays, etc are so big that any field module doing anything unusual would probably just need to handle the collection of the default value itself.

The method for a module to opt out of this handling is like the one yched just used in the patch to set formatters for the body and teasers, except it would be an operation of 'callback' in the widget_settings instead of the field_settings.

At any rate, this is a starting point for this feature, so hack away at it :-)

Karen, thanks for opening the work. I did hack from your patch indeed :-)

Here's my proposition, and what the attached patch does :
- it considers the default value as a "real" value for the field, meaning it can itself be multiple if the field is multiple (but not 'required' if the field is required...)
- this allows us to actually use the widget form to define the default value
- accordingly, it slightly modifies the content_default_value with the delta as an optional second parameter
- in order to avoid visual clutter, I enclosed the "default value" stuff in a collapsed fieldset (might be argued ?)

This allows a better handling of default values for 'multiple' fields IMO (do not force default values for all the deltas), and the inclusion of the actual field widget is quite pleasant.

This probably still needs some polishing, but I have tested this with text fields and noderefs (select widget), and it seems to work pretty well. The patch includes modifications for all the field modules, but I did not actually tested all of them.
BTW, I wonder if there is a possibility to have this 'default value' stuff managed entirely in content.module, and leave field modules out of this. I guess we'll see that as we move ahead.

Whichever road we take, I think we also need to clarify exactly what we mean with 'default value' for a feild : if a user left a field empty (and it's not required...), should we present him with the default value on next edit (current behaviour in both our patches), or do default values only come on node creation form ?
I'd probably vote for the latter. If I do want my field empty and removed the suggested default value, I should be pretty annoyed if I have to remove it again on next edit (and I might forget to do so, meaning the field changes even if I submit without changing anything in the form - not nice).

great work guys. i agree with "default values only come on node creation form"

new version of the patch :
- It integrates default value handling in content.module, and thus does not need any update on field modules
- as mentioned in earlier post, it only deals with node creation forms : once the node is created it's values (empty or not) are the ones chosen by the author and we should not mess with them.
- the code could probably be polished a little further by places
- the advanced php option needs further testing.
- the idea of a field / widget opting out of the 'default' content.module handling for default values is not completely clear to me, and might need a clearer definition : what happens then ? why would that be a widget setting instead of a field's ?

Moving this to 5 version, since the patch applies to 5 - It could be backported when / if committed.

I completely agree on using it only on node creation.

An example of a field opting out of this is the date field. The default value options are going to include 'current date', or maybe 'current date' + or - some value, which are not regular options in the widget and won't pass validation, so the date field will need to do its own default value handling.

Sorry for the delay on reviewing this. I'm going to try to get to it later today. Thanks for the effort!

Default value for dates : OK - not that I had any objection to allowing an opt-out, but I could not find a concrete example, and this one makes perfect sense of course.
So I guess we're needing your requirements for this use case in order to further refine open questions on this matter :-)

Actually I have a question regarding the 'now' feature for date module.
Wouldn't that be better off as an actual feature of the date widgets themselves ?
Allowing the author to set the date to 'now' or 'now+delta' when he creates the nodes _or_ on subsequent edits ?
In which case date widgets would not need to override the default 'default value' behaviour ?

Well, given the variety of date widgets, maybe that's not actually possible, or requires non negligible work.
And that probably does not stop us from taking this example as a study case for the 'custom default value handling' we're trying to define anyway.

Possibly, but I'm not sure if that is the way it should behave for the end user. Maybe so, haven't played around with it yet. Either way, I think there will be legitimate use cases.

Just to happily announce that I even managed to specify a default value for an image field, which I consider an encouraging sign...
(there is just a missing $form['#attributes'] = array("enctype" => "multipart/form-data"); line in the field setting form)

Well, there is Just a small problem afterwards : when you delete a node that uses the default image, the file is gone. (that's the way imagefield currently works - a workaround should be painless I think)

Looking pretty good! I'm still playing around with it, but a couple comments:

1) Why put default value in a collapsed fieldset? I guess if it is a multiple value that keeps the screen cleaner, but otherwise it makes it harder to find. Might be OK, just wondering...

2) Doesn't work for optionwidgets. The allowed values list now looks like key|value and the field is storing that whole string instead of just the key. I'm trying to see what is happening on the processing side. We need to let the widget do the processing rather than just accept the returned value or we'll have problems with other fields (like the date field that has to put the date parts back together and turn them into a date). Maybe that's not the source of the problem, still investigating...

I figured out the problem with optionwidgets. You were doing the widget processing, but you had it set up to use the field's widget function instead of the widget's widget function. Then after letting the widget process the values, we needed to update the value.

I found one other small item. You are using ob_start(), eval(), and ob_end(), but it would be better to just use drupal_eval() which does all that for us.

So I put those changes into a revised patch.

I haven't tested other things like php code yet.

After more testing with php code and optionwidgets (which is one of our most complicated scenarios) I have made a few more adjustments:

1) drupal_eval() just won't work here. I would swear I got this working somewhere else, but here it just wants to print the array instead of giving it back as an array, so I went back to what you had with ob_start(), eval(), and ob_end().

2) Complicated widgets like optionwidgets that start out with and array in one format (using a key of 'keys') and convert them to a different format) are a problem if you're trying to use php code to create the array. If you create an array that makes it through the widget processing, it is creating the wrong array when you try to actually use the default values. Plus the array you need to create to get through widget processing is very convoluted, and different for every type of field. So what I did was to assume the php code will create the final array of values, which will work the same for all fields, then don't run default values created by php code through the widget processing, and that seems to work. Nodereference and userreference will have the same issues (an input array that is different than the final array), but I think they also will be fixed by this.

Now we probably need an example of what this 'array of arrays' should look like so users know what the code needs to create, but I wasn't quite sure where to put that.

- fieldset : well, I do find that having the 'default values' block expanded by default really gets in the way, since I think you'll want to set default values for a minority of your fields.
But then again, as we've seen in the 'display matrix' patch, my UI choices might not raise consensus :-)
That's open for discussion anyway.

- drupal_eval : yes, I followed the same path and got back to the ob_start / ob_end_method. This is the same code views.module uses for the 'php argument parsing' textarea, so I thought it was OK.

- optionwidgets : I'm definitely not familiar with those, so thanks for checking :-)

- input array for php code : I noticed the same thing with noderef, and was currently working on that. Sorry that I forgot to mention this, it could have saved you some investigation time.
I think we have to make the whole 'default value' setting widget-agnostic anyway (i.e : if you specify a default value, php style or not, your settings are not affected and do not need to be updated if you change the widget later on).
In order to have that, the php code has to return a value in the 'final' (out of db) format, and not in the specific widget format.
Meaning, for noderef :

 array(
  0 => array(
    'nid' => 115,
  ),
);

As opposed to, for instance (autocomplete widget)

 array(
  0 => array(
    'node_name' => 'foo [nid:115]',
  ),
);

So I came to the same conclusien as yours : the validation for php values should not go through widget-level validation (the value does not come from a form), but through field-level validation.
The problem for noderef (and userref - didi not check optionwidgets) is that they only implement validation at widget level. Once that is done, the values are deemed correct (and rightly so), and the field itself does not provide any additional validation (is the nid 'referenceable'). So any values you provide for the nids are considered correct. But of course, later on, these default values have the node rejected on creation time.

This sums up to : in order to provide consistent support for php default values, all fields should provide a field-level validation ?

Actually, yes, we do need to update all modules to move validation into the fields. I forget that hadn't been done yet. There was a long discussion on the dev list about how that was where validation belongs anyway.

There was a long discussion on the dev list about how that was where validation belongs anyway.
Yes ? I must have missed that. Do you by chance have any track of the thread title, or something that I could look for in archives ?

There was a whole long thread about CCK. Here is one part that talked about validation - http://lists.drupal.org/archives/development/2006-10/msg00238.html. The general idea was separating the UI (the widget) from the data layer (the field). I can't think of any reason why nodereference and userreference wouldn't work just as well if the validation steps were moved to the field, but I may not have dug deep enough.

@yched, what do you think about committing this now? Or do you want to wait pending the discussion about moving field and widget validation around?

With the table renaming / upgrade fix patch, I don't really remember where exactly we are at this.
From the back of my head :
- the code for validation needs to be refactored / rewritten (php code should not go through widget ops)
- do we still call widget validation ? I think we should keep that for now (even if it eventually comes out from http://drupal.org/node/112464 that internally all core widgets defer validation to fields - we have no control on contrib fields)
- some explanation for the value expected for php code - "array of arrays" is not right indeed.

Unfortunately I'm a bit short of time to see this before this weekend - but do go ahead with this if you have the opportunity.
This, added with the display matrix patch, would make an nice pack for a 'critical hotfix release' :-)

Sorry, your last version of the patch actually addresses the first two points.
That's right, I remember now : I did not have the time to review it yet :-)

The other 'non resolved' thing is the opt-out behaviour, which, in _my_ last patch at least, was still kind of blurry.
I think 'opt-out' here possibly means two things :
- the ability for a field type (and / or widget ?) to declare that it does not want to support the concept of default value (computed field might need this - but then again,
- the ability for a field type (and / or widget ?) to declare that it provides its own default-value-selection widget (your example with date.module and 'now' stuff)

Maybe we can release the feature with no opt-out feature for now (rather than a temporary-still-to-be-refined one, for we can't really go back and forth with the contrib field API) ? We might want to check if this is OK with computed field, though.

Er, forget the truncated '- but then again' part. Leftover from a rephrase.

I'll work on this tomorrow and try to get it finished up.

Following this great discussion here with specific interest in default date values of php code, it is not clear to me if it was decided that the CCK-form admin will define validation or the CCK-field contributor (and ultimately restrict the values). Will this be a php snippet customizable in [whichever's] rule field? I will post my date-specific concern to the existing CCK date field feature request for default values.

There will definitely be a way for a module to opt out of this and the date module will most like do so. Yes, please post requests on the date issues queue for how date default values should be handled.

Er, I guess I should say eventually there will be a way for a module to opt out. Won't know for sure if it will work on this first go-round until I get this patch finished up.

I just committed this to HEAD and 5.x, it will take a while to get it ported to 4.7, which I'll work on later. Some notes:

1) I tested with a number of field and widget modules. There were only a few that had problems, the logical culprits -- computed field, imagefield, filefield. To work around that, I added in a $excluded array of modules known not to work with this to give the maintainers a chance to make updates, and then to give users time to actually start using the updated code.

2) All the core fields seem to work fine with one exception -- the nodereference autocomplete won't work in the default value form, but works fine in the widget form itself. The userreference autocomplete works fine everywhere, so some investigation needs to be made into that.

3) I went ahead and altered the date module to opt out of the default value handling (although the default handling worked fine as a way to pick an absolute date for a default value). I figured getting that working would be a good way to make sure the implementation worked that way as well, and it does. At some point I need to write up some documentation about how to do that.

Great news ! Thanks Karen !

Now committed to 4.7 also. There will probably be some tweaking needed, but everything seems to be working. Open new issues as necessary.

Works great on the link.module. Thanks guys!

Karen, a few questions / suggestions before we release :

- about imagefield (and filefield ?) : see my comment #37 above.
In short, default values for imagefields seemed to work OK (if we add the currently missing 'multipart/form-data' thing).
An additional fix for node deletion was needed in imagefield.module, but maybe that does not force us to exclude imagefields from the whole default value feature ?

- about keywords used by 'callbacks' op to describe the behaviour wrt field / widgets callback :
'none' / 'module' / 'handle' seem confusing, and not consistent with the 'TRUE / FALSE' values used for the 'view' callback
I suggest we unite this to use defined constants here :
CONTENT_CALLBACK_NONE / CONTENT_CALLBACK_CUSTOM / CONTENT_CALLBACK_DEFAULT
(resp. your 'none' / 'module' / 'handle')

Plus if we define those values as binary masks, this would allow us to combine these values with later to come interesting settings :
CONTENT_CALLBACK_PRE / CONTENT_CALLBACK_POST / CONTENT_CALLBACK_VALUE / CONTENT_CALLBACK_ITEM

I missed #37 or forgot about it. If that will get it working, by all means add it in. Will that make filefield work too? Computed field definitely needs to be excluded, though, because it returns a form element that the user cannot alter, and there may be others I haven't tested.

The keywords names are probably a good idea. Actually, I got to thinking later that that function should proably be refactored to handle various callbacks by changing the name to content_handle($op, $field) instead of content_handle_default_value($field) using $op to identify which callback is being sought ($op = 'default value', $op = 'view', etc.).

I don't have time to make these changes right now, but if you do, go ahead.

I reintegrated imagefield and filefield. Computed field has to stay out indeed.

And yes, I think that eventually we should have a function that centralizes the management of field callbacks and the dispatch between default content.module behaviour and module callbacks. And content_handle_default_value probably is a good starting point. Probably for later, though

I'll try to add the NONE / DEFAULT / CUSTOM constants ASAP.

I committed the CONTENT_CALLBACK_* stuff, and went ahead and turned content_handle_default_value into a generic content_handle, that deals with callbacks settings (since we use this also during the 'view' op).
The example field.php still needs to be updated.

The special management of default value and view ops makes content.module currently stand in the middle of the bridge wrt field modules callbacks management (this not really a consequence of this last commit, we took that step earlier when we added the display matrix feature, and went on with the default value management). I think it's ok since the code in 'externally' functional, but we probably need to internally refactor this to have a consistant handling of field callbacks between all ops.

Oops, I hit "submit" too soon.
I was about to add "(but we probably need to internally refactor this...) in a later release"

Tried downloading latest 4.7 branch from CVS (latest 4.7 release keeps stuck to the 9th January...) cos i really need default values (thanks everybody for this!), but got some fatal errors as it seems some functions already have the names supposed to be for 5.0 (ex: module_exists() and drupal_set_css() if i'm not wrong..).

Can anyone kindly explain why, or what is needed to make it work on 4.7(.2) ?

Thank you very much

You're probably not getting the right branch, and you're trying to execute 5.0 code on your 4.7 install.
I just checked : 4.7-1.x-dev does not have drupal_add_css nor module_exists.

Yched, pardon the ignorance and the OT (this is more support probably, maybe private answer is more appropriate in case), but where can i find 4.7-1.x-dev?

On CVS i can only see 4.7 and 4.7.1-1.x, but not 4.7.1-1.x-dev.....
maybe you mean the 2nd May version found at http://drupal.org/node/48429/release ?

Here it is : http://drupal.org/node/96065
(it' the last item on the project release page)

And, sorry, you're right, the '-dev' part is only added for the tarball name.
In CVS, you would get the 'DRUPAL-4-7' branch. (it's the head of the branch, i.e a moving target - that's why -dev is added)

I just got the latest 4-7 code out of CVS and the default value wasn't working for me with a nodereference field. I haven't followed this thread enough to know what's going on, but just thought I'd throw that out there to make sure that, before the next release, the nodereference type gets tested. I was unable to select a default value for the field, and so wasn't able to fully configure the field (even though I didn't care about default values).

After reverting to the latest release (pre-default values), things work fine for me.

@marcp : there has been fixes around this committed very recently.
Can you :
- check you're using the latest cvs version (4.7 nodereference module should be version 1.25.2.28)
- if the issue is still here, post follow up to http://drupal.org/node/114346, which was opened for this
- if so, provide more info on the exact errors you encounter and the widget you're using

yched - you are correct - i had 1.25.2.25 - i'll try out the latest.

thanks,
marc