Un campo propio afecta más que el diseño: se renderiza en el navegador, valida en PHP, guarda en el pedido y quizá se envía a emails o sistemas externos. Un fallo puede detener la compra o crearla sin información necesaria.
Conserva el valor sintético fallido y la hora. No elimines el campo hasta saber si lo necesitan logística, impuestos o cumplimiento.
Determina dónde se detiene
Envía una vez con datos controlados e inspecciona la petición. Comprueba si WooCommerce crea pedido antes del error.
Sin pedido y con mensaje de validación apunta al campo. Un 500 apunta a PHP. Un pedido existente sin dato indica fallo de guardado o visualización, no de creación.
Consulta la pasarela antes de repetir un pago real.
Inspecciona la definición
El input necesita clave estable, tipo apropiado, etiqueta y condición de obligatoriedad. Su name debe coincidir con la clave leída por PHP.
$value = isset( $_POST['delivery_note'] )
? sanitize_textarea_field( wp_unslash( $_POST['delivery_note'] ) )
: '';El ejemplo solo sirve para texto plano. Fechas, checkboxes, identificadores y estructuras necesitan validación específica.
No confíes en un hidden: el cliente puede modificarlo.
Revisa callbacks de validación
Localiza cada hook y su prioridad. Debe manejar campo ausente, vacío, array o tipo inesperado sin fatal.
Las condiciones deben usar valores POST actuales. Una instrucción quizá solo sea obligatoria con cierto transporte; comparar un ID antiguo o una etiqueta traducida puede rechazar todo.
Muestra un error útil al cliente y guarda detalles técnicos sin contenidos sensibles.
Comprueba HPOS
Con High-Performance Order Storage, el código debe usar las API de pedidos y hooks compatibles, no asumir que postmeta es el modelo principal.
$order->update_meta_data( '_delivery_note', $value );
// Guardar en el ciclo de vida previsto por el hook elegido.No llames save() repetidamente dentro de loops o fases tempranas. Confirma que el hook proporciona un objeto válido y se ejecuta una vez.
Prueba la compatibilidad declarada por la extensión.
Ensaya valores válidos poco habituales
Prueba un opcional vacío, acentos, apóstrofos, longitud máxima y autocompletado móvil. Una columna, API o expresión regular estricta puede fallar solo con ciertos valores.
Define un límite visible. No trunques silenciosamente información necesaria para preparar el pedido.
Si sube archivos o contiene datos personales, aplica controles de tipo, acceso y conservación.
Inspecciona las integraciones
CRM, transporte, facturas y email pueden asumir que el campo siempre existe. Un timeout remoto no debería dejar al cliente mirando un spinner después del pago.
Separa la validación síncrona esencial del trabajo que puede ejecutarse tras crear el pedido. Encola exportaciones no críticas y alerta al administrador sobre fallos.
Relaciona Action Scheduler y logs con el ID sintético.
Haz que los reintentos sean idempotentes. Si la API externa agota el tiempo después de aceptar el dato, repetir el checkout no debe crear dos envíos, dos reservas o dos etiquetas. Guarda un identificador seguro del resultado y reconcilia el estado sin bloquear al comprador.
Aísla sin perder la regla de negocio
Reproduce en staging con el mismo checkout y modo de almacenamiento. Desactiva solo el componente o callback implicado y acota entre renderizado, validación y guardado.
Un bypass temporal en producción requiere aprobación si el dato es operativo. Documenta cómo lo recogerá el personal y cuándo se restaurará.
No modifiques WooCommerce core.
Publica y verifica
Corrige clave, saneado, condición, hook o uso de la API. Añade una prueba de regresión para el valor exacto que fallaba.
Completa pedidos de invitado y cliente con transportes y pagos pertinentes. Confirma un pago, visibilidad solo para personal autorizado, emails correctos y recepción por logística.
Comprueba también edición administrativa, reembolsos y exportaciones si consumen ese metadato. El valor debe conservar el mismo significado al leerlo desde HPOS, mostrarlo en una plantilla o enviarlo a una integración, sin exponerlo a usuarios no autorizados.
El mantenimiento recurrente debe probar los campos cuando cambien WooCommerce, Checkout Blocks, pasarela o HPOS. Son código de aplicación y necesitan versiones, revisión y monitorización.