Jump to content

Enrique Gómez

Global Moderators
  • Posts

    1,623
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by Enrique Gómez

  1. Puede que los accesorios sea lo que necesitas. Tienes la posibilidad de añadir accesorios en la ficha de producto
  2. Es posible que te falte alguna plantilla de email en el módulo. en github esta el código fuente. En una instalación Española además en la carpeta mails estaría la subcarpeta /es con los emails traducidos https://github.com/PrestaShop/mailalerts
  3. Parece complicado... Yo diría que hay algún módulo "enganchado" en el hook de cambio de cantidad (p.ej Mailalerts..creo que en ps17 también está) que debe tener información de ese producto concreto y da algún problema.. Posiblemente sea buena idea mirar de desactivar los módulos enganchados al hook de cambio de cantidades
  4. Warehouse ya hace tiempo que dejo la rama 1.6 de su tema/módulos. Actualmente van evolucionando su tema/módulos para 1.7. No es posible actualizar al último tema sin actualizar antes prestashop
  5. Quizás el nombre del producto tiene el carácter "|"? Si realizas alguna modificación te deja guardar? Es bastante extraño lo que comentas
  6. La única cosa que se me ocurre es que al producto se le este aplicando una regla de impuesto con varios impuestos Nunca he usado estas opciones ... pero todo apunta a que se aplican dos impuestos -> uno detrás de otro
  7. En principio diría que si añades esta regla css customizada #index #wrapper { padding-top: 0 !important; } te quitará el padding
  8. En general siempre es mejor usar un módulo si quieres que haya una integración mas sencilla Yo he encontrado este https://addons.prestashop.com/es/blog-foro-noticias/19299-xen-forum.html Si realmente necesitas un foro muy cañero abría que ir a un cms específico para foros, pero la integración sería complicada. Saludos
  9. De entrada en el panel de control de hosting (ideal si tienes plesk p.ej) el dominio nuevo tiene que añadirse a la suscripción y "apuntar" a la carpeta httpdocs. Luego se configura ese dominio en la multitienda editando el antiguo cosa que modificará (entre otras cosas) el htaccess y ya podrás acceder.
  10. De entrada el módulo candidato a ser desactivado es Merchant Expertise, de hecho ese módulo es mejor desinstalarlo por completo.. solo da problemas Saludos
  11. te paso un shopify que es de donde sacamos la idea de este plugin Salta un popup con el calendario, pero el widget se pude incurstar de otras formas https://www.contentbeautywellbeing.com/pages/digital-make-up-consultations
  12. El nombre que aparece en el megamenú debería ser editable y no tener nada que ver con el nombre de la categoría. Depende del megamenú que uses, pero seguro que te deja editarlo.
  13. Esto que comentas no es normal, es posible que hayas metido algún fallo en el css. Una coma mal puesta puede arruinar un css
  14. Puedes mirar en Modulos posiciones los módulos anclados a hookActionCartSave y desactivarlo selectivamente. Es posible que alguno este tardando demasiado en hacer su trabajo
  15. Curiosamente metí hace poco un widget en un prestashop de https://calendly.com/es . Saludos
  16. Se trata de una versión vieja en 1.6 pero diría que tiene que funcionar en cualquier módulo mrwtracking. El módulo desactivado o "desenganchado" del hookBackOfficeFooter para que no se ejecute automáticamente y de problmeas Luego se mete este fichero cron.php y se programa un cron que se ejecuta en paralelo y no "atasca" la web cada X tiempo, si el cron da un timeout no hay problema. El cron solo llama al hookBackOfficeFooter La url con una clave de seguridad que se puede cambiar en el código fuente de forma sencilla tu_web/modules/mrwtracking/cron.php?token=CLAVE_SECRETA if ($sToken == 'CLAVE_SECRETA') cron.php
  17. Yo tengo la mayoría de clientes en 1.6 ya que son tiendas con bastantes ventas donde se ha invertido muchas horas en programaciones a medida. Ahora están en php 7.1 y mas adelante se mirará pasar a php7.2/7.3... Al cliente no le compensa hacerlo todo de nuevo ya que las actuales funcionan correctamente y se siguen evolucionando sin problemas. De la 1.7 me ha sorprendido "negativamente" algunos fallos que no existen en la 1.6 con la multitienda p.ej. Se que están preparando mejoras con la multitienda y van a arreglar estos problemas.. pero es que estamos hablando casi de 4 años ya .. En mi opinión el equipo de prestashop va en una buena dirección, pero es también evidente que se equivocó con la 1.7. Hasta prácticamente la 1.7.4 ha tenido muchos fallos y se ha ganado a pulso una cierta desconfianza.. Creo que intentaron abarcar demasiado teniendo en cuenta el tamaño del equipo IT.. Aunque la versión actual es estable desde hace ya un tiempo, para mí esta siendo una versión de transición hacia algo mejor. Saludos Enrique
  18. Échale un vistazo a a ver si es uno de los modulos . A malas hay que revisar el log de accesos a ver si se detecta el coladero, típicamente un php para subir ficheros donde te suben lo que quieren.. Suerte
  19. En la gran mayoría de tiendas las imágenes de productos son las mismas. No es una funcionalidad "normal" por lo que prestashop no la tiene de serie. En addons existe un módulo que permite gestionarlo https://addons.prestashop.com/es/fotos-productos/24807-multi-language-image-product-image-per-language.html Saludos
  20. No estoy para nada de acuerdo.. En lo que respecta a seguridad hay gente detrás. Hay demasiadas tiendas 1.6 como para que no haya soporte para temas críticos (no oficial, pero si comunitario -> voluntarios) , evidentemente la rama 1.6 ya hace tiempo que no evoluciona https://build.prestashop.com/news/1.6.1.x-what-s-next/ Mismamente uno de los voluntarios, Olivier le corre tiene un pull para hacer compatible la 1.6.1.x con las versiones recientes de php https://github.com/PrestaShop/PrestaShop-1.6/pull/4 Esta claro que todas las tiendas tarde o temprano tienen que plantearse la evolución de su ecommerce, por temas de seguridad, funcionales,estéticos..etc. Pero ahora mismo se puede tirar de una 1.6 durante algún tiempo y llegado el momento aprovechar y hacer la migración junto con otros cambios para evolucionar la web. El principal escollo para migrar es el coste.. Saludos Enrique
  21. Deduzco que no lo han arreglado por la respuesta del 30 de diciembre de @serpega. Estos problemas de acceso a APIS de terceros no son raros, incluso hubo una época que las conexiones de prestashop en el backoffice a la api de addons fallaba. Por eso sacaron una librería "CIRCUIT BREAKER LIBRARY" para la 1.7 https://build.prestashop.com/news/resilient-php-applications/
  22. Si el servicio web no funciona, si cambias 5 por 60 se te atascará la tienda a los 60 minutos desde la última llamada en lugar de cada 5 minutos. Suponiendo que el Servicio Web esta caído, si ha pasado una hora de la última llamada, el resto del día no podrás entrar al backoffice. Y no es a los 60 minutos de duración de la conexión del backoffice, es a los 60 minutos desde la última llamada, vamos que se te atascará igualmente. También puedes poner 1000000 minutos y problema solucionado! Ah si, pero ahora no se esta llamando a la funcionalidad y no se están actualizando los pedidos. Es decir, que la solución es eliminar la funcionalidad.. O programar un cron que es lo mas lógico. En cualquier caso el aviso original del post es de hace casi 4 años mas que nada para que la gente lo tuviese en cuenta, pensaba que lo habrían modificado pero veo que no.. Y por cierto la edición, al menos en el momento de la incidencia, de los 5 minutos es manual en el código fuente ($dif['min']) > 5) Aquí la función original del módulo public function hookBackOfficeFooter($params) { $fecha = Configuration::get($this->rename . 'LAST_EXECUTE_MRW'); $dif = $this->getTimeDif($fecha); $this->writeTolog('hookBackOfficeFooter:-> Entramos en el hookBackOfficeFooter'); $this->writeTolog('hookBackOfficeFooter:-> $fecha = ' . $fecha); $this->writeTolog('hookBackOfficeFooter:-> $dif = ' . $dif['min']); if ((int) ($dif['min']) > 5) { if ($this->debug_activo == '1') $this->writeTolog('hookBackOfficeFooter:-> Entramos en el HOOK. Hace ' . (int) ($dif['min']) . ' minutos que se ejecutó la última vez'); $this->executeGetTrackingMRW(); Configuration::updateValue($this->rename . 'LAST_EXECUTE_MRW', $dif['lastTime']); } }
  23. Efectivamente, lo normal sería en este caso programar un cron que llame a un script (como hacen cientos de módulos) para que realice la tarea que hoy se hace en el hookBackofficeFooter. Al ejecutarse en el mismo hilo sin ningún timeout razonable (salvo el timeout del hosting), te bloquea el backoffice. Si se ejecuta en el cron, si el WS no funciona, acabará dando un timeout (típicamente a los 5 minutos, pero es configurable) pero no afectará en nada ya que se ejecuta en su propio hilo. Porque no lo hacen? Yo creo que hay muchos hostings que incluso no ofrecen la posibilidad de programar crons (o hay que pagar un extra) y MRW no quiere una capa extra de problemas de configuración (suelen dar soporte) porque la mayoría de gente no sabe como configurarlo en el panel de control que tenga. A parte que estar pululando por el backoffice no es la mejor manera de controlar que se ejecuten estas cosas.. si no entras al backoffice no se ejecuta..
×
×
  • Create New...

Important Information

Cookies ensure the smooth running of our services. Using these, you accept the use of cookies. Learn More