"Default" value behaviour

I think you’ve misunderstood this. The default value of a field is used when you first CREATE a page. If you are UPDATING a page, the default value does not come into play. The flow is assumed to be this: you create a new page, the default values populate the form fields and you save them. After that point, the edit operation is simply displaying the stored values.

When you are outputting values (i.e. printing values in your templates), the default value is meaningless: you are simply printing the stored values. If you stored a value that happens to also be the default value, it gets printed. If you stored some other value, that gets printed. There’s nothing tricky going on there, we’re just printing the meta_value associated with the given meta_key. Garbage in, garbage out.

Re a blank field: no, that makes no sense. A default value defines a value to use when the field is created, so you can’t have both a default value and have a blank value — it has to be one or the other.

I can understand your confusion because this isn’t the only way to handle this — it’s a subtly complex discussion. Consider a couple mind-bending use-cases:

1. Imagine you have existing pages and you add a new custom field X with a default value of Y. When you print a page that uses those fields, what should it print for the custom field X? Should it “lie” and print “Y” when there is in fact nothing in the database yet for that field? If you are searching for posts based on values for that field, how should that work? You may be able to “lie” to your visitors by printing a value that does not exist in the database, but you cannot “lie” to a MySQL query.

2. What if you change the default value of field X from Y to Z. Should this be a destructive edit and CHANGE all values in the database that were formerly Y to Z? If yes, you risk corrupting data. If no, you risk confusing users who are entering/updating data.

So there’s really no perfect solution here — I just opted for the most transparent, simple option that was the least likely to blow things up.

Thanks for such a quick response!

Your explanation of how it SHOULD work matches my initial assumption. On reading your comments I thought maybe it was just ‘me’, especially as I was basing my comment on items I’d previously created and given a value to a field then later attempted to set it to ‘blank’ by deleting the value and resaving the post.

However, I’ve just created a new post … the ‘default’ value in CCTM is for “CAPTION” is “Michael4fm”. I created a new post and deleted the default value for this field so that the value is ‘blank’ … still is when I edit the post, then published it. However, it shows as “Michael4fm” on the public side of the post here. Yet the value in the post itself is blank (screenshot below the actual post), and has been since creation … so it must be getting the value from the CCTM default … mustn’t it?

To double check I’m not going totally mad, I’ve just gone into CCTM and blanked out the default. When I then view the post the “Caption” field is also blank. When I restore a default value in CCTM, that value then appears in the post … even though I’ve not changed the post at all.

So while I understand what it SHOULD do (and can understand what you mean about the complexity!) what it ACTUALLY seems to be doing is using the default value if another one isn’t specified … or is that just me and I really should be looking elsewhere for the cause?

Sorry, just reread your comments, and maybe I’m still not ‘getting’ what you’re saying.

Re a blank field: no, that makes no sense. A default value defines a value to use when the field is created, so you can’t have both a default value and have a blank value — it has to be one or the other.

Maybe I should be saying “suggested” instead of “default” … so the “suggested” value is pre-filled. If you do nothing and just save the post, this value is used, or you can choose to use a different value, including a NULL value, when you save it.

So what I’ve done is have MICHAEL4FM as the ‘default’ (in my world ‘suggested’ value) in CCTM but on creating this post I’ve erased this value so that the stored value should be NULL or blank … which is what it is showing on the ‘edit post’ screen.

oh snap, you’re right… I changed behavior at some point (sometimes I forget which project I’m working on). So the default value IS being read out of the field definition. See the includes/functions.php file:

// Default value?
	if ( empty($value) && isset(CCTM::$data['custom_field_defs'][$fieldname]['default_value'])) {
		$value = CCTM::$data['custom_field_defs'][$fieldname]['default_value'];
	}

This addition was probably due to some other discussion I had… but I think the way I outlined the functionality before is how it should work, otherwise things get confusing when you deliberately attempt to have a blank value.

I’m glad that I’m not going mad … but I’m a bit confused on your conclusion

I think the way I outlined the functionality before is how it should work, otherwise things get confusing when you deliberately attempt to have a blank value

It’s perhaps unclear from this statement whether you think a blank value SHOULD be allowed to ‘override’ the default or not. Personally, now that I know how it will behave, it’s not a huge deal. I mention it purely in case someone else comes looking at this thread (though if it were a vote, I’d cast mine FOR allowing the occasional blank value while getting the benefit of a default ‘suggestion’ in most cases).

[I’ve got round the problem of introducing new fields on new posts that don’t exist on old ones by adding an ‘if’ statement – if it’s blank, use this value. If you need to change a value on old posts, you can do a ‘search and replace’ … though it takes a little thinking about if you need to change 4 to 3, 3 to 2, 2 to 1, etc!]

The current behavior is a bit weird if you A) have a default value and B) you attempt to deliberately blank out a field. So your concern is valid — I’ll tweak the get_custom_field() function. Personally, I absolutely hate if-statements in a template: they lead to nothing but trouble, and the fact that WP templates are full of loops and conditionals is the primary reason that WP sites do not scale well.