Module tab very slow loadnig and no module update

[zabamich]

My back office loading time is about 0.3s but when I;m trying open module tab loading time is 5-7 sec, also  no modules update.

I checked setting in administration panel, and is active check module update.

 

How to fix update problem, and why take to long to load tab with module??

 

[NemoPS]

What if you disable the automatic check? Does it get faster?
If not, do you have any third party module that might need to connect to an external service, perhaps to check licenses?

[zabamich]

When automatic check is off is the same few seconds to load modules tab.

I think this issue has some connection with class_index.Php. This file was missing in cache folder. Now this file is created one more time.

I don't have any new modules. Up to yesterday all was fine with loading time.

[NemoPS]

Are you using 1.6.0.9? As you mention the class index, which was bugged

Although creating a file shouldn't take that much really

[zabamich]

Yes 1.6.0.9

[NemoPS]

And you applied this?

 

 

https://github.com/PrestaShop/PrestaShop/blob/8288a6fffa0eb7a42b280298f798ff9292dd7be3/classes/PrestaShopAutoload.php

[zabamich]

Yes and file class index. Php was created, but bug with loading time on module tab still it is.

[exadra37]

A little late to the party, but i run also in the issue of loading time for Modules tab, during an upgrade i am doing to a client from 1.3 to 1.6.0.14, but i want to share what i have discovered.

 

My findings is that the blame goes to the new functionality that Prestashop have to track if all the Modules in your modules folder is from the original installation, Addons or from third parts.

 

The performance issue is more evident if you do not have Cache enabled.

 

Also note that the third part modules are the ones being more expensive in time spent to perform the check.

 

If you are a Developer you can continue reading, but if you are not or only have limited knowledge about Software Development, the only thing you need to know is if you still have this performance issue with Cache enabled and want to avoid it, you just need to edit the method Module::isModuleTruted() and leave the method like this:

/**
 * Return if the module is provided by addons.prestashop.com or not
 *
 * @param string $name The module name (the folder name)
 * @param string $key The key provided by addons
 * @return integer
 */
final public static function isModuleTrusted($module_name)
{
    return true;
}

NOTE: I complete disagree with editing the core code and always prefer to use the override class, but here once the method is declared as a final method, is not possible to override it.

 

Now if you fill adventorous and want to understand what is going on you can try to understand what i will try to explain... English is not my natural language, so excuse me in advance if is not correct.

 

The problem with this check is the implementation, that is not well design, once is very repetitive in some situations:

• every time we load the modules tab in BO we will call Module::getModulesOnDisk() to perform a lot of actions for each module present in our modules directory, no matter if is installed or not. This will be happening in this foreach for all modules retrieved from modules dir using the method Module::getModulesDirOnDisk().
• During the foreach we can call Module::isModuleTrusted() from several places inside of the foreach, leading to situations where Module::isModuleTrusted() will be called more than once, what is bad design and a performance killer.
• Inside of method Module::isModuleTrusted() when making this call to self:generateTrustedXml() it will call again Module::getModulesDirOnDisk() and walk all again the modules dir, checking the Prestashop Api by call  Module::checkModuleFromAddonsApi() again in order to be able to generate a new xml trusted file for all trusted modules. The problem is that we are repeating the modules dir scan and the Prestashop Api calls and this will happen for each module that will trigger the need of generate a new xml file in this if condiftion. This is a really performance killer.
• The Module::checkModuleFromAddonsApi() is by it  self also repeating actions already performed, like  when is performing this call to Module:getInstanceByName() and instantiating the module class again inside of this if block, that can have been already instantiated previously in this line. So one more possible duplication of code execution.

 

So this really very hard to grasp and takes a lot of time and effort to realise what is going on. This needs a lot of debug putted inside of the code to log the flow of the actions into the console or into a file in order you can understand in which order things are being repeated.

 

I am really tired of debug this and with a need to sleep, therefore you find some inconsistency in my explanation, let me know so that i can double check if was a misunderstanding from my part or just a mistake writing here.

 

Tip for Developers:

<?php

/**
 * Example for third part Module not in Prestashop Addons, therefore without a valid module key.
 *
 * @author Exadra37 <exadra37ingmailpointcom>
 * @link   exadra37.com
 * @since  2015/04/04
 * 
 */
class Exadra37Example extends Module
{
    /**
     * Declare this property as empty will avoid a call to Prestashop Api to see if the module key is a trusted one.
     *
     * @see  https://github.com/PrestaShop/PrestaShop/blob/1.6.0.14/classes/module/Module.php#L1705-L1706
     * 
     * @var string
     */
    public $module_key = '';

    public function __construct()
    {
        // code here as normal
    }

    // all your methods here as normal
}

Edited April 4, 2015 by exadra37 (see edit history)

[aviel]

Exadra37, you are the saviour of my life.

I love U  hahaha

 

Thanks! I was crazy trying to fix that bug.

 

Regards,

[eleazar]

Edited October 4, 2015 by eleazar  (see edit history)

[exadra37]

Glad that my info was useful

 

@razaro and @eleazar thanks for the click in Like This

[jetx]

Most helpful!

[mattimattimatti]

Very nice. Thanks!

[Dmitrrry]

exadra37, you simply the best