Píldoras PrestaShop de febrero de 2023: overrides, hooks y menús
Las ideas sueltas de febrero de 2023 en la comunidad: cómo hacer bien un override, por qué buscar antes un hook, cómo cambiar estados de pedido desde código y varios avisos de servidor y de plantillas.
Febrero de 2023: muchas preguntas de desarrollo (overrides, hooks, estados de pedido), avisos de servidor y algún susto con las plantillas. Las ideas sueltas del mes.
No metas imágenes en los menús
Gustavo se encontró un menú que cargaba 159 ficheros, uno por cada imagen de cada categoría, y ha visto casos peores. Otro miembro añadió el remate: imágenes de 8 MB en el menú. El menú se carga en todas las páginas, así que cada imagen que le pongas la paga cada visita. Deja el menú en texto y, si quieres imágenes de categoría, ponlas en la portada o en la propia categoría, optimizadas.
Al hacer un override de una clase, conserva sus use
Un compañero hizo su primer override de PaymentModule::validateOrder() para añadir un campo al correo del pedido, y le daba error. Otro miembro le dio dos claves: si lo haces a mano, borra la caché después, y copia también las líneas use que necesite el código, como use PrestaShop\PrestaShop\Adapter\StockManager;. Tu fichero de override no hereda los use del original: si tu método usa una clase con espacio de nombres, tienes que declararla tú.
Si el método es private, el override no llega: busca un hook
El mismo compañero intentó después sobrescribir un método de un controlador que llamaba a otros métodos private, y fallaba. Desde un override no puedes llamar a métodos privados de la clase original: solo te queda copiarlos también, con el riesgo de que dejen de coincidir al actualizar. Gustavo propuso lo de siempre: busca primero un hook. En las últimas versiones de la 1.7 se añadieron muchos que evitan overrides.
Cambia estados de pedido con OrderHistory, no con un UPDATE
Consejo de Gustavo para quien cambia estados de pedido desde código: no toques la tabla con SQL. Usa el historial de estados, que es lo que dispara los hooks de cambio de estado, y así se enteran los módulos que dependen de ellos (facturación, avisos, conectores):
$history = new OrderHistory();
$history->id_order = (int) $order->id;
$history->changeIdOrderState((int) $idEstado, $order, true);
$history->addWithemail();Él mismo había tenido problemas con códigos que cambiaban el estado por otra vía. Pruébalo antes en una copia de la tienda.
Datos bancarios vacíos al reenviar el correo de transferencia
Un compañero vio que, al reenviar desde el back-office el correo de un pedido por transferencia, los datos bancarios llegaban vacíos, mientras que el cliente sí los recibía al hacer el pedido. Él mismo encontró la explicación: es un fallo conocido de PrestaShop 1.7.6, documentado en esta incidencia del repositorio oficial, cerrada como resuelta en 2020. Antes de tocar plantillas de correo, busca en las incidencias del repositorio: muchas rarezas ya están contadas.
Error 413 al subir ficheros: mira también el servidor web
Un compañero con servidor dedicado recibía un «413 Request Entity Too Large» al subir ficheros. Subió todos los valores de subida en php.ini y seguía igual. Otro miembro dio la pista: si hay un nginx delante, él también limita el tamaño de lo que se envía. El 413 lo da el servidor web antes de que la petición llegue a PHP, así que hay que subir los dos límites: el del servidor web (en nginx, client_max_body_size) y los de PHP (upload_max_filesize y post_max_size).
De CentOS 7 a AlmaLinux: servidor nuevo, no actualizar encima
Alguien preguntó por pasar un VPS de CentOS 7 a AlmaLinux 8. Dos miembros que lo habían probado coincidieron: instalar AlmaLinux desde cero va bien; la herramienta de migración en caliente les salió mal en todos los casos y después fallaban cosas al azar, como memcached. La recomendación: monta un servidor nuevo y migra las webs. Nunca lances una actualización de sistema operativo sobre un servidor en producción.
El cliente no puede marcar productos para devolver
Un compañero tenía las devoluciones activadas, pero el cliente no podía elegir qué producto devolver: la casilla no aparecía y, al mostrarla con CSS, no se podía marcar. Gustavo repasó lo que tiene que cumplirse: devoluciones activadas en el back-office, plazo en días configurado y sin superar, y el pedido en un estado que lo permita: en el código de PrestaShop, el estado actual tiene que estar marcado a la vez como pagado y como enviado (son casillas de cada estado). Si todo eso está bien y la casilla no responde, el culpable suele ser el CSS o el JavaScript del tema, como apuntó otro miembro.
Una plantilla que sobrescribe un módulo puede romper el RGPD
A un compañero no le salía la casilla de consentimiento en el formulario de alertas por correo. Gustavo le dio la pista: la plantilla tenía su propia copia del TPL del módulo en themes/tu-tema/modules/, hecha sin el hook del módulo de RGPD. Al renombrar esa carpeta, el módulo vuelve a usar su TPL original. Pasa a menudo con plantillas antiguas: si una casilla legal desaparece, mira si el tema sobrescribe el módulo.
Esto salió en @PrestashopEsp, la mayor comunidad PrestaShop de España en Telegram. Ver la conversación