

Add a field in a few clicks and watch it appear in the checkout preview, on a desktop or a phone.
Moved to the WooCommerce Checkout block and your checkout field editor stopped working? Most field editors were built for the old shortcode checkout and cannot reach the new one. Fieldwright was built for the Checkout block from the start.
Fieldwright is a visual checkout field editor for the WooCommerce Checkout block.
It starts with the thing most field plugins still cannot do there: WooCommerce’s own checkout fields. Rename them, switch them off, make them optional or required, and drag them into any order in the same list as the fields you add. The change reaches the browser, every country’s address rules and the Store API, so an optional postcode really is optional and the order goes through.
Then it adds fields of your own. Fourteen types, nine positions on the checkout page, and a live preview of the page beside the editor as you build it.
Answers are shown where you and your customer look for them: on the admin order screen, where you can also edit them, in the order emails, on the order confirmation page, and in the customer’s order history. Each of those can be switched off per field.
No banners and no popups. Fieldwright puts nothing in your dashboard except its own screen: no admin notices, no review prompts. Inside that screen its paid add-on is named in a few places you can read past, one of them a line you can close for good.
Everything described on this page is in this plugin. A separate paid add-on, Fieldwright Pro, adds a file upload field type, conditions, “required when” rules, checkout fees, an orders list column, CSV export of orders with their answers, answers on PDF invoices, default values for WooCommerce’s own fields, date rules including a minimum age, and delivery time slots. It is sold and supported from our own site and is not needed for anything described here.
Your settings are stored as one option and stay exactly as you left them if you deactivate the plugin and come back to it.
It collects nothing, tracks nothing, and answers WordPress’s own export and erasure requests. See “Privacy”.
Built on WooCommerce’s own Additional Checkout Fields API wherever that API can carry a field, so those fields keep working through every WooCommerce update.
Block checkout only. If your store still uses the classic (shortcode) checkout, these fields will not appear there. The builder’s Compatibility tab tells you which checkout your store renders today, and offers a draft copy of the page to try the Checkout block on.
Every field can carry help text, a starting value and a half width layout. Ten ready made fields (delivery instructions, gift message, VAT number and more) are one click away in the builder’s empty state.
Shipping address and Billing address are for a question that belongs to one address and not the other. A required field there is only required when that form is on the customer’s screen, so it cannot block an order placed with one address, or an order that needs no shipping.
WooCommerce’s own checkout fields sit in the same builder outline as the ones you add, so you arrange all of them together instead of guessing where yours will land.
Company, apartment or suite and phone are the three WooCommerce keeps its own settings for, so Fieldwright writes to those settings rather than shadowing them. The Checkout block’s own “Address fields” sidebar, the classic checkout and the builder always show the same thing, and deactivating Fieldwright leaves them exactly as you last set them.
Fieldwright collects nothing for itself. It has no tracking, and it makes no request to any server of ours.
What is stored, and where. Your field configuration is one WordPress option, cbwb_config. An answer a customer types is stored on their order. For the field types WooCommerce carries itself, it is stored the way WooCommerce stores its own: _wc_other/<key>, _wc_billing/<key> or _wc_shipping/<key>. For every other type, Fieldwright stores it as _cbwb/<key> order meta, where <key> is the field key without its cbwb/ prefix. A checkbox group is a comma separated list of the option values, a date is YYYY-MM-DD, and a time is HH:MM. A field type provided by an add-on stores whatever that add-on documents, in the same place. A field set to “Remember for next time” also keeps a copy against the customer’s account as user meta under the same _cbwb/<key> name.
Export and erasure. Fieldwright answers WordPress’s own personal data tools under Tools, filed under the group “Fieldwright fields”. The exporter returns every answer on the customer’s orders and every value remembered against their account. The eraser removes both. Answers are read from the order rather than from the fields you have today, so a field you have since switched off or deleted outright still has its old answers exported and erased. They are listed under the key they are stored as, because a deleted field has no label left to show. An add-on that keeps anything behind one of its values is told when the value is erased, so it can remove that too.
Anonymisation. WooCommerce’s “Remove personal data” bulk action, and its retention schedule, clear Fieldwright’s values from an order along with WooCommerce’s own, on the same terms. WooCommerce’s customer erasure clears the values remembered against an account.
Uninstall. Answers already on your orders are always kept, the way a customer’s address is: a store has to be able to read its own past orders after removing the plugin that collected them. Everything else (your configuration, the values remembered against accounts, and the plugin’s temporary rows) is removed on uninstall when you turn on “Remove all data on uninstall” in the Settings tab.
Fieldwright is built to be extended, and every hook, filter, JavaScript API and REST route it offers is a public contract, documented at https://github.com/devKhairul/fieldwright-checkout-fields/blob/main/docs/developers.md.
Source code. The files in build/ are compiled and minified from the TypeScript and React sources in src/, and both the sources and the build tooling are in that same repository. To rebuild them: npm ci, then npm run build, which runs wp-scripts build.