Allow customers to change their field values
Last updated
Last updated
This feature is deprecated. It is no longer actively maintained and we only provide support for existing implementations created before November 2021. If you need to create forms with support for customer Metafields, we highly recommend using Helium's app. Follow the link for a 20% partnership discount
This article contains information about:
Enabling customers to edit the information stored about them in custom fields
Creating a customer account with or without custom fields
How to set up HTML elements for different ACF field types, including file upload
How to handle repeatable fields
How to use the ACF proxy for form submission
To create a form for editing an existing customer's custom fields, you must include a hidden field with the name "customer[id]" and set its value to that of the logged-in customer via {{ customer.id }}
Each form element linked to a custom field must be named "metafield[ namespace.fieldname]". The namespace must be included even if you just use the default "accentuate".
In addition to custom fields, you can provide these fields as well to have them updated in Shopify:
customer[email]
customer[first_name]
customer[last_name]
customer[email_marketing_consent] (defaults to false*)
customer[sms_marketing_consent] (defaults to false*)
customer[phone]
customer[tags]
customer[password] and customer[password_confirmation] (both must come together and have matching values)
The procedure here is exactly the same as above for customer custom fields, except that you must use a hidden field with the name "order[id]" and set its value to that of the relevant order via {{ order.id }}. Having an "order[id]" field present in the form switches the scope of any provided custom fields to orders.
ACF can create new customer accounts on form submission AND update any provided custom fields after the fact. To do this, set the value of "customer[id]" to an empty string and include at least one of these fields as well:
customer[email]
customer[first_name] and/or customer[last_name]
Optional fields for customer creation include:
customer[verified_email] (default to false*)
customer[send_email_invite] (defaults to false*)
customer[password] and customer[password_confirmation] (both must come together and have matching values)
customer[send_email_welcome] (defaults to false*)
customer[email_marketing_consent] (defaults to false*)
customer[sms_marketing_consent] (defaults to false*)
customer[phone]
customer[tags]
This form example highlights some different ways to provide values for custom fields Please note:
For fields where you need to send multiple values, define them as form "arrays", i.e. "metafield[ namespace.fieldname][ ]" (note the closing [ ]'s)
If you use checkboxes to have your customer select one or more values for a Selection or Tags type field, be sure to include each field's value as a "data-option-value" attribute.
Now, you may be wondering how you are going to keep your form's selection lists in sync with the allowed values defined for the field. Getting to those values is possible using special ACF Metafields. Please see the related article on Liquid access to field definitions. Armed with this information, you can loop over the defined "preferred_color" values in Liquid like this:
If you need your form input to add values to a repeatable field (e.g. register a newly bought product to an existing list of bought products) rather than overwriting the value, add this option to your form:
Similarly, if you need your form input to remove values from a repeatable field (e.g. remove an element from a list) rather than overwriting the value, add this option to your form:
There is also an option to have ACF split text values to multiple values based on a split character defined by you. Say you want your customer to input a comma-separated list of values but you'd like this to be stored as individual elements of a repeatable field in ACF, you can add the below option to your form. If this is present, ACF will automatically split any non-array form values targeted for repeatable fields by the provided split character:
You can remove a set of repeatable field values that "belong" together (like "pet_name" and "pet_date_of_birth" for a customer's list of registered pets) by defining them inside the same repeatable section in ACF, like this:
Then, in your form, provide a special field options.remove.id that points out the Metafield that contains the value to be removed:
In your theme.liquid file, near the closing </body> tag, be sure to include the ACF proxy script and one line of code to bind your form to the proxy.
The Accentuate proxy script depends on jQuery to work, so make sure jQuery is loaded separately before the proxy script is invoked The proxy script sets up a handler for the form submission but does not actually submit the form. This is up to you, either by using a standard submit button or by calling the form's .submit() method via Javascript
Adjust the above selector of the form - jQuery("#metafields_form") - to match your actual code. Accentuate will automatically handle the form submission and determine the endpoint target for the form submission - therefore you don't need to define METHOD or ACTION attributes on the form itself (and they will be ignored, if present). The "Accentuate()" function takes two optional parameters: The first optional parameter is a callback function where you can take action after updates have been submitted to ACF. This callback is served with a "data" object containing the below properties, which you can use for inspecting whether the update succeeded or not, and which:
data.status
will contain either "OK" or "ERROR"
data.message
will contain a related message with details
data.errors
in case of status = "ERROR", this will contain an object structure highlighting which parts of the request failed, e.g. { email: ["is already taken"], phone: ["is invalid"] } Here is a simple example, where the results are just logged to the browser's console:
If your form contains file uploads (input type="file"), the file uploads are handled separately from the rest of the form's fields. This is handled automatically by the proxy script but you will experience that the callback function (if defined) is called twice, once for any files and once for all other fields The second optional parameter is a callback function where you can validate your form prior to submitting it to ACF's handling. If you return false from the validation callback, the form will not be submitted. Any other value than false will allow for form submission. Example of a validation function that checks for a non-zero length of a field with an id of "myfield":
customer[address.property] (where property is one of the valid address properties listed ). When referencing an [address.property] you must always include the address id via [address.id] (for example {{ customer.default_address.id }})
ACF will automatically determine the index of the provided value ("Fido") within the existing value of "_name" and remove any other values at that index for the section's other fields (in this example "pet_date_of_birth" as well).
Preferably the points to something reasonably unique - ACF will determine the index from the first occurrence of the field's value matching the provided value. Consider providing an id in a separate field to store a unique id, e.g. a GUID