API create_customer drops date custom fields (double date parse)

[alllexandrz]

Impacted plugin

Jetpack

Quick summary

Contact date custom fields are not saved when creating/updating a contact via the CRM REST/API create_customer endpoint, even when a valid Y-m-d value is sent and the API response looks successful.

Root cause: the date is converted to a Unix timestamp once in api/create_customer.php, then converted again inside zeroBS_addUpdateCustomer() → zeroBS_buildContactMeta(). The second pass expects Y-m-d, receives a timestamp string, fails parsing (false), and removeEmpties=true strips the field before save.

Steps to reproduce

In Jetpack CRM → Settings → Custom Fields, create a Contact custom field of type Date (example label: Contract Date, slug e.g. contract-date).

Enable the CRM API and note the API key/secret.

POST to the create/update customer API endpoint with JSON similar to:

{
"email": "apitest-date-cf@example.com",
"fname": "API",
"lname": "DateTest",
"status": "Customer",
"contract-date": "2026-07-23"
}

Confirm the API response returns success / echoes the payload (including the date).

Open the contact in CRM admin, or fetch via the customers API (withCustomFields is enabled there), or query wp_zbs_customfields for the contact.

Expected

contract-date is stored as a Unix timestamp (UTS) and shown as 2026-07-23 in the contact UI / API read responses.

Actual

The contact is created/updated, but the date custom field is missing/empty. The create endpoint response is misleading because it returns the request payload, not the persisted custom-field state.

Technical root cause

Pass 1 — api/create_customer.php

$customer_array = zeroBS_buildContactMeta( $new_customer, array(), '', 'zbsc_', $remove_empties, $autogen_autonumbers );

Input key: contract-date = "2026-07-23"

Date branch in zeroBS_buildObjArr():

case 'date':
$retArray[ $outputPrefix . $fK ] = jpcrm_date_str_to_uts( $safe_text, '!Y-m-d', true );

Result: zbsc_contract-date = e.g. 1784764800 (int UTS)

Pass 2 — zeroBS_addUpdateCustomer() in includes/ZeroBSCRM.DAL3.Helpers.php

$zbsCustomerMeta = zeroBS_buildContactMeta( $cFields, $existingMeta, $metaBuilderPrefix, '', true );

Re-reads zbsc_contract-date (already UTS)

Date branch again runs jpcrm_date_str_to_uts( '1784764800', '!Y-m-d', true )

DateTime::createFromFormat( '!Y-m-d', '1784764800' ) fails → false

With $removeEmpties = true, empty(false) removes the key

addUpdateContact() never receives the custom field value

Same pattern exists for companies (api/create_company.php + zeroBS_addUpdateCompany / shared zeroBS_buildObjArr date handling).

Site owner impact

More than 60% of the total website/platform users

Severity

Critical

What other impact(s) does this issue have?

Platform revenue

If a workaround is available, please outline it here.

Suggested fix

One of:

Skip re-normalization for already-parsed UTS in the date case of zeroBS_buildObjArr():

case 'date':
$raw = $arraySource[ $fieldPrefix . $fK ];
if ( is_numeric( $raw ) ) {
$retArray[ $outputPrefix . $fK ] = (int) $raw;
break;
}
$safe_text = sanitize_text_field( $raw );
$retArray[ $outputPrefix . $fK ] = jpcrm_date_str_to_uts( $safe_text, '!Y-m-d', true );
break;

Or stop calling zeroBS_buildContactMeta twice in the API → zeroBS_addUpdateCustomer path (pass already-built meta through, or only sanitize once).

Add a regression test: API create contact with a date custom field, assert custom field row exists with expected UTS.

Platform (Simple and/or Atomic)

Self-hosted

[donnchawp]

This was generated by AI during triage.

Agent Brief

Category: bug
Summary: Make the date and datetime normalisation in the shared object-array builder idempotent, so custom date fields survive the API's second normalisation pass.

Current behavior:

The shared "build object array" helper (zeroBS_buildObjArr, reached via zeroBS_buildContactMeta / zeroBS_buildCompanyMeta) converts a date custom field from a Y-m-d string to a Unix timestamp, and a datetime field from a locale-formatted string to a UTS. Neither conversion can read its own output: given a value that is already a UTS, the underlying DateTime::createFromFormat call fails and the helper returns false.

The contact and company create/update API endpoints normalise the incoming payload once, then hand the already-normalised array to zeroBS_addUpdateCustomer / zeroBS_addUpdateCompany, which normalise it a second time with removeEmpties enabled. On that second pass the timestamp fails to parse, becomes false, and the empty-stripping step drops the key entirely — so the field never reaches the DAL and no custom-field row is written.

The endpoint still reports success, because the create responses echo the request payload rather than the persisted record. The reporter confirmed this end to end; the code path has been verified by reading it, and DateTime::createFromFormat('!Y-m-d', '<uts>') returning false was confirmed directly.

The admin UI is unaffected — it normalises once and passes straight to the DAL.

Desired behavior:

Normalising an already-normalised value is a no-op. Concretely, for both the date and datetime field types in the shared builder:

• A value that is already a UTS passes through unchanged (as an integer).
• A Y-m-d string (for date) or a locale-formatted datetime string (for datetime) parses to a UTS exactly as it does today.
• An unparseable value continues to behave as it does today — this is not a change to error handling.

Applying the builder twice to the same input must produce the same result as applying it once.

Key interfaces:

• zeroBS_buildObjArr() — the date and datetime branches of its field-type switch. This is the single shared code path for contacts, companies, transactions, invoices, quotes and tasks, so one fix covers every object type.
• jpcrm_date_str_to_uts() and zeroBSCRM_locale_dateToUTS() — the two conversion functions that return false on unparseable input. Decide whether the guard belongs in the callers or in these functions; if you change them, check every caller, since some rely on the false return to detect bad input.
• zeroBS_addUpdateCustomer() / zeroBS_addUpdateCompany() — the second normalisation pass. Leave their structure alone (see Out of scope); they are context for why idempotency is the requirement.

One judgement call to make deliberately: a naive is_numeric() guard also captures short numeric strings, so a date custom field legitimately submitted as "2026" would be read as a timestamp in 1970 rather than failing to parse. Pick a check that distinguishes a plausible timestamp from a short numeric string, and state the rule you chose in the PR description.

Acceptance criteria:

• Creating a contact through the API with a date custom field set to a Y-m-d value writes a custom-field row holding the expected UTS, and the value reads back correctly from the contact API and the admin UI.
• The same holds for creating a company through the API with a date custom field.
• The same holds for a datetime custom field on both object types.
• Updating an existing contact or company through the API with a date custom field persists the new value.
• Passing an already-normalised UTS directly to the builder returns that timestamp unchanged.
• Existing behaviour for Y-m-d input, empty input, and unparseable input is unchanged.
• Regression tests cover a contact and a company created through the add/update path with a date custom field, asserting the stored custom-field value equals the expected UTS. The repo's WP integration test base class and the existing entity tests are the model to follow.
• The admin UI create/edit path for contacts and companies still saves date custom fields correctly.

Out of scope:

• Restructuring the double-normalisation itself. Passing pre-built meta through, or normalising only once in the API path, is the wider fix — but zeroBS_addUpdateCustomer is called by many integrations that pass raw, un-normalised fields, so changing its contract has a far larger blast radius than making the conversion idempotent. Fix the idempotency; leave the double call in place.
• Changing the create endpoints to return the persisted record instead of echoing the request payload. That is the reason the bug went unnoticed and it is worth doing, but it is an API response-shape change and belongs in its own issue.
• Any change to the other field-type branches in the builder (price, numberint, checkbox, autonumber); they are already idempotent or out of scope here.
• Date handling in import, sync, or form-capture paths beyond what the shared builder change covers.

[donnchawp]

This was generated by AI during triage.

Split out the response-shape concern noted in the agent brief: #22. Not a blocker for this fix.