Extra Properties de PrestaShop 9.2: elegir el modelo de datos adecuado

Un campo adicional es fácil de pedir y sorprendentemente difícil de definir bien. Un comerciante solicita una «referencia de proveedor», pero la agencia aún debe saber si pertenece a un producto, una combinación, un pedido o una relación con un proveedor. Una respuesta equivocada crea ambigüedad allí donde se reutiliza el valor.

PrestaShop 9.2 presenta Extra Properties como mecanismo nativo de extensión. La explicación oficial describe definiciones de campos con espacios de nombres, tipos, valores predeterminados, validación y ajustes de visibilidad. Identifica entidades como Product, Combination, Customer y Order. Introducción a Extra Properties.

Para la RC1 disponible el 26 de septiembre de 2026, trata la adopción como un ejercicio de diseño en preproducción. Los ejemplos siguientes explican cómo decidir qué pertenece a una propiedad; no afirman que ya se haya migrado una tienda de ejemplo.

Una vez que la responsabilidad y el ámbito del campo estén claros, utiliza el flujo de integración del módulo Extra Properties para seguir el valor a través del registro, los formularios, la persistencia y el acceso a la API.

Empezar por el hecho, no por el campo del formulario

Una propiedad útil registra un hecho sobre una entidad identificable. Antes de elegir un widget, escribe una frase que describa ese hecho: «Este producto tiene esta clase interna de manipulación» o «Este pedido tiene esta referencia externa de conciliación».

Después pregunta cuándo cambia ese hecho. Una clase de manipulación del catálogo puede cambiar al cambiar el embalaje del producto. Un sistema externo puede asignar una referencia de pedido una vez y esta permanecer fija. Una preferencia del cliente puede cambiar con frecuencia. Distintos ciclos de vida implican distintos responsables y reglas de validación.

Evita nombres vagos como extra_info. Invitan a mezclar varios significados sin relación en un mismo valor. Una propiedad llamada packing_instruction ofrece a los responsables del mantenimiento un contrato más claro, aunque aún hay que definir su formato exacto y contenido permitido.

Los espacios de nombres también importan operativamente. Dos módulos pueden hablar de una «referencia» pero referirse a identificadores distintos. Mantén visibles los responsables de negocio y técnicos. Si se reemplaza un módulo, el equipo debe saber qué valores transferir y cuáles están obsoletos.

El mecanismo nativo de extensión puede reducir el trabajo repetido de infraestructura. No puede decidir qué significan los datos de un comerciante.

Elegir la entidad que siga siendo correcta con el tiempo

Considera una tienda que vende un producto en varias tallas. Una instrucción de manipulación compartida por todas puede pertenecer al producto. Un código que identifique la talla concreta de un proveedor puede pertenecer a la combinación o a un modelo de relación separado. Colocar ambos en el producto puede hacer que las exportaciones parezcan correctas hasta que se introduzca la segunda talla.

Los pedidos introducen una cuestión temporal. Si un valor describe lo vendido en el momento de la compra, leer la propiedad actual del producto meses después puede dar una respuesta histórica incorrecta. Decide si el pedido necesita una instantánea, una referencia a un registro externo duradero o ninguna copia.

No debe utilizarse una propiedad a nivel de cliente solo porque se haya recogido un valor de un cliente. Una instrucción de entrega para una compra podría pertenecer a una dirección o a un pedido. De lo contrario, la siguiente compra puede heredar un valor que el cliente nunca quiso reutilizar.

Utiliza esta breve entrevista de modelado:

La entrevista debe hacerse antes del desarrollo. Un campo rápido de añadir puede resultar caro de interpretar después.

El ámbito de tienda y el de idioma responden a preguntas distintas

Una etiqueta traducida no es lo mismo que un valor traducido. La etiqueta del campo puede necesitar aparecer en varios idiomas del personal mientras el valor guardado es un único código interno. En cambio, una instrucción dirigida al cliente puede requerir un valor separado por cada idioma del escaparate.

El ámbito de tienda describe dónde difieren los valores comercial u operativamente. Dos tiendas pueden compartir un producto pero usar instrucciones de preparación distintas. No es un problema de traducción. Dar a las tiendas idiomas diferentes solo para distinguir sus valores ocultaría el modelo de datos real.

Separa también la disponibilidad del campo de la variación del valor. Una propiedad puede ser relevante solo para determinadas tiendas. Dentro de ellas, su valor puede seguir siendo común o específico de tienda según la definición admitida. El trabajo de 9.2 incluye restringir definiciones de propiedades a una lista de tiendas; es una cuestión separada de decidir cómo varía un valor. Definiciones restringidas por tienda.

No supongas que todas las combinaciones de ámbito se admiten igual en cada entidad y superficie de integración. Comprueba la implementación actual de la entidad que planeas ampliar. Una descripción general de la función no sustituye una pequeña prueba del modelo exacto.

Utiliza valores de prueba deliberadamente distintos al evaluar el ámbito. Si ambas tiendas contienen «Estándar», un valor compartido accidentalmente puede pasar inadvertido. Valores distintos revelan si un guardado, lectura o exportación utilizó el contexto previsto.

La visibilidad es una decisión de datos, no de estilo

Un comerciante puede querer un campo en un formulario administrativo sin quererlo en el escaparate. Una integración puede necesitar un valor que nunca debe aparecer en una plantilla de producto. Decide ambas cosas por separado.

La introducción oficial explica que las Extra Properties de la API se agrupan bajo el espacio de nombres de su módulo y heredan los permisos de la entidad principal. Esto significa que una capacidad de API no debe tratarse como un límite independiente de confidencialidad a nivel de campo. Comportamiento de la API en la explicación de la función.

Para una instrucción interna, inspecciona todos los consumidores previstos y no previstos: formulario, tabla, respuesta de API, datos del escaparate y módulos de exportación. Ocultar una columna no demuestra que el valor no pueda leerse en otro lugar.

Ten especial cuidado con valores que contengan notas sensibles para el negocio o datos personales. La respuesta correcta puede ser un diseño más especializado de almacenamiento y autorización. Un sistema general de campos personalizados no debe convertirse automáticamente en un repositorio de información que exija acceso más estricto que su entidad principal.

Para valores públicos, decide si son texto plano, una opción limitada, una URL o contenido enriquecido. El tratamiento de salida debe corresponder al tipo. Un valor editable en el Back Office puede seguir necesitando escape al mostrarse en el escaparate.

Los valores predeterminados, vacíos y únicos necesitan significados explícitos

A menudo hay al menos tres estados: desconocido, deliberadamente vacío y un valor significativo. Un valor predeterminado puede fusionarlos accidentalmente. Si cada producto importado recibe «Estándar» porque el proveedor omitió el campo, el personal puede confundir la ausencia de información con una clasificación verificada.

Escribe el comportamiento previsto para registros antiguos, nuevos y valores borrados. Un campo obligatorio también necesita un plan para entidades existentes anteriores al requisito. Sin él, una edición ordinaria puede quedar bloqueada por una restricción nueva.

La unicidad debe corresponder al dominio del negocio. Un identificador externo puede ser único dentro de un proveedor o tienda, no en toda la instalación. Una suposición de unicidad global puede rechazar registros legítimos o animar al personal a alterar identificadores solo para guardar un formulario.

Los valores predeterminados y las restricciones deben apoyar el contrato de datos, no compensar uno poco claro. Pruébalos mediante todas las vías de escritura admitidas, incluida la API si está expuesta. Un widget de formulario no es el único lugar por donde entra un valor en el sistema.

Algunos datos pertenecen a un modelo separado

Extra Properties es un buen candidato para un pequeño número de atributos bien definidos ligados a registros existentes. Es menos adecuado como modelo completo de una secuencia de eventos, una relación de muchos a muchos o un flujo que requiera permisos y transacciones propios.

La categoría de almacenamiento de un producto es un atributo plausible. Un registro de cada movimiento de almacén es un historial de eventos. La referencia externa de un pedido es un atributo plausible. Un proceso completo de conciliación con intentos, errores y aprobaciones es un flujo de trabajo.

Evita meter documentos JSON grandes y opacos en una propiedad solo para evitar diseñar las relaciones. Un valor estructurado puede ser adecuado para un propósito limitado, pero un documento sin límites dificulta buscar, validar y migrar. Pregunta cómo un operador inspeccionaría y repararía un elemento incorrecto.

Asimismo, distingue los datos fuente de los valores derivados. Si un valor puede calcularse de forma fiable a partir de registros existentes, guardar otra copia crea una obligación de sincronización. Puede estar justificado, pero debe ser deliberado.

Para una propuesta de campo, exige un ejemplo concreto y un contraejemplo. «La referencia de conciliación de un pedido» es el ejemplo; «el historial completo de intentos de conciliación» es el contraejemplo. Esta pequeña distinción ayuda a futuros responsables a conservar el límite original cuando lleguen nuevas peticiones.

Acordar la responsabilidad antes de guardar el primer valor real

Crea una pequeña especificación del campo con entidad, espacio de nombres, tipo, ámbito, valor predeterminado, escritor, lectores y política de eliminación. Incluye una frase que describa para qué no debe utilizarse nunca.

Por ejemplo, una clase interna de manipulación podría pertenecer al equipo de catálogo, escribirse mediante una importación controlada y leerse en la preparación de pedidos. Las ediciones manuales podrían permitirse solo si la siguiente importación las conserva. Si no se define esa excepción, la integración y el personal sobrescribirán mutuamente sus cambios.

Planifica también el reemplazo y la desinstalación. Desactivar un módulo, quitar su definición y borrar sus datos guardados son operaciones distintas. El módulo oficial de ejemplo demuestra opciones destructivas de eliminación que no deben copiarse ciegamente en una política comercial de conservación de datos. Módulo oficial de ejemplo.

Un buen diseño de Extra Properties empieza por un hecho pequeño y preciso y lo sigue durante toda su vida. Cuando la responsabilidad, el ámbito y la visibilidad están claros, el desarrollador puede implementar el campo sin tomar esas decisiones de negocio de forma implícita en el código.

Para conocer el contexto de la plataforma, consulta nuestra guía de desarrollo de módulos de PrestaShop 9 y aplica las comprobaciones específicas de versión anteriores a la instalación que estás evaluando.