Fix misformatted start_date default on new contribution page

[eileenmcnaughton]

Overview

Fix unreleased regression from #11881

see https://lab.civicrm.org/dev/core/issues/263

Before

Start date field does not populate for new contribution page. Bug on save if not set

After

Start date field does populate for new contribution page. Save works

Technical Details

This was overlooked when switching the field to datepicker (preferred) in #11881 . Huge thanks to @MegaphoneJon for finding while in rc - seems that because we were focussed on the handling of various start dates we never tried not setting one.

Comments

@yashodha @MegaphoneJon can one of you review this?

[civibot]

(Standard links)

• If this is your first pull-request for CiviCRM, please browse CONTRIBUTING.md for information about the development and testing processes.
• If you are reviewing this pull-request, you may wish to consult the test sites and the Review Standards (long template, short template).

[MegaphoneJon]

I'll review it - I haven't reviewed many PRs lately.

[eileenmcnaughton]

Thanks @MegaphoneJon - happy to help you with upping your pr-review output :-)

[MegaphoneJon]

@eileenmcnaughton Two issues, one blocking, one not.

First - this avoids the bug, but it will set ANY date to the current date, and not allow a change. You could move the lines up to the beginning of the function, or wrap them in a conditional.

Of course, that still means that contribution pages can no longer have no start date. I can't think of a reason why it would matter if a blank start date is always set to "now" - but it is inconsistent with other fields* thus a (non-blocking) hit to the UX.

• Except submitting a CiviMail, but that has a good reason.

[eileenmcnaughton]

@MegaphoneJon try the updated version - it should only be set for new not for existing - that is consistent with previous behaviour from what I can see

[MegaphoneJon]

@eileenmcnaughton This restores the original bug. I did a quick debug session - when you create a new contribution page, $defaults['start_date'] seems to default to a m/d/Y date format, even though none is displayed in the datepicker - probably because that's the wrong format for the datepicker.

[eileenmcnaughton]

ug - that doesn't look like my latest cut - it should be

if (!$this-_id) {
   $defaults['start_date'] = date('Y-m-d H:i:s');
   unset($defaults['start_time']);

}

will fix

[eileenmcnaughton]

Well - that assumes it is not mis-formttatting any results loaded from $this->_values

[MegaphoneJon]

I tested this with a number of permutations and was unable to get unexpected behavior/crashes. OK to merge.

[eileenmcnaughton]

thanks @MegaphoneJon