w3bsolutions

Aquí van un par de hilos con los que tenemos/hemos tenido el mismo problema con Siteground, que tienen un límite de 4096 archivos abiertos salvo en los servidores Cloud (que en mi opinión debería ser suficiente, si algún proceso necesita más archivos abiertos es que seguramente no está optimizado). Haciendo análisis del código he podido encontrar varios sitios donde eso estaba pasando. :

¿Qué peso tiene puesto el zueco cuando te está cobrando el precio de envío más alto?

Totalmente de acuerdo contigo. Si siempre vas a añadir número de seguimiento a los envíos, puedes desactivar el email de "shipped" en el estado de pedido "Enviado" tranquilamente.

Pues haciendo eso lo quitas de todas partes, incluida la página de productos y la de pago. Y si actualizas el módulo volverán a aparecer. El tutorial del link de @pullidea-dev es justo para lo que pedías, poder ajustar en qué páginas se cargan qué ficheros CSS/JS. ¿Has comprobado que sigan cargándose en la página de productos y de pago?

Normalmente, tendrías que cambiar primero a "Enviado" y así el cliente se entera de que su pedido se ha enviado. Y luego, si tienes un número de seguimiento lo metes y se le mandaría el email con el número de seguimiento. Hay muchas tiendas online aún (lamentablemente) que no mandan el número de seguimiento, con lo cual el primer email le viene bien al cliente. El email con el número de seguimiento no se configurar si se envía o no, se envía siempre. Si quieres desactivarlo habría que programarlo.

I just stumbled upon this issue (in PS 1.6.1.20) after losing so much time trying to figure out what was happening. Sad this was never fixed in PS 1.6

The ulimit is the same for Startup, GrowBig and GoGeek. You can only change it in cloud plans.

I agree with you 100%. But unfortunately Prestashop core developers don't check the forums. So you have to open an issue at https://github.com/PrestaShop/PrestaShop if you want any feedback from them.

I had this issue also with one shop, where I couldn't open the autoupgrade config page directly, I was already getting the "too many open files" (500 error) directly. I did some debugging and it turns out when you open the page it runs some tests on your installation. Some of these tests just check if directories are writable, and specifically one of the tests checks if each directory in the /img directory is writable... recursively. This shop had several thousand images (more than 4096) and it was breaking there. So I created an override to disable the recursively in this test, and then I could open the autoupgrade configuration page fine. Attached is the override. If you want to test it, just place it under /override/classes. Note that in this shop this test was the problematic one, but there are other tests it is running that are also still using recursivity on nested directories, so they could also give problems. You can see which ones exactly in /classes/ConfigurationTest.php. All the tests in there are executed when you open the autoupgrade configuration page. P.S. It is giving an error when uploading the PHP override, so I just put it in a zip to overcome this. ConfigurationTest.php.zip

Workaround if you don't wanna spend that money just to be able to upgrade:

I have several shops on SG Startup Plan too. The shops are working fine for the traffic they have, so imho no need to change hosting plans just to be able to upgrade. My workaround so far, which is pretty straightforward: Download latest version of Prestashop zip: https://www.prestashop.com/en/versions Login to your Site Tools and go to the Files Explorer /public_html/[admin_directory/autoupgrade/latest and upload the zip there Extract zip, which contains another prestashop zip, extract it as well. Move all prestashop folders and files from the extracted zip to hang directly from the /latest directory (where you uploaded the zip). Although they are many files, you can select them all and move (or drag and drop) in Site Tools and it takes just a couple seconds to move them. Go to the auto upgrade module configuration change, hit on "Expert mode", pick "Local Directory" channel and type the version of prestashop you are upgrading too. For the current version this would look like this: Hit "Save" and upgrade works fine. Cheers.

Glad I could help. Same for you!

linking this since it's the same problem:

Ok... is the whole dashboard blank or only the metrics section? Check if this is your problem as well:

What do you see when you enable debug mode?

Clear your local storage and refresh. If you don't know how, clear all your cache and it should also work. The entry below (example in Safari) is the problematic one:

I've experienced the same issue on Siteground on a shared account. On the cloud packages you can modify this configuration as you with. What I find ridiculous is that the 1-click upgrade module needs to open more than 5k files. That's crazy and should be improved on the module.

Since it is a theme-specific issue, try replacing your classic theme folder with the one in the PS 1.7.8.1 download, clear your caches and see if it's solved.

Did you also upgrade the default theme (enabled the option in the auto-upgrade settings) when upgrading to 1.7.8.1? Cuz the fix (https://github.com/PrestaShop/PrestaShop/pull/26410/files) was included in 1.7.8.1: https://github.com/PrestaShop/PrestaShop/releases/tag/1.7.8.1

Did you guys also upgrade the default theme? or are you using a custom theme?

El módulo a día de hoy no lo permite, no es que estés haciendo nada mal. Habría que cambiar bastante código, no es tarea sencilla.

¿No será que los usuarios no están volviendo a la tienda desde la pasarela de pagos (haciendo click en "continuar" o "volver a tienda")? y luego entran a mirar si está el pedido en el historial de pedidos?

¿Qué tipo de cachés tienes activadas? Algún módulo de optimización? Esto me pasó en una tienda una vez hace mucho tiempo y era por una caché que tenía activada en el servidor que estaba cacheando "demasiado".

Adjunto la versión 5.1. Con esta debería funcionar. ps_accounts.zip

Have you tried with the code suggested above by @toimata? .js-address-form .form-group:first-of-type { display: none!important; }