Title: &quot;Default&quot; value behaviour
Last modified: August 20, 2016

---

# "Default" value behaviour

 *  Resolved [Michael4fm](https://wordpress.org/support/users/michael4fm/)
 * (@michael4fm)
 * [13 years, 4 months ago](https://wordpress.org/support/topic/default-value-behaviour/)
 * An observation / comment rather than a bug …
 * The ‘default value’ field option (seems to) work during output … so if no other
   value has been assigned, the field uses the default for outputted data.
 * That initially confused me – I thought it was a ‘default’ value for INPUTTING
   data … so if you didn’t specify something else, this would be the value. As it
   is currently set up, if you want a ‘blank’ field, you can’t have a default value,
   even if ninety nine times out of a hundred you want “x” to be the value. If you
   specify ” for the hundredth, it’ll see the blank field and output ‘x’ if that’s
   what you’ve set as a default.
 * Would be handy for this to be an input option rather than an output one, or have
   an additional ‘input’ default.
 * [http://wordpress.org/extend/plugins/custom-content-type-manager/](http://wordpress.org/extend/plugins/custom-content-type-manager/)

Viewing 6 replies - 1 through 6 (of 6 total)

 *  Plugin Contributor [fireproofsocks](https://wordpress.org/support/users/fireproofsocks/)
 * (@fireproofsocks)
 * [13 years, 4 months ago](https://wordpress.org/support/topic/default-value-behaviour/#post-3417744)
 * 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.
 *  Thread Starter [Michael4fm](https://wordpress.org/support/users/michael4fm/)
 * (@michael4fm)
 * [13 years, 4 months ago](https://wordpress.org/support/topic/default-value-behaviour/#post-3417758)
 * 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](http://captioned.s-t-u-f-f.net/cp0102-2/).
   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?
 *  Thread Starter [Michael4fm](https://wordpress.org/support/users/michael4fm/)
 * (@michael4fm)
 * [13 years, 4 months ago](https://wordpress.org/support/topic/default-value-behaviour/#post-3417763)
 * 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.
 *  Plugin Contributor [fireproofsocks](https://wordpress.org/support/users/fireproofsocks/)
 * (@fireproofsocks)
 * [13 years, 4 months ago](https://wordpress.org/support/topic/default-value-behaviour/#post-3417813)
 * 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.
 *  Thread Starter [Michael4fm](https://wordpress.org/support/users/michael4fm/)
 * (@michael4fm)
 * [13 years, 4 months ago](https://wordpress.org/support/topic/default-value-behaviour/#post-3417814)
 * 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!]
 *  Plugin Contributor [fireproofsocks](https://wordpress.org/support/users/fireproofsocks/)
 * (@fireproofsocks)
 * [13 years, 3 months ago](https://wordpress.org/support/topic/default-value-behaviour/#post-3417870)
 * 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.

Viewing 6 replies - 1 through 6 (of 6 total)

The topic ‘"Default" value behaviour’ is closed to new replies.

 * ![](https://s.w.org/plugins/geopattern-icon/custom-content-type-manager_c9c790.
   svg)
 * [Custom Content Type Manager](https://wordpress.org/plugins/custom-content-type-manager/)
 * [Frequently Asked Questions](https://wordpress.org/plugins/custom-content-type-manager/#faq)
 * [Support Threads](https://wordpress.org/support/plugin/custom-content-type-manager/)
 * [Active Topics](https://wordpress.org/support/plugin/custom-content-type-manager/active/)
 * [Unresolved Topics](https://wordpress.org/support/plugin/custom-content-type-manager/unresolved/)
 * [Reviews](https://wordpress.org/support/plugin/custom-content-type-manager/reviews/)

## Tags

 * [default](https://wordpress.org/support/topic-tag/default/)
 * [field](https://wordpress.org/support/topic-tag/field/)

 * 6 replies
 * 2 participants
 * Last reply from: [fireproofsocks](https://wordpress.org/support/users/fireproofsocks/)
 * Last activity: [13 years, 3 months ago](https://wordpress.org/support/topic/default-value-behaviour/#post-3417870)
 * Status: resolved