<p>Something I'd not done with the edit form was replace [new1] with [{{variant.id}}] for the variant inputs. As I said, the form was saving correctly anyway if I changed the date, so I didn't expect correcting these to fix the issue I'd been having.</p>

<p>It turns out that correcting these does in fact fix the issue I was having with saving products with an unchanged custom date field. Here is the corrected template code:</p>

<pre><code>{% if variant is defined %}
  &lt;input type="hidden" name="variants[{{ variant.id }}][unlimitedStock]" value=""&gt;
  &lt;input type="hidden" name="variants[{{ variant.id }}][minQty]" value=""&gt;
  &lt;input type="hidden" name="variants[{{ variant.id }}][maxQty]" value=""&gt;
  &lt;input type="text" value="{{ variant.stock }}" name="variants[{{ variant.id }}][stock]"&gt;
  &lt;input type="text" value="{{ variant.price | number_format(0) }}" name="variants[{{ variant.id }}][price]"&gt;
{% else %}
  &lt;input type="hidden" name="variants[new1][unlimitedStock]" value=""&gt;
  &lt;input type="hidden" name="variants[new1][minQty]" value=""&gt;
  &lt;input type="hidden" name="variants[new1][maxQty]" value=""&gt;
  &lt;input type="text" value="" name="variants[new1][stock]"&gt;
  &lt;input type="text" value="" name="variants[new1][price]"&gt;
{% endif %}
</code></pre>

<p>I'm left wondering whether only having a single default variant allowed still permits new variants to be submitted, which might explain why I wasn't getting any errors? Similarly, I'm not sure why correcting the variant field names fixed the problem I was having with the custom date field not saving when the date wasn't changed.</p>

CC BY-SA 3.0
2016-10-31T14:06:33.163Z
2016-10-31T15:21:57.620Z
2016-10-31T15:21:57.620Z
Clive Portman
<p>When editing an entry (actually it's a product within Craft Commerce but everything seems the same) with a pre-existing date, the field looks like this:</p>

<pre><code>&lt;input name="fields[date][date]" value="06/12/2016"&gt;
</code></pre>

<p>But when re-saving the entry it won't save if I leave the date the same. I'm not getting any errors. If I change the date and re-save the entry, all is fine. Any ideas?</p>

CC BY-SA 3.0
2016-10-27T16:48:09.503Z
I'm guessing some validation error. Is anything coming back from `entry.getErrors()`?
Brad Bell
CC BY-SA 3.0
2016-10-31T13:34:38.917Z
All I'm getting from entry.getErrors() is the date field being blank if I leave it blank. As I'm not leaving it blank, no error is being returned, but it's clearly failing the validation somehow. To be clear, changing the value of the field to 07/12/2016 will save the product. No other changes. But leaving the field value the same will not let the save go through, there are no errors and nothing in the logs.
Clive Portman
<datetime><frontend><saveentry>
Entry not saving when date isn't changed using frontend form
# Entry not saving when date isn't changed using frontend form

(Asked by: username_0 on 2016-10-27)

When editing an entry (actually it's a product within Craft Commerce but everything seems the same) with a pre-existing date, the field looks like this:


But when re-saving the entry it won't save if I leave the date the same. I'm not getting any errors. If I change the date and re-save the entry, all is fine. Any ideas?

**Tags:** datetime, frontend, saveentry
> **Comments:**
> **username_1**: I'm guessing some validation error. Is anything coming back from `entry.getErrors()`?  
> **username_0**: All I'm getting from entry.getErrors() is the date field being blank if I leave it blank. As I'm not leaving it blank, no error is being returned, but it's clearly failing the validation somehow. To be clear, changing the value of the field to 07/12/2016 will save the product. No other changes. But leaving the field value the same will not let the save go through, there are no errors and nothing in the logs.  

---

## 1 answers

### Answer by username_0 on 2016-10-31. Score: 1 | Accepted answer

Something I'd not done with the edit form was replace [new1] with [{{variant.id}}] for the variant inputs. As I said, the form was saving correctly anyway if I changed the date, so I didn't expect correcting these to fix the issue I'd been having.
It turns out that correcting these does in fact fix the issue I was having with saving products with an unchanged custom date field. Here is the corrected template code:
{% if variant is defined %}
  
  
  
  
  
{% else %}
  
  
  
  
  
{% endif %}

I'm left wondering whether only having a single default variant allowed still permits new variants to be submitted, which might explain why I wasn't getting any errors? Similarly, I'm not sure why correcting the variant field names fixed the problem I was having with the custom date field not saving when the date wasn't changed.


---

