maximo88

Qué actualices a versión 8, porque yo estaba en 1.6 y ya empezó a caerse este invierno de forma continuada, son versiones muy inseguras y vas a tener problemas muy gordos, yo perdí mucho posicionamiento en Google por las continuas caídas. Cómo te dice Dan, sin usar el módulo Migration Pro será muy difícil la actualización.

Le he echado un vistazo a tu web. El idioma sale en español, pero lo tienes como configurado en modo demo con la plantilla que lo tienes. Arriba a la derecha de tu web aparece Ajustes y ahí se puede seleccionar el alemán. Supongo que lo tenías ahí seleccionado, porque tienes la tienda en varios idiomas. A la izquierda aparece una rueda dentada ⚙️ roja que le puedes cambiar el color a la web que pone Theme Options, no creo que esto debiera estar. La sección de contacto no has puesto bien las coordenadas, aparece la sede de Prestashop. El botón de añadir al carrito los productos no va nada bien, a veces tarda mucho y a veces no los añade. No me parece una buena plantilla.

No empiezan con buen pie. Vamos a ver si GitHub les saca los colores y consiguen hacer algo decente. La versión Alpha da miedo.

Gracias por el vídeo.

Now available

No hay de qué, para lo que haga falta. Activar el pedido express para cuentas de invitado Permitir a los visitantes realizar un pedido sin registrarse. La tengo desactivada, porque como bien dices falla. Pero en este caso creo que es un problema de Prestashop 8.2.1, porque yo que la tengo desactivada Redsys no me falla como a ti con un usuario previamente registrado, porque en este caso cuando se llega a usar Redsys el usuario ya estaba registrado. Hay tres escenarios: Invitado > Te falla en el momento de Redsys Usuario que se registra > Falla antes de Redsys en el paso de la dirección Usuario que ya estaba registrado > No falla A mí me falla cuando después de meter la direccion en el proceso de registro le da a siguiente, se queda en blanco. A nivel interno genera al cliente, pero no los datos del domicilio o facturación que los tiene que volver a introducir el cliente de nuevo. Pienso que hay un problema con el almacenamiento de los datos del cliente de la facturación ya sea en invitado o cuando se crea al cliente registrado. Mi idea es que a ti te falla en invitado cuando usas Redsys, porque es en ese momento cuando almacena en las tablas la dirección y los datos y a mí me falla previamente, en el paso de guardar la dirección, por lo tanto si el error ocurre con invitado y no con registrado, es casi seguro que Redsys no tiene que ver aquí. En las pruebas usaba un usuario registrado que ya tenía, entonces siempre iba bien con 1.5.7. Pero cuando he probado a registrarme con nuevo email para probar Redsys, ya se queda siempre colgado en el paso de guardar la dirección del nuevo cliente. Si tú lo puedes probar o si ya lo has probado creando un nuevo cliente, me sería de ayuda saberlo. Tengo la teoría que esos dos errores parten de la misma base, a ver si consigo repararlo. Te mantengo informado.

El error ocurre si se mira un pedido antiguo que se pagara con otro tipo de módulo de Redsys que no fuera, por ejemplo, el oficial o contrareembolso o transferencia bancaria. Lo acabo de mirar, a mí también me sale Autorizada con el número en la factura y tengo esa opción que indicas también activada. Quizás se podría poner la palabra Redsys + Autorizada + número. No lo sé. Y esto afortunadamente también lo sufrí y era el tercer parche que le tuve que poner, que ya ni me acordaba pero he visto que lo tenía apuntado. redsyspur.php Si entramos en el archivo nos encontramos este código de Redsys que no funciona, porque como falle una vez el pago volverá a intentarlo con el mismo código y no lo cambia hasta que no pasan unos 6 minutos: // NUMERO DE PEDIDO - Añadimos time() para evitar SIS0051. $orderId = (int) $cart->id; if( ! isset($_COOKIE['nPedSession']) ) $numpedido = $this->generaNumeroPedido($orderId, Configuration::get ( 'REDSYS_NUMERO_PEDIDO' ), Configuration::get ( 'REDSYS_PEDIDO_EXTENDIDO' ) == 1); else $numpedido = $_COOKIE['nPedSession']; 🔥 PARCHE 2: Generar siempre un número nuevo (más agresiva, más segura) Hay que sustituirlo por este //Nuevo código abril 2025 $orderId = (int) $cart->id; $numpedido = $this->generaNumeroPedido($orderId, Configuration::get('REDSYS_NUMERO_PEDIDO'), Configuration::get('REDSYS_PEDIDO_EXTENDIDO') == 1); setcookie('nPedSession', $numpedido, time() + 3600, '/'); // Reescribe siempre Gracias a vosotros 😇

Acaba de salir sí. Yo tardaré tiempo en probarla, solo cuando revise el código los cambios que han hecho. @apositivo prueba por favor la versión que te he dado, estoy casi seguro que el fallo que te está dando es el mismo que tuve yo que arreglar, a ver si así te cargan los pedidos antiguos. Hace dos meses migré como tú de 1.6.1.24 a 8.2.1. No hay que hacer ninguna traslación u homologación de los datos antiguos por temas de métodos de pago. No hay que tocar las tablas para este aspecto. La prueba más sencilla es: ¿puedes ver los pedidos antiguos cuando ese módulo de Redsys 1.5.7 o 1.6 está desactivado? Si puedes el problema es el módulo, que debug te especifica donde está el error. ——————- Detallo el parche que me temo que no han reparado en esa versión 1.6.0: Parche para evitar error 500 en el backoffice al ver pedidos sin Redsys 1.5.7 📌 Síntoma del error Al acceder a un pedido desde el backoffice, PrestaShop lanza este error: Warning: Trying to access array offset on value of type null en modules/redsyspur/redsyspur.php (línea ~2499) Esto ocurre porque el módulo intenta acceder a datos de Redsys aunque el pedido no haya sido pagado con un módulo oficial de Redsys, aunque usara también la plataforma Redsys o fuera muy antiguo, o fuera métodos de pago como contrareembolso. ✅ Solución Editar el archivo modules/redsyspur/redsyspur.php, dentro del método: public function hookDisplayAdminOrderSide(array $params) Y reemplazar su contenido completo por lo siguiente, añadiendo un primer if: public function hookDisplayAdminOrderSide(array $params) { $orderDetails = Redsys_Order::getOrderDetails($params['id_order']); if ( !is_array($orderDetails) || !isset( $orderDetails['redsys_order'], $orderDetails['confirmation_amount'], $orderDetails['refund_amount'], $orderDetails['shipping_paid'] ) ) { return ''; // No hay datos de Redsys, no mostramos nada } $orderId = $params['id_order']; $order = new Order($orderId); $redsysOrder = $orderDetails['redsys_order']; $amountPaid = ($orderDetails['confirmation_amount'] - $orderDetails['refund_amount']) / 100; $amountPaid = number_format($amountPaid, 2); $smartyVars = array(); $smartyVars['orderId'] = $orderId; $smartyVars['redsysOrder'] = $redsysOrder; $smartyVars['amountPaid'] = $amountPaid; $smartyVars['productsAmount'] = number_format($order->total_paid_real - $order->total_shipping, 2); $smartyVars['shippingAmount'] = number_format($order->total_shipping, 2); $smartyVars['reference'] = $order->reference; $smartyVars['shippingPaid'] = json_encode(($orderDetails['shipping_paid']) ? true : false); $this->context->smarty->assign($smartyVars); $content = $this->context->smarty->fetch(_PS_MODULE_DIR_ . $this->name . '/views/templates/admin/refundpayment.tpl'); return $content; } 💡 ¿Qué hace este parche? Evita errores fatales al comprobar si $orderDetails existe y tiene todos los campos necesarios antes de usarlos. No interfiere con pedidos que sí usaron Redsys, donde el bloque se sigue mostrando como siempre. Hace el módulo compatible con pedidos de otros métodos de pago o con pedidos migrados desde otras versiones.

Hola, justamente hoy le he pasado a otro compañero del foro la 1.5.7 que yo reparé y veo que acaba de salir esa 1.6.0. Te dejo el enlace del post para que puedas descargarlo. De la 1.6.0 no sé nada hasta que no mire el código en profundidad. Prueba primero si te funciona con esta versión de 1.5.7 reparada (el error que indica Salserín y otro muy gordo en vista del pedido) y así vemos si es el módulo u otra cosa de tu web. Este módulo funciona en PHP 8.0 y 8.2, 8.1 no lo he podido probar, pero vamos no creo que tenga nada que ver.

El oficial es el 1.5.7 que viene con dos errores, uno leve de la denominación de los teléfonos y otro muy grave en la lista de pedidos. Con mucho esfuerzo pude corregir el segundo, te paso la versión que yo estoy usando que afortunadamente ya va bien en 8.2.1. Si tienes algún problema me dices redsyspur 157 corregido abril 2025.zip

Yo voy a poner un post a favor de Prestashop, soy experto en Prestashop y Woocommerce y si bien estoy de acuerdo en la deriva tan terrible de Prestashop, mientras parece que sus competidores se lo meriendan a nivel gráfico con el gran Elementor, siendo objetivos es la plataforma que consigue un rendimiento excepcional tanto en backoffice como frontoffice. La inmediatez, la pureza de su base de datos, no existe en Wordpress que bajo mi punto de vista cuando se le piden las funcionalidades de Prestashop, para lo que hace falta una sobrecarga de módulos, empieza a desfallecer en rendimiento. Shopify ya es otro cantar, está permitiendo a gente absolutamente nula en informática, superar a nivel gráfico y ventas a expertos en código. Y aunque sus estadísticas de Pagespeed son malas, la sensación para el usuario es buena y ágil. Lo que se hizo en este foro con los usuarios no tiene nombre, prefiero ni mencionarlo, pero es una de las causas de la huida y nada tiene que ver con las gracias o las no gracias en mi humilde opinión. Este mal ambiente se sumó a que Prestashop 1.4 y 1.5 fueron un quebradero de cabeza, demasiada ambición en aquel momento, que no era capaz ni de hacer un redondeo correcto. Con 1.6 llegó la estabilidad, pero también el miedo, la gente ya dijo yo me quedo como estoy, porque como me cambie de versión volverán los problemas. La 1.7 pocos se atrevieron a actualizar, se basaba en usuarios nuevos que llegaban y ahora con el empuje de Wordpress muchos usuarios ya si están haciendo la actualización de 1.6 a 8, que realmente ofrece casi lo mismo, pero con mucha más inmediatez y como novedad tiene los landing que los recomiendan para el SEO. Los módulos de Prestashop también tienen un precio desaforado, podemos entender que sí, que hay mucho esfuerzo detrás, pero por favor, que está costando cualquier módulo más que una licencia de Windows 11. Prestashop ahora está algo obsoleto, pero lo prefiero así, a que vuelva a sacar versiones que no eran operativas para la venta, casi la totalidad de sus versiones fueron peligrosas y este foro no se usaba para engrandecer Prestashop, sino para buscar continuos parches que solucionaran un sistema que era una beta. Otra novedad de Prestashop 8, es que el código ya está organizado en carpetitas con una lógica, lo otro era una auténtica locura. La historia aún está por escribir, no se ha llegado al punto de vencedores o vencidos. Pero objetivamente Prestashop es más rápido, es más capaz y siempre quiso ser la versión gratuita de la costosísima Magento.

¿Qué opciones tienes activas en el módulo Formulario de Contacto? ¿Tienes las dos? Y el otro que tienes que mirar es “Alertas por correo electrónico“, seguramente tampoco las tengas marcadas. Ya nos cuentas.

Deberías hacer redireccionamientos en el htcaccess, porque como te han dicho perderás el SEO.

Gracias por tomarte el tiempo aquel día de poner la solución. Lo olvidé al actualizar a Prestashop 8 y he perdido tres horas de reloj con ChatGPT. Es simplemente marcar esa opción en el módulo formulario de contacto. Hola @grodsnake. Te recomiendo que uses este SMTP fake o trampa para hacer las pruebas. En dos minutos tienes un SMTP, que no enviará nada al email, pero irás viéndolo todo en su bandeja de entrada. ¿En qué versión estás? ¿Conseguiste arreglarlo? https://mailtrap.io/ Lo primero es enviar el email de prueba a ver si llega. Luego mirar en el registro de email del backoffice a ver si los ha generado y luego en ese SMTP fake ir viendo lo que pasa.

Thanks, with that module I have reduced on a 5000 products store 145000 inodes, that I couldn’t erase. Old images unused.