Volver a proyectos
Inicio / Proyectos / Debugging y soporte técnico avanzado

Caso de estudio

Debugging y soporte técnico avanzado

Resolución de incidencias reales en entornos WordPress, WooCommerce, PrestaShop y Dolibarr, trabajando sobre tiendas y sistemas en producción donde los errores afectaban a pedidos, checkout, facturas, emails, TPV, reservas, contratos o sincronizaciones externas.

Este caso reúne intervenciones técnicas realizadas en contexto de empresa: análisis de logs, detección de módulos conflictivos, revisión de plantillas, corrección de overrides, validación de procesos de compra, ajustes en PDFs, problemas multidioma, errores de servidor y pruebas funcionales sobre flujos críticos.

Ver casos
Producción real Errores críticos Debugging PHP eCommerce Soporte avanzado
Producción incidencias sobre webs y tiendas activas
eCommerce checkout, pedidos, pagos, facturas y transportistas
Legacy correcciones sobre temas, módulos y plugins existentes
Debugging análisis de errores, logs, pruebas y validación final

Problema / reto

Resolver incidencias que afectaban a procesos críticos

En entornos e-commerce, una incidencia no siempre es un error visible en pantalla. A veces es un email que no llega, una factura incompleta, una URL traducida que falla, un transportista mal filtrado, un TPV en pruebas, una firma que no se genera o un módulo que rompe el carrito.

El reto fue diagnosticar cada caso sin partir de un proyecto limpio, sino trabajando sobre instalaciones existentes, con temas personalizados, plugins de terceros, módulos antiguos, código legacy y configuraciones distintas por cliente.

  • Detectar el origen real del fallo antes de modificar código.
  • Diferenciar entre errores de plugin, tema, servidor, hosting, SMTP o configuración.
  • Corregir incidencias sin romper otros flujos de la tienda.
  • Trabajar sobre sistemas activos donde los cambios impactaban en pedidos o reservas reales.
  • Documentar rutas, líneas modificadas, pruebas realizadas y posibles limitaciones.
  • Validar el resultado con pedidos de prueba, capturas o reproducción del caso.

Solución

Diagnóstico técnico antes de aplicar cambios

El enfoque no fue aplicar cambios a ciegas, sino seguir un proceso de análisis: reproducir el error, revisar contexto, aislar el componente responsable, localizar el punto de intervención y probar la corrección en el flujo afectado.

  • Revisión de logs, mensajes de error y comportamiento real del usuario.
  • Desactivación o comparación de módulos cuando existían conflictos.
  • Inspección de plantillas PHP, TPL, hooks y overrides.
  • Correcciones localizadas en lugar de modificar todo el sistema.
  • Pruebas funcionales sobre carrito, pedido, factura, email, idioma o método de pago.

Enfoque

Soporte técnico con impacto directo en negocio

Muchas incidencias afectaban directamente a ventas, reservas, documentación o comunicación con clientes. Por eso cada corrección debía equilibrar rapidez, seguridad y trazabilidad.

  • Evitar pérdida de pedidos o reservas.
  • Restaurar funciones críticas del checkout.
  • Corregir facturas y documentos generados automáticamente.
  • Garantizar que los emails transaccionales incluyeran la información correcta.
  • Mantener sistemas legacy sin rehacerlos desde cero.

Caso representativo

Error fatal en carrito provocado por módulo

Diagnóstico de un error crítico en el carrito causado por un módulo de producto dinámico. La prioridad era diferenciar si el fallo venía del tema, del core, de un override o de un módulo externo.

  • Reproducción del error desde el flujo real de compra.
  • Revisión de módulos activos relacionados con producto y carrito.
  • Aislamiento del módulo responsable.
  • Verificación de compatibilidad con la versión de PHP y PrestaShop.
  • Documentación del origen del problema para decidir solución o sustitución.
// Ejemplo de checklist técnico aplicado al diagnóstico
1. Reproducir el error en carrito.
2. Revisar si ocurre con todos los productos o solo con productos configurables.
3. Comprobar módulos que intervienen en precio, atributos o campos dinámicos.
4. Revisar logs del servidor y errores PHP.
5. Desactivar temporalmente módulos sospechosos en entorno controlado.
6. Confirmar el módulo responsable.
7. Proponer solución: actualización, sustitución, override o configuración alternativa.

Este tipo de intervención demuestra capacidad para trabajar con errores no evidentes, donde el mensaje final del usuario no explica el origen real del fallo.

Caso representativo

Correcciones en facturas PDF y documentos generados

Varias incidencias estaban relacionadas con facturas, abonos o documentos generados automáticamente: CIF no visible, descuentos mal reflejados, textos legales ausentes, colores de cabecera o políticas de venta.

  • Modificación de plantillas PDF en WooCommerce y PrestaShop.
  • Corrección de información fiscal y desglose de IVA.
  • Ajuste de descuentos en abonos y facturas rectificativas.
  • Inserción de textos legales en zonas concretas del documento.
  • Pruebas de generación para confirmar el resultado final.
// Ejemplo genérico de intervención en plantilla PDF WooCommerce
$order = $this->order;
$billing_vat = $order->get_meta('billing_vat_number');

if (!$billing_vat) {
    $billing_vat = $order->get_meta('billing_nif');
}

if ($billing_vat) {
    echo '<p><strong>CIF/NIF:</strong> ' . esc_html($billing_vat) . '</p>';
}

// En facturas rectificativas se revisa el subtotal, descuento e impuestos
// para que el PDF represente correctamente el importe original y el descuento aplicado.

La dificultad está en que una factura no es solo una vista visual: tiene implicaciones fiscales, de cliente y de operación interna.

Caso representativo

Emails transaccionales y problemas de entrega

Análisis de casos en los que los emails de pedidos, reservas o confirmaciones no llegaban correctamente o no incluían la información esperada.

  • Revisión de configuración SMTP.
  • Prueba de emails desde formularios y WooCommerce.
  • Modificación de plantillas de correo.
  • Inclusión de información adicional en pedidos y reservas.
  • Adaptación de HTML de emails para mejorar compatibilidad con Gmail, Outlook y otros clientes.
// Ejemplo genérico de mejora en email de pedido WooCommerce
add_action('woocommerce_email_order_meta', function($order, $sent_to_admin, $plain_text, $email) {

    if (!$order) {
        return;
    }

    $custom_info = $order->get_meta('_reserva_info');

    if ($custom_info) {
        echo '<table width="100%" cellpadding="0" cellspacing="0">';
        echo '<tr><td><strong>Información de reserva:</strong></td></tr>';
        echo '<tr><td>' . esc_html($custom_info) . '</td></tr>';
        echo '</table>';
    }

}, 20, 4);

En emails transaccionales no basta con que “se vea bien” en navegador: hay que pensar en compatibilidad, estructura en tablas, estilos inline y entregabilidad.

Caso representativo

Errores de firma en contratos y documentos Dolibarr

Diagnóstico de errores al firmar contratos, analizando el flujo completo de generación del documento, parámetros de URL, referencia del contrato y creación de imagen de firma.

  • Reproducción del error en contrato de prueba y contrato real.
  • Análisis de parámetros como token, referencia y URL.
  • Detección de caracteres problemáticos en la referencia.
  • Corrección de la generación para evitar referencias vacías o rutas inválidas.
  • Ajustes de coordenadas y márgenes en documentos PDF.
// Ejemplo genérico de normalización de referencia antes de firmar
$ref = GETPOST('ref', 'alpha');

if (empty($ref)) {
    throw new Exception('Referencia de contrato no válida');
}

// Evitar caracteres que rompen rutas o parámetros de URL
$ref = str_replace('/', '-', $ref);
$ref = preg_replace('/[^a-zA-Z0-9\-_]/', '', $ref);

// A partir de aquí se continúa con la generación de la firma
// y la escritura sobre el PDF correspondiente.

Este tipo de incidencia requiere entender tanto la parte funcional del contrato como la parte técnica del PDF, la URL, el token y la persistencia del documento.

Caso representativo

TPV, Redsys, Plazox y métodos de pago

Revisión de integraciones de pago, validando configuraciones de entorno de pruebas, paso a producción, comportamiento de tarjetas compatibles y textos asociados a métodos de pago.

  • Configuración y revisión de TPV/Redsys.
  • Pruebas en entorno test antes de solicitar producción.
  • Validación de métodos como Bizum, PayGold o pago por transferencia.
  • Revisión de textos en checkout y emails.
  • Diagnóstico de errores relacionados con banco, plugin o configuración.
// Checklist de validación de pasarela de pago
1. Confirmar FUC / código de comercio.
2. Confirmar terminal, moneda y entorno.
3. Activar modo test.
4. Realizar pedido de prueba.
5. Revisar respuesta del banco.
6. Confirmar creación correcta del pedido.
7. Revisar email de confirmación.
8. Solicitar paso a producción cuando el flujo test es correcto.

Las incidencias de TPV son críticas porque afectan directamente a la conversión y a la capacidad de cobrar pedidos.

Caso representativo

Problemas multidioma, URLs y traducciones

Corrección de incidencias relacionadas con traducciones incompletas, menús no traducidos, URLs que fallaban por idioma, formularios con rutas incorrectas y textos de checkout o emails que no aparecían en todas las lenguas.

  • Traducción de menús, botones y bloques de tema.
  • Corrección de rutas por idioma.
  • Revisión de formularios multidioma.
  • Adaptación de URLs para mantener al usuario en la misma página traducida.
  • Uso de cadenas traducibles en plantillas TPL/PHP.
{* Ejemplo genérico en plantilla PrestaShop *}
<a class="btn btn-primary" href="{$product.url}">
  {l s='Consultar por WhatsApp' d='Shop.Theme.Action'}
</a>

{* Usar cadenas traducibles evita duplicar plantillas por idioma
   y permite gestionar el texto desde el sistema de traducciones. *}

En tiendas multidioma, una mala URL o una cadena sin traducir puede romper la experiencia de compra o enviar al usuario a una página equivocada.

Incidencias reales

Incidencias reales resueltas

  • PrestaShop: Error fatal en carrito por incompatibilidad de módulo con PHP 8.
  • WooCommerce: Facturas PDF sin mostrar CIF/NIF del cliente.
  • Dolibarr: Problemas de firma digital y generación de contratos PDF.
  • Redsys / Plazox: Validación y puesta en producción de pasarelas de pago.
  • SMTP: Emails transaccionales que no llegaban o llegaban incompletos.
  • PrestaShop: Conflictos entre módulos, overrides y actualizaciones.
  • Multidioma: URLs y traducciones incorrectas que afectaban a la navegación.
  • Hosting: Incidencias relacionadas con ModSecurity y configuración del servidor.
  • Integraciones: Problemas de sincronización con sistemas externos y reservas.

Proceso

Cómo se abordaban las incidencias

01

Reproducción del problema

Antes de modificar nada, se intentaba reproducir el fallo en el mismo flujo que reportaba el cliente: carrito, checkout, pedido, factura, email, firma o panel de administración.

02

Identificación del componente afectado

Se revisaba si el origen estaba en el tema, un plugin, un módulo, un override, una plantilla, el servidor, una traducción, una configuración o una integración externa.

03

Corrección localizada

La intervención se realizaba en el punto más concreto posible para reducir riesgo: una plantilla, una función, un hook, una regla de envío, una traducción o un ajuste de configuración.

04

Validación funcional

Después del cambio se repetía el flujo afectado para comprobar que el problema quedaba resuelto sin introducir efectos secundarios.

05

Documentación de la intervención

Se dejaban documentadas rutas, líneas modificadas, módulos implicados, pruebas realizadas y cualquier limitación que pudiera afectar al mantenimiento futuro.

Resultado

Resolución de problemas reales en sistemas activos

Este trabajo permitió mantener operativos flujos críticos de varias plataformas: pedidos, pagos, reservas, facturas, contratos, emails, traducciones, formularios, transportistas y procesos de administración interna.

A nivel técnico, demuestra experiencia trabajando sobre sistemas existentes, capacidad para diagnosticar errores complejos y criterio para intervenir sin romper funcionalidades que ya estaban en producción.

  • Errores críticos de carrito diagnosticados y aislados.
  • Facturas y documentos PDF corregidos.
  • Emails transaccionales revisados y personalizados.
  • Contratos y firmas digitales ajustados.
  • Pasarelas de pago revisadas en test y producción.
  • Problemas multidioma y URLs corregidos.
  • Incidencias de módulos legacy documentadas.

Contacto

¿Quieres ver más proyectos o hablar de un desarrollo similar?

Puedo enseñarte más casos de WordPress, PrestaShop, WooCommerce, automatización, módulos personalizados o debugging en producción.