How can I specify default value for certain input field?

[PawelGIX]

Can I specify default value for certain input field?

For example:

<h1>Title</h1><h2>subtitle</h2><p>article content</p>.

in body InputField.

Maybe custom module?

Some hints?

[ryan]

Currently you can't specify a default value for most fields in ProcessWire. However, it can be supported at the individual fieldtype level. For instance, the date/time fieldtype supports defaulting to today's date. We will likely add more thorough default value support to many fieldtypes in the future, but I'm a little worried about it because I know it will lead to some confusion... especially when you want to change the default value, and there are already old default values on pages.

[PawelGIX]

Thx.

Custom fieldtype should be ok.

Currently you can't specify a default value for most fields in ProcessWire. However, it can be supported at the individual fieldtype level. For instance, the date/time fieldtype supports defaulting to today's date. We will likely add more thorough default value support to many fieldtypes in the future, but I'm a little worried about it because I know it will lead to some confusion... especially when you want to change the default value, and there are already old default values on pages.

For me, the default value is the value that is saved only when adding a new page. After you save the default value becomes the normal value.

[ryan]

For me, the default value is the value that is saved only when adding a new page. After you save the default value becomes the normal value.

I agree and that's the way we'd have to do it. I think there will be some that don't understand why the old default value is still present in places after they change the field's default value, but that will just have to be the compromise.

[MadeMyDay]

Perhaps as an additional option in the field configuration? So if you change the default you are prompted to a dialog:

[ ] change all fields that hold the old default value to the new default

[ ] Leave the old defaults

Btw, somehow related: A optional "inherit" option also would be nice. I know both features (default and inheritance) can be done on a template basis, but as a field option it would be a little bit developer/designer friendlier ;-) But it makes the above problem not easier... hm.

[Adam Kiss]

Maybe if we call it something else than 'default value'?

You know, like 'Populate value for new fields'.

That should take care of some confusion, right?

[ryan]

You know, like 'Populate value for new fields'.

I think this would be the way to go, solving it with terminology.

However, if someone is going to have a lot of the same default value in their database, it would technically be better for them just to leave it blank and then assume the default value from the API side. That way you aren't storing a bunch of duplicate entries in the database. It also solves the issue of what to do when the needs of the default value change. Beyond the issue, this is partly why there isn't a default value in PW now, because I've always used blank to assume a default. Automatically-populated or default values seem like an easy way to store a lot of redundant/duplicate values in the database, making it very unnormalized. So while it seems useful to have default values on the surface, I think there are a lot of cases where they introduce unnecessary overhead.

[Pete]

I wonder if there is some way to assume a default value then but not store it?

If we assume that a developer with some PW knowledge under their belt would be the sort of person to use this feature then we could offer them some options with the default value:

1. No default value (the default field setting)
   
2. Default value that is stored in the DB (not desirable in many cases, but it's all about not making assumptions as to what the user will use it for )
   
3. A default value that is displayed, but not stored. So if in a very simple example the template outputs the default value using if ($page->field == 1 ? $page->field : "I'm a default value string")... then you don't want to store "I'm a default value string" for every page but it would make sense to have it at least display it as the default value in the page editor.
   

I hope 3 makes sense, as I think that option is the best of both worlds - giving the dev the option to set a default value that's not stored in the DB but is instead handled elsewhere but that it's necessary for other admin users to at least see a default value even if it's not stored in the DB

Of course, writing some instructions for this that make perfect sense is another matter entirely

[ryan]

A default value that is displayed but not stored is really no different than having no default at all. But one might assume that they could go perform a find() or something and match pages having that default value, and you couldn't. So it introduces some confusion there. There's also the danger of the default value getting set back to the field and inadvertently saved. That's why I kind of prefer letting the developer decide when and how to implement their default value in their own code. There's no ambiguity about it. But I do still think we'll want a "populate for new fields" like Adam mentioned, for some fieldtypes. The best example is a checkbox that you want to be checked by default.

[Soma]

For things it's may be useful (checkbox) but never felt I ever need it as you could also make it reverse (check to disable). And if then it also can be handled in the template code, if(!$value) $value = 'default'; way. I'm not sure what to think about it really, some part of me likes having default values and some part thinks it complicates things not really necessary maybe.

[ryan]

Default values sound good as a feature, but in practice the need seems to be rare in ProcessWire. There are so many other (usually more efficient) ways to accomplish the same thing. So when/if we implement default values, it'll probably be more about appealing to people's sense of features rather than something that will actually add much value. But there are those rare instances: like a page reference field with categories where you want 3 of them selected by default... I don't think I've ever had the need, but can see it coming up for somebody.

[apeisa]

It is definitely something that you think you do need (of course you need default values), but in real life I haven't got the need even once (only default date).

[Pete]

The only default I have ever implemented was for an article author - it was an ASMSelect field were you could attribute users to an article as authors and I wanted the person creating a new page to be listed as an author automatically.

I worked around it in a module with about 3 lines of code anyway, but that's literally the only time I think I needed it. Even then, as I've added articles on behalf of others on that site I found myself removing my name as the default so the default doesn't always apply by any means.

[MadeMyDay]

I used the default values a lot in MODX. Well, because they were possible (but with all disadvantages mentioned above). I think the default value can easily be done in templates, but as mentioned above some inheritance logic would be nice (which MODX also has, just put "@inherit" in the standard value field). One can also do this in the templates / modules but it is difficult to handle that in the selectors. Say you have a text field which standard value should be "green". In your template you can handle that easily like Soma said with if(!$page->color) $page->color = 'green'. You can also select with color=,... , but if I want to inherit this value I am lost. So something like "inherit value from parent(s)" would be nice. If a parent has color = blue, the selector for color=blue should also find the children of that page with that value.

[Pete]

Well I know I'm only picking holes in your example, but you could do something like this in the template:

echo (!$page->color && !$page->parent->color) > 'green' : $page->parent->color;

That would of course only check one level up the tree rather than going all the way up until it found a value though.

[Joss]

Hi

I know this is an old topic, but I was just searching for this.

A default value for me is, as someone mentioned above, a pre-filled value that will be used if you don't replace it with anything.

For instance, I have a field that asks for a "span" value for a box. If it is not filled in, I want it to default to 4.

Now, I can easily achieve this in the template, but the problem is that the user cannot see that it defaults to 4 - so having the field pre-filled not only gives me a starting value, but also informs the user.

Joss

[ethanbeyer]

On 1/2/2013 at 6:04 PM, Joss said:

I know this is an old topic, but I was just searching for this.

A default value for me is, as someone mentioned above, a pre-filled value that will be used if you don't replace it with anything.

For instance, I have a field that asks for a "span" value for a box. If it is not filled in, I want it to default to 4.

Now, I can easily achieve this in the template, but the problem is that the user cannot see that it defaults to 4 - so having the field pre-filled not only gives me a starting value, but also informs the user.

Joss

Hey! New to ProcessWire but I am *loving* its flexibility and extensibility! Thanks for all the work on it.

I just wanted to swing by this discussion and see if there was any chance that default values had been reconsidered? I'm looking for a way to do exactly what @Joss stated above.

[adrian]

Hi @ethfun - welcome to PW!

We do have default values now for certain fields. I don't recall all of them, but definitely for Integer, which should work if you are looking for a span value like in Joss' post.

 

Of course if you need another fieldtype, you can always just do this in your template code:

$value = $page->fieldname ?: 4

 

[Juergen]

If you need a default (pre-filled) value for a field you can also use a hook to populate this field before the page is rendered.

[ethanbeyer]

Thanks, @adrian and @Juergen! I'll look into the Hook option - I need to do it for some text fields.

I'll report back if I'm having any trouble.

E

[desbest]

Any update on having a default value for checkbox fields?

[abdus]

26 minutes ago, desbest said:

Any update on having a default value for checkbox fields?

For `value`, you can just set `value` attribute. But for `checked`, you need to set `checked` attribute.

If you're using API to create inputs, then you can set `checked` property and generated HTML will omit checked attribute accordingly

$checkbox->checked = false;
<input type=checkbox />

$checkbox->checked = true;
<input type=checkbox checked=true/>

If you're creating inputs manually, then you need to add checked a attribute (any value), or remove it completely for unchecked

<?php
$isChecked = true;
?>
<input type="checkbox" <?= $isChecked ? 'checked=true' : '' =?> />

 

[desbest]

That's not what I meant.

In the Processwire admin panel, you can choose the default value for Integer fields.

 

How can I have the same option for Checkbox fields? For checkbox fields, there is no "Default value" option under the Input tab.

[stuartsa]

On 10/7/2016 at 6:10 PM, Juergen said:

If you need a default (pre-filled) value for a field you can also use a hook to populate this field before the page is rendered.

Are the values $page and $parent set at the time inputField::beforeRender is called? I want to default the value of a numeric field to the max of the page's values for said field among its siblings plus one, or one if the page is an only child. I'm using RockFinder to query the database in the hook.

[dotnetic]

Here is what I did to pre-fill fields with a default value:

// in ready.php or a module add a hook
   $this->wire->addHookBefore(
      "ProcessPageEdit::buildFormContent",
      $this,
      "addDefaultTexts"
    );

public function addDefaultTexts(HookEvent $event)
  {
    $form = $event->return;
    $page = $event->process->getPage();
    bd('editForm, pre-fill fields');
   
    if ($page->nameofthefield == "") {
      $page->nameofthefield = "my default text";
    }
  }