14 replies to this topic

[pers0n]

Sorry if this has been mentioned before.

I'd like to be able to set certain fields in a template to be required, meaning they cannot be left blank.

[Soma]

Turn on advanced mode in your site config.php, then in the field settings you see additional setting, though "required" is only working for text fields I think.

[onjegolders]

Thanks Soma, I was just about to ask for this feature. For such an advanced system it seems strange not to have a "required' feature for fields. Is there any reason this is hidden by default?

Also would be interested in a feature to limit characters for a field (ie: summary fields should only be 256 characters). I know this can be done in the code but I'd really like the user to be told to resubmit his summary if it is too long.

My apologies, don't think I have my head switched on today! Of course you can limit characters on a text field.

Would still be very interested in the required thing though....

Edited by onjegolders, 04 June 2012 - 04:20 AM.

[ryan]

Proper required fields aren't quite as easy as they sound in ProcessWire. There are some problematic scenarios. For instance, what if you edit a published page, make a bunch of edits and leave a required field blank. When you save, if there is a missing required field, then logically the save should be aborted. But any other changes you made that were valid would also have to be aborted, otherwise we'd have a page in a partially saved state (which is not possible). A page can't be in two states at once. And if we're saying we support real required fields, we can't have a published page in the system in a state where one of the required fields is blank. So the required field support you see in PW right now is not much more than symbolic, because the page can still exist without a required field populated. PW will complain and give you errors telling you about it, but it can still exist.

Real required field support means letting a copy of a given page exist in some unpublished/draft state, until the requirements are met. Once the requirements are met, it can replace the published page. Until versioning is built in, making this happen is overly complex. So until that happens, any required field support will likely just be symbolic required field support via javascript or PW error messages. People will still want to code their templates to account for empty value situations, even on required fields. That's the primary reason why the 'required' option is hidden in advanced mode, because I don't want to imply that you can always expect some field to always be populated.

Another scenario that not even versioning can fix: lets say you have a site with a bunch of active pages in it. You add a new field to a heavily used template and make it 'required'. All the existing pages will have an empty required field. It's a tricky situation. The expectation of required fields seems to open more potential for site-breaking situations. Better to code things as if required fields didn't exist.

[onjegolders]

Proper required fields aren't quite as easy as they sound in ProcessWire. There are some problematic scenarios. For instance, what if you edit a published page, make a bunch of edits and leave a required field blank. When you save, if there is a missing required field, then logically the save should be aborted. But any other changes you made that were valid would also have to be aborted, otherwise we'd have a page in a partially saved state (which is not possible). A page can't be in two states at once. And if we're saying we support real required fields, we can't have a published page in the system in a state where one of the required fields is blank. So the required field support you see in PW right now is not much more than symbolic, because the page can still exist without a required field populated. PW will complain and give you errors telling you about it, but it can still exist.

Real required field support means letting a copy of a given page exist in some unpublished/draft state, until the requirements are met. Once the requirements are met, it can replace the published page. Until versioning is built in, making this happen is overly complex. So until that happens, any required field support will likely just be symbolic required field support via javascript or PW error messages. People will still want to code their templates to account for empty value situations, even on required fields. That's the primary reason why the 'required' option is hidden in advanced mode, because I don't want to imply that you can always expect some field to always be populated.

Another scenario that not even versioning can fix: lets say you have a site with a bunch of active pages in it. You add a new field to a heavily used template and make it 'required'. All the existing pages will have an empty required field. It's a tricky situation. The expectation of required fields seems to open more potential for site-breaking situations. Better to code things as if required fields didn't exist.

OK thanks for taking the time to explain that!
I think allowing for empty fields will make me a better coder in the long run anyway!

[JeffS]

The less complicated solution to this problem is to use javascript and hook into the system on before save (not familiar with PW internals yet). MODx approached this in the evolution build with a module that used a simple text config file which could have field by field options by template in the backend, such as required or even replacing the label text. Worked well for the intended purpose of "helping" publisher/editors.

I will need to dig deeper into the backend to see what's available.

[ryan]

JS is certainly an easy way to accomplish it for helping the editors. It's more the developers I'm worried about, coding in a manner that expects a field to always be populated, when it may not be technically possible for that to always be the case. But if it's just helping the editors that we need, then that's no problem: there are no technical challenges there.

[thomas]

I just built a module that adds a "addHookBefore('save' ...) Hook and the checks the inputs I want to be required. If the requirements aren't met, there's an error and I set $page->addStatus(Page::statusUnpublished); ...
This seems to work great so far. Is there anything I'm missing? (since this method isn't mentioned here ...)

[ryan]

Sounds good to me. Though something to consider is that you may be unpublishing a live page from the site, which could be undesirable in many situations. Depending on the situation, it may be better to save the page and notify the editor of the error rather than fully unpublishing it.

[thomas]

Yeah, I thought about that but these people don't learn unless there's consequences.
I did have to built a rather dirty hack to get through the "add page" dialogue, though. So my method isn't too sophisticated.

[Soma]

Maybe I'm missing something, but currently in latest PW you can set all fields to "required" built in.

[ryan]

I figured we were talking about some condition other than required? But if that's the case, Soma is right that this is built in. However, it's not going to unpublish a page if you leave a required field empty. Though it won't publish an unpublished page that has a missing required field.

[thomas]

Hm ... I remember trying it (that is "advanced", right?) but it didn't work for fieldtypes Pages and Image, which is what I needed. I'll try again, although on my sites unpublishing a page is better than publishing one without a teaser image, for instance. And as I said, my editors won't learn.
Thanks!
t

[Soma]

Actually it's now in there without advanced. And it should work for all fields I think.

[thomas]

Cool. I just updated and now it works. Cheers.