-1

This is a general question, but based on a specific situation. In Commerce the standard way of customising a product AFAIK is to use Commerce Customizable Products. It allows you to create different bundles of the line_item entity and configure certain fields to be used on the add-to-cart form. A typical example would be a customisable message being implemented as a text field. When you add the product to your cart, a new line item is created and that's what's actually associated with your order.

While considering another Q I thought it made sense to have the option to fill out the form at checkout time. It would be useful to have required fields, but that would mean that when the line item is created these required fields are empty. AFAICT core doesn't enforce required fields when saving entities programatically. field_default_validate() just checks cardinality. (And a quick test creating a node without required fields populated seems to bear this out.) It seems like the required attribute is only for the UI.

One potential problem occurs if users have access to the entity edit form. Imagine you want to change the title of a node, you edit it, and then you have to fill in all the required fields as well before you can save. But in some cases (like line_item) users typically don't have general access to an entity edit form. So in this situation is it icky to create an entity without its required fields? Is there any precedent? Can anyone see any other pitfalls?

  • 2
    i think it might be a bit broad question... especially the part about pitfalls. One I can see are export/import issues. If importer module tests for required fields (and many, if not most, do), then you will not be able to export your entities and re-import them, so restoring checkouts from backup without restoring whole site will be painful. – Mołot Aug 4 '14 at 11:35
  • +1 for migrations, good point thanks. I think it might be one of those questions where you don't know if it's broad until you know the answer (: If it turns out that it's been discussed and is not advised for reasons X, Y and Z then it's got a simple answer. But I understand it might not be clear-cut! – Andy Aug 4 '14 at 11:43
2

Yes, it is wrong. If you will mark some fields as required, other modules will be free to assume they are / need to be filled. So migration of your entities may fail, and it will be your fault.


More philosophically, remember robustness principle:

Be conservative in what you send, be liberal in what you accept

That's what Drupal does, accepting your incomplete entities. But you shouldn't send them to Drupal incomplete.

RFC 1122 and RFC 3117 are telling you basically the same thing if you want to transmit your entities over the Internet. They don't tell you what to do internally, of course, but I believe it is a good practice to store internal data in a robust, standard-compatible, ready to be transmitted shape.

| improve this answer | |
  • Thanks for your thoughts. I just did the example migration from the migrate module with an empty required field and it imported fine. It seems strange to me that core would allow a semantically required field to be empty, given that there's all sorts of other ways to fail validation (and if required is supposed to mean that, I'd personally feel safer with a core that enforced it). So I wonder if required only means present a required widget... – Andy Aug 4 '14 at 14:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.