WP Product Manager

El problema

Una tienda que revende juegos de consola ponía precio a decenas de miles de artículos tomando como referencia una tienda superior que cambia sus precios constantemente: las rebajas empiezan y terminan sin avisar, y el mismo título cuesta distinto en cada tienda regional. Los precios del escaparate quedaban por tanto obsoletos o equivocados: una revisión manual del catálogo tardaba días y caducaba antes de terminar.

La solución ingenua, pedir el precio a la tienda superior cada vez que carga una ficha, es peor. Una página de catálogo con treinta productos se convierte en treinta llamadas salientes, la carga se desploma y una respuesta lenta del origen se lleva la tienda por delante.

Antes → Después

Antes	Después
Precios corregidos a mano, días por detrás del origen	Precios traídos de la tienda superior y actualizados solos
El precio de una región aplicado a todo	Se recogen y comparan todos los precios regionales disponibles
Qué precio cobrar era una decisión humana por producto	Una estrategia de precios, elegida una vez para todo el catálogo
Consultas en vivo al cargar: páginas lentas y caídas ajenas visibles	Precios en caché de vida corta: la ficha nunca espera una llamada externa
Al pedido le faltaban los campos que la entrega necesitaba	Campos propios que atraviesan ficha, carrito, pago y pedido
Cambiar la regla de precios exigía tocar código	Las estrategias se intercambian tras una única interfaz

Cómo funciona

Los precios se recogen por región. Para cada producto el plugin pide a la tienda superior su precio en cada moneda configurada, en lugar de fiarse de un único escaparate.
Una estrategia elige uno. La elección es un componente enchufable tras una sola interfaz; la implementación incluida toma el precio regional legítimo más bajo. Cambiar la regla: una región fija, un margen sobre la mediana: no toca el resto del plugin.
El resultado se cachea. El precio elegido se escribe en un transient de vida corta. El catálogo y las fichas leen la caché, así que renderizar una página nunca se bloquea por una llamada externa y una caída del origen no se convierte en una caída de la tienda.
Los campos propios acompañan al pedido. Los campos adicionales de los que depende la entrega se inyectan en la ficha de producto, el carrito, el pago y el pedido final, de modo que el dato que necesita un operador viaja con el pedido en vez de reconstruirse después.
El catálogo se mantiene al día. Las actualizaciones se ejecutan programadas sobre todo el catálogo, que es lo que mantiene a una tienda de este tamaño al ritmo de un origen que cambia a diario.

Funciones clave

Obtención de precios en varias monedas desde la tienda superior
Estrategia de precios enchufable: precio regional más bajo por defecto
Caché de precios sobre transients con vida configurable
Campos propios en ficha, carrito, pago y pedido
Actualización programada de todo el catálogo
DTOs tipados para cada respuesta del origen: un cambio de formato falla en voz alta

Instalación

Suba la carpeta del plugin a /wp-content/plugins/ y actívelo
Configure las credenciales de la API de origen y las monedas a consultar
Elija la estrategia de precios y fije la vida de la caché
Ejecute la primera actualización del catálogo a mano para poblar la caché
Programe la actualización recurrente con el intervalo que justifique el origen