La pasarela de pago RedSys es la que ofrecen los bancos en España como solución por defecto para pagos con tarjeta y no está carente de errores y problemas.
Para empezar, el proceso de configuración es para mear y no echar gota, un horror absoluto, solo para miembros de la secta.
Pero vaya, que no nos vamos a poner estupendos, y si has conseguido acceder al módulo de administración y hacer las primeras pruebas, no siempre el proceso ha terminado ahí, muchas veces ocurren errores en la comunicación entre nuestra tienda online y RedSys, o simplemente no terminan de confirmarse los pedidos, quedándose pendientes, el problema más común con diferencia.
Estas suelen ser las causas más comunes…
Plugins de seguridad
Es bastante habitual que si tienes un plugin de seguridad para WordPress esté bloqueando la comunicación con RedSys, los que suelen generar problemas más comúnmente son estos.
All in One SEO Pack
Aunque no es un plugin de seguridad, una de las utilidades que ofrece AIOSP es el bloqueador de bots maliciosos, y siempre bloquea RedSys, así que desactiva esta utilidad.
Solid Security
También este buen plugin de seguridad puede bloquear la comunicación con RedSys. En este caso hay un par de ajustes que pueden estar bloqueando RedSys.
El primero sería si tienes activa la lista de HackRepair. Si así fuera desactiva esta característica.
Otros ajustes que podrían estar bloqueando a RedSys serían los de bloquear cadenas sospechosas y URLs demasiado largas, en los ajustes del sistema de iThemes.
Una posible solución a este bloqueo, sin desactivar los anteriores ajustes, sería poner las IPs de RedSys en la lista blanca de bloqueo de los ajustes generales de iThemes.
Las IPs a añadir a la lista blanca normalmente serán estas pero confírmalas con el equipo de soporte de RedSys porque pueden haber cambiado:
- 195.76.9.187
- 195.76.9.222
- 195.76.9.182
- 193.16.243.33
Redirecciones HTTPS forzadas
Otro culpable habitual suelen ser las redirecciones HTTPS forzadas, para servir todo tu contenido mediante el cifrado del certificado SSL.
Y esto puede estar forzado de muchas maneras, a saber…
Plugins de SSL … y otros
Todos los plugins de gestión de certificados SSL y muchos de optimización tienen ajustes para forzar que todo tu contenido se cargue mediante HTTPS.
Esto, que a priori es bueno para tu web, pues la hace más segura y evita avisos de sitio no seguro del navegador, casi siempre genera conflictos con RedSys.
Así, por ejemplo, si usas el plugin Really Simple SSL, debes tener activos solamente los siguientes ajustes:
- Solucionador de contenido mixto (sí, no pasa nada si sigues la lista)
- Permitir redirección 301 de .htaccess (no la de WordPress)
- Dejar de modificar el archivo .htaccess
Además, a continuación debes añadir las siguientes líneas, que recomienda José Conti, al archivo .htaccess:
# REDIRECCION CERTIFICADO SSL REDSYS
RewriteEngine on
RewriteCond %{QUERY_STRING} !^wc-api=WC_Gateway_(.*)redsys
RewriteCond %{HTTPS} !=on [NC]
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
# FIN REDIRECCION CERTIFICADO SSL REDSYS
Curiosamente, en este aspecto, también iThemes Security podría estar provocando este problema si tienes activos los ajustes de SSL de este plugin de seguridad, que viene precisamente a forzar la carga por HTTPS de tu contenido.
De hecho hay muchos usuarios de iThemes Security que no saben que tiene esa utilidad, con la que ahorrarse un plugin para HTTPS, pero que en este caso concreto, por este problema con RedSys, podría estar interfiriendo.
Así que si usas Solid Security pero estás teniendo problemas de pedidos pendientes de RedSys, también aquí podría estar el problema, y deberías desactivar este módulo.
Y, si como millones de usuarios de SiteGround, utilizas su plugin de optimización SG Optimizer, también el ajuste para corregir contenido inseguro, así que si es tu caso prueba a desactivarlo y ver si era eso lo que dejaba pendientes los pedidos de RedSys, como en el resto de posibles soluciones.
Por supuesto, ni de coña utilices plugins como SSL Insecure Content Fixer o similares.
Códigos de redirección HTTPS
Si, por el contrario, no usas ningún plugin para forzar la carga de tu web por HTTPS sino un código en el archivo .htaccess, búscalo, bórralo y prueba a ver si ya entran correctamente los pedidos desde RedSys.
Un ejemplo de este tipo de códigos sería así:
# BEGIN HTTPS
<IfModule mod_rewrite.c>
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>
# END HTTPS
CloudFlare
Para finalizar, si utilizas CloudFlare para cargar todos tus estáticos desde esta CDN, también hay un ajuste de SSL que podría ser el culpable.
SSL/TLS
En la sección denominada SSL/TLS tienes la posibilidad de cambiar el modo de cifrado, que por defecto CloudFlare configura en el modo completo (Full), lo que fuerza que se use el certificado de CloudFlare en vez de el de tu alojamiento.
Siempre, he dicho SIEMPRE, es más recomendable usar el modo flexible de SSL de CloudFlare, y de paso puede que solucione el problema de los pedidos pendientes de RedSys.
Comprobación de integridad del navegador
Otro posible culpable, bastante habitual, es un ajuste de seguridad denominado «Comprobación de integridad del navegador» que busca solicitudes con cabeceras HTTP que suelen usar quienes envían spam, los bots y los rastreadores, como solicitudes con agente de usuario ausente o que no es estándar, y en esta lista a veces puede entrar RedSys.
Para comprobarlo pásate por la sección de eventos de seguridad de Cloudflare y revisa si ha habido bloqueos a RedSys por este motivo (u otro).
Si fuera el caso, y la prueba la tienes en la misma captura, pásate por la sección de configuración de seguridad y desactiva la comprobación de integridad del navegador.
Vigila los eventos de seguridad, para comprobar que Cloudflare deja de bloquear estas comunicaciones de RedSys, y comprueba si tus pedidos dejan de estar pendientes y pasan a procesando, el estado por defecto.
¿Te gustó este artículo? ¡Ni te imaginas lo que te estás perdiendo en YouTube!
Hola. Por mi experiencia puedo decir que tanto los CDN como las versiones de PHP han roto las comunicaciones de Redsys con las tiendas.
Son bastantes las llamadas a Redsys tratando que me aconsejaran, y no es por hacerme el listo, no tienen grandes consejos.
Para empezar tardaron meses en actualizar el archivo que vinculaban a la última versión en su web, vinculaba con la anterior. Creías que bajabas la 3 y estaba vinculado a la 2.
Me mandaron el vínculo por privado, me dio muchos fallos, volví al anterior.
Hoy en día su plugin último (por lo menos a mí en varias tiendas) no me funciona más allá del PHP 7.1.
Incluso me recomendaron que comprase un plugin «especializado» ellos mismos, flipas…
Y qué no funciona? En caso de que hagas la compra, el panel de Redsys no informa a la tienda del pago, lo que es realmente divertido, primero mientras lo encuentras y luego para explicarlo al cliente.
Pues he comprado un plugin, no voy a hacer propaganda, pero compré un modulo de pago (es fácil de encontrar) unos 70 o 140 pavos dependiendo funciones, token y suscripciones. Yo he comprado el ilimitado, algo más caro pero rentable a la larga.
Sin problema, tiendas en PHP 7.3 (el 7.4 cuando haga pruebas me da yuyu a lo loco).
Si tenéis problemas con el plugin de Redsys comprobad: CDN (gratuito), SSL Wild card o si PHP más de 7.1
En mi caso, mi ignorancia, me impidió dar con una solución más especializada, encontré una solución simple.
Fernando gracias por la información y la divulgación.
Hola Fernando, muchas gracias por este post que me está salvando la vida.
Es justo lo que me está pasando en cuanto la plataforma Redsys no informa el WooCommerce y me está dando el clásico error de prohibición:
Error (Server returned HTTP response code: 403 for URL: https://kurasanalabs.com/?wc-api=WC_Gateway_redsys)
El pedido se me queda en WC como «pendiente de pago» en lugar de «procesando» con consecuente falta de envío del correo y nadie se entera de que hay un nuevo pedido si no entramos a verlo.
No usando ni el Cloudfare ni ningún plugin de SSL (ya que tenia activado en iThemes el modulo SSL), el único que puede estar afectando es el iThemes en su especifica configuración que vi en otro post tuyo super importante y útil.
Para resolver este problema he configurado lo siguiente en iThemes:
—AJUSTES GLOBALES: En lista de servidores autorizados los de REDSYS 195.76.9.187,195.76.9.222,195.76.9.182,193.16.243.33
—USUARIOS BANEADOS: he dejado activas las opciones: Activa la funcionalidad de lista de bloqueo de HackRepair.com y Activar listas de baneo
—AJUSTES DELSISTEMA: he desactivado tanto Filtrar cadenas de URL largas como Filtrar cadenas de petición sospechosas en la URL
—He dejado inactivo el modulo SSL.
Me surge una duda, debo añadir las líneas, que recomienda José Conti, al archivo .htaccess o con los puntos anteriores es suficiente?
Gracias de antemano.
Me habéis salvado la vida con el código en el htaccess. Me ha solucionado el problema de «pendiente de pago».
Mil gracias!!
Muchas gracias por los consejos… he conseguido solucionar el problema! menos mal 🙂
Buenos días Fernando. He leído tu post y me gustaría conocer tu opinión.
Nada de lo que en él mencionas está en mi proyecto instalado ni en el functions.
Con todo, sigue pasando de vez en cuando.
Desde el 1 de noviembre de 2021 a hoy, 26 de enero de 2022, hemos tenido un 0.6% de error de timeout de Redsys en los pedidos
Mis dos preguntas:
– ¿Crees que es un porcentaje que debemos asumir o crees que debería ser CERO ABSOLUTO?
– ¿Crees que puede ser un problema del hosting donde está alojado el proyecto?
Gracias
Uf, me pides que te de datos que no tengo. Llevo el mantenimiento de varias tiendas y NUNCA hemos tenido un timeout de RedSys ¿significa eso que deba ser lo normal? no lo sé. ¿Podría ser por el hosting? Podría, pero antes miraría que no esté bloqueando conexiones a RedSys desde .htaccess, alguna regla del servidor, la CDN.
Gracias Fernando. En el htacess no tenemos ninguna regla, nuestra me refiero, que pueda ocasionarlo. En todo caso las que escribe el plugin de cache, en este caso fastest cache. Del servidor, hemos estudiado el caso con su servicio de soporte varias veces y no se encuentra nada y de la CDN tampoco puede ser.
De todas las opciones que se me ocurren, no sé si el plugin de cache puede estar interfiriendo en algún momento o si sencillamente debo probar con otro hosting.
Si, en tu opinión, no crees que deba sustituir el plugin de cache, creo que voy a optar por la opción de mover a otro hosting la tienda a ver si ese es el motivo.
Fernando, creo que en alguna ocasión he leído que tú estás en Villalba. si es así pues somos vecinos ya que yo vivo junto al hospital.
Bueno, te agradezco mucho tu respuesta y opinión y, si quieres saber cómo acaba todo esto, dímelo y te lo hago saber para no darte la lata y hacerte gastar el tiempo.
Un saludo y gracias de nuevo.
Independientemente del origen del problema, Fastest Cache me parece con mucho el peor plugin de caché que hay. Prueba mejor con Cache Enabler (para mi el mejor si no tiene caché tu servidor), o incluso WP SuperCache.
Lo de Villalba es cierto, así que cuando quieras tomamos un café o damos un paseo por la Dehesa con los perrillos (ahora tengo un Jack Russell Terrier) y charlamos:)
Gracias Fernando. el WP super cache lo dejé de usar hace como un par de años y ciertamente le cogí el aire al Fastest cache y por lo menos en su versión gratuita me dió la impresión de que el resultado era mejor. Ahora no recuerdo muy bien y tendría que buscar en los apuntes que me hago para recordar el motivo.
Lo que sí se me ha quedado grabado es que cuando veo «Automattic» se me «retuerce el morro».
Tomo nota y, considerando tu experiencia en este asunto, voy a instalarlo de nuevo en un proyecto y a ver la diferencia.
Una última pregunta, para usar el otro que mencionas «Cache Enabler» y según dices, ¿Sólo se puede usar si no tiene caché el servidor?
A nivel personal y sin ánimo de mostrar públicamente nuestro lado personal, seguramente nos habremos cruzado más de una vez en la dehesa y, además, yo también tengo un Jack Russell, jajajajaja qué coincidencia. Voy a intentar localizarte por la gente que pasea por allí y seguramente en poco tiempo nos conoceremos en persona.
Un saludo y te voy contando Fernando.
Cache Enabler es caché de disco, pura y dura, compatible con cualquier caché de servidor. También tengo pendiente probar Surge (https://es.wordpress.org/plugins/surge/) que apunta maneras.
Un abrazo 🙂
Pues aunque este post tiene ya unos años, lo acabo de encontrar buscan respuesta a mi problema con redsys
En mi caso web con woocommerce totalmente actualizado todo, hospedado en siteground, forzado https y con el cdn que siteground ofrece ahora a sus clientes.
Creo que tocará empezar a probar opciones pero… vaya lata
Si alguien tiene alguna pista concreta, se agradece
Slds
Hola Ignacio. en mi caso, me dí cuenta de que al borrar la caché con Fastest Cache, borraba también los datos que tenía en el carrito algún cliente. Lo solucioné instalando WP-Rocket y configurando que no se borraran esos datos.
El resto de pedidos en los que ha ocurrido esto, que ya son muy pocos, ha sido porque tenemos fijado en 7200 minutos la reserva de inventario (Woocommerce > productos > Inventario) por lo que si un cliente ha empezado la compra de un producto y lo ha terminado después de esos minutos, surge el error.
Lo tenemos así configurado por el horario máximo para recibir un pedido al día siguiente.
Espero haber puesto un poco de luz a tu duda o por lo menos saber por dónde tirar del hilo.
Un saludo para tí y otro para Fernando.
Muy buenas Jorge y gracias por tu aportación.
Creo que en mi caso el problema está siendo otro. Uso en wordpress y con woocommerce el plugin que proporciona redsys. Los pedidos se quedan en espera y aunque el pago se realiza, ni wordpress, ni el cliente ni nosotros nos enteramos.
Parece ser que redsys y lets encrypt se dan de tortas y ahora toca decidir qué hacer
1.- Cambiar el plugin por otro que gestione este problema: no me hace mucha gracia porque si surgen problemas redsys se lavará las manos.
2.- Tocar algo en el .htaccess… pues como mi nivel técnico no es muy alto, siempre me da miedo tocar este archivo
3.- ¿Desactivar wildcare para lets encrypt en siteground, que es donde está la web?… Ufff, pues no sé, da pena y tampoco tengo claro que lo solucionase.
En fin, que parece mentira que andemos así con la que debería ser la pasarela de pago por excelencia para nuestro mercado.
Si hay alguien con experiencia que pueda aportar algo se agradecería enormemente.
Gracias a todos y en especial a Fernando por compartir tanto.
Hola Ignacio. En mi caso, hablé con el servicio de hosting donde está alojada la web y me dijeron que ese tipo de errores en Redsys, no son tan extraños. No obstante, lo tuve en cuenta y, aunque asumí que podían darse estos errores no me conformé y seguí buscando la mejor solución.
Ciertamente, con mi configuración actual, prácticamente han desaparecido estos errores pero todavía, esporádicamente, siguen apareciendo con lo lo cual mi configuración actual no es perfecta.
Esto nos obliga a comprobar si cada vez que recibimos el correo de Redsys de pago recibido, al momento recibimos el de la tienda de nuevo pedido. Al final es la única manera que hemos encontrado de no dejar sin servir ninguna compra realizada. Es decir, el factor humano, como toda la vida. En todo caso, te indico que tenemos del orden de 20 pedidos diarios.
Por otro lado, Cambiar de hosting no me parece que sea la solución. En cuanto a htaccess, la única regla que puede influir es si tienes una regla de redirección de http a https y lo mismo ocurre en el panel del hosting. Si tienes redirección de http a https, quítala.
Los otros valores que puedes revisar con el servicio de hosting son los relacionados con la configuración PHP como memory_limit, max_execution_time, max_input_time, post_max_size o pm.max_children.
En cuanto a Let´s Encrypt, lo tienes más fácil y es comprar durante un periodo un certificado de pago a ver si por ahí van los tiros.
Por último, mira la cantidad de minutos que tienes en Woocommerce > Ajustes > Productos > Inventario de tal forma que si alguien comienza un pedido y no lo termina antes de esos minutos, ahí puede venir el problema también.
Por supuesto lo que te comenté del plugin de caché, que cuando borres la caché no borre los datos de los carritos en curso. En mi caso, me di cuenta que era el principal motivo de toda esta historia.
Si te parece y como mi configuración no es perfecta 100%, quedo a la espera de cualquier noticia tuya en este hilo para ver si al final podemos dar con la solución definitiva ya que en Redsys no dan mayor explicación.
Un abrazo, para ti y para Fernando cuando lo lea.
Hola a todos,
He visto este post, que es algo antiguo, pero yo tengo un problema con Redsys y Siteground similar.
Mi caso es el siguiente, tengo una tienda con Woocommerce, el plugin Woo Subscriptions y el plugin oficial WooCommerce Servired/RedSys Spain Gateway, que no es el oficial de Redsys.
Todos los pedidos funciona perfectamente, pero en ocasiones, de forma aleatoria y sólo los pedidos de renovación se quedan pendientes, sin embargo el cargo por el banco se realiza, vamos lo que se comenta en el post.
Lo que yo puedo observar, es que en el panel de la TPV, muestra un timeout supuesto de mi web, y en los logs de mi web, aparece un error 499, que es un error concreto de Ngnix indicando que el cliente (en este caso Redsys) cerró la conexión.
Un ejemplo de pedido de un día a las 20:26:47 y el timeout lo da a las 20:26:58, por tanto sólo pasan 11 segundos, me parece bajo para un timeout.
No se si tu Fernando, con tu experiencia, y pasados los meses desde los últimos comentarios tienes algo más de información sobre este tema. Yo sabiendo como funciona Redsys, tienen pinta de ser cosa de ellos, pero es muy dificil saber el motivo ya que ocurre de forma aleatoria.
La única solución que se me ha ocurrido es crear un script que busque los pedidos pendientes, que sean una renovación y no tengan ninguna Nota, porque este es el patrón que tienen siempre los pedidos.
Si alguien más ha tenido este problema y ha encontrado solución, agradecería mucho la información.
Gracias a todos.
Pues eso en concreto no me ha pasado pero si preguntas en soporte de SiteGround igual les ha pasado con otro cliente, o de REdsys, o cambias de plugin y usas el de José Conti, que suele dar menos problemas en todo
Hola Carlos. Soy Jorge el autor del post. En mi caso, aunque usaba el plugin de José Conti, que es un fenómeno y desde aquí le envío saludos, ese error se seguía produciendo, incluso todo esto lo hablé con José Conti sin llegar a encontrar cuál podía ser el problema.
Sin embargo todo el problema desapareció cuando cambié de servicio de Hosting a finales del año pasado 2023. Por si te sirve, me fui a IONOS, sin ánimo de hacer publicidad porque en realidad creo que el problema venia de que en el anterior que lo tenía, que no diré el nombre para no hacer mal a nadie, no se podía actualizar la versión de Debian, que rea la que tenía y tampoco se podía actualizar la versión de PHP de la 7 a, como poco a la que ahora mismo esta probada, la 8.1.
En todo caso, por si te sirve, ahora el servidor nuevo trabaja con Ubuntu en vez de con Debian como el anterior.
Una vez vi que dejó de dar ese error se lo comenté a José Conti por si en alguna ocasión a algún usuario suyo le pasaba porque, de verdad, que fue un alivio que se solucionara el problema.
Si quieres más detalles sobre ello, contesta a este hilo y, si a Fernando no le parece mal, te doy mi contacto y te explico todo, por más que creo que he dado todos los detalles.
Gracias Jorge, pero mira que es raro que pase según la versión de Linux
He hablado con el soporte de SiteGround, no les constan problemas como este con RedSys. Con Redsys todavía no he hablado, pero me parece que le echarán la culpa a SiteGround seguramente.
Ya estoy usando el plugin de José Conti, que efectivamente funciona muy bien, a excepción de este caso raro y aleatorio, que no se puede reproducir.
Gracias por tu respuesta Fernando.
Pregúntale en su foro, seguro que le ha pasado antes
Hola a ambos. Yo únicamente he contado como se me solucionó y os aseguro que se me solucionó.
Un saludo cordial
Hola Jorge,
En primer lugar muchas gracias por tu respuesta y tu ofrecimiento.
Yo también he hablado con José Conti sobre el tema en varios emails, tampoco hemos visto solución.
Lo que sí veo claro, al menos en mi caso, es el problema. Los pasos son:
1. Se lanza la renovación de forma automática (ya que solo me pasa con pedidos de renovación), sin intervención del usuario ni nadie, puro proceso cron.
2. Toda la información se procesa correctamente en Redsys, tan correctamente que el pago se realiza. Pero cuando manda el IPN de vuelta a la tienda, en la consola de Redsys muestra un error timeout y en el log de errores del servidor un error 499, que indicaba en mi entrada anterior que indica que el cliente (redsys) ha cerrado la conexión.
El caso es que me funciona perfectamente todo el tiempo, sólo pasa a veces, por tanto sólo se me ocurre que como es un servidor compartido y no dedicado, eventualmente el servidor retrase la respuesta un poco y redsys cierre la conexión con un timeout bajo, de 10sg debería ser, porque el error es a los 11sg.
De momento como parche, tengo un script que busca pedidos con esas características, los marca como completados y luego me avisa.
No sé que experiencia habéis tenido contactando con Redsys, pero no suelen dar mucha solución.
Gracias a los dos. Saludos.
Carlos, tal como lo relatas es como ocurría en una de las tiendas que llevamos. Por supuesto que también estuvimos en contacto con Redsys sin obtener ninguna solución. Efectivamente nuestro servidor era y es, dedicado y no compartido así que por ahí tampoco pensaría que puede venir el problema. ¿Has mirado la versión de PHP con la que estás trabajando en el servidor? ¿Y la versión de Linux? Revisa también los parámetros de PHP como el Max-execution_time o el memory-limit.
En todo caso, si no das con ello y para olvidarte del asunto, también puedes contratar un servicio en IONOS, mover tu web, sólo la web y no el correo para hacerlo más sencillo y si deja de suceder, ya habrás ganado.
Ojo, no tengo ni comisión ni interés especial en IONOS más que al ir allí, dejó de ocurrirme.
Yo no pude averiguarlo pero ahora que conseguí que se arreglara al cambiar el hosting, pienso que podía ser cualquier configuración o alguna regla que tuviera el Plesk o Apache en el servidor antiguo y eso, eso sí que es complicado de encontrar. Más bien creo que todo se me solucionó desde el momento en que arranqué con un nuevo Plesk y Apache vírgenes.
Bueno, perdona por semejante parrafada pero ahora si que creo que tienes toda la información completa. En todo caso, aquí te dejo mi email por si tienes alguna duda más o hay algo en lo que pueda ayudarte: [email protected].
Un saludo cordial.
Hola Jorge,
De nuevo muchas gracias por tu atención.
Tengo actualmente la versión 7.4 de PHP, con respecto a Linux ignoro la distribución y versión (ya que es servidor compartido). El timeout lo tengo alto a 120sg y de memoria 768Mb por proceso.
En cualquier caso, no creo que el problema venga por ahí, porque es una simple petición de redsys a un endpoint de la tienda a la que manda un POST. Creo que más bien debe estar relacionado con la gestión peticiones, mi servidor usa Ngnix, así que tal vez por ahí venga la cosa.
Seguiré mirando, si obtengo solución os comentaré. Si no valoraré cambio de servidor.
Gracias. Saludos.
Estupendo Carlos. Yo empezaría cambiando la versión de PHP ya que, además de que es más que posible que el problema lo soluciones, debes hacerlo por cuestiones de seguridad. La versión que tienes está obsoleta y no recibe desde hace meses actualizaciones de ningún tipo, como por ejemplo de seguridad.
mira:
https://www.php.net/supported-versions.php
Únicamente debes asegurarte de que todos los plugins de Wordpress o módulos de Prestashop son compatibles con esa versión y, por supuesto hacer una copia del sitio.
Otra cosa es que tengas posibilidades de subir la versión al servidor.
Nosotros nos dedicamos a llevar tiendas online y ya hemos pasado por todo esto.
Ya, a partir de aquí, puedes seguir tú o bien contactar con nosotros.
Suerte y un abrazo.
Estupendo Carlos. Creo que deberías actualizar la versión de PHP ya que es más que posible que el error provenga de ahí y además es una versión obsoleta que no recibe actualizaciones de ningún tipo, como las relacionadas con la seguridad, lo que hace tus proyectos vulnerables.
Mira esto: https://www.php.net/supported-versions.php
Yo no tengo dudas de que empezaría por ahí pero para ello debes asegurarte de que todos los plugins de Wordpress o módulos de Prestashop son compatibles con la versión que vayas a poner de PHP.
Para que te hagas una idea, yo tengo la 8.1 y en noviembre de este año, actualizaré a 8.2, una vez que sé de sobra que está probada y pulida.
Nosotros nos dedicamos a llevar tiendas online y por eso te cuento todo esto, porque ya pasamos por ello.
Ya, a partir de aquí, puedes actuar tú o bien puedes contactar con nosotros.
Suerte!
Bueno se ha publicado dos veces porque me había dado un error. Disculpad