Could not extend oxid core in vendorfolder

English forums
1

I try to extend the oxcategory-model with an own modul (oxid 4.7.10). Everythings works very well, if i run the modul directly in the /modules/ folder. But if i copy this folder into my venderfolder (/modules/myvendor/) it does not work any more. All the other modules in the same vendorfolder still work.

Before i copied the modul, i deactivate it. After i copied the modul i was editing the metadata file to change the path to my oxcategory-model. My vendormetadata.php is still empty.

What is wrong with the vendorfolder?

2

Sorry wrong thread, but I dont know how to fix it…

3

Sometimes if you move a module to the vendorfolder, aModulesPaths is still the old value in DB or /tmp and the module cannot be activated. Then you can delete aModulePaths in oxconfig table, clear tmp, click on “Extension/modules” to delete old values and it can be activated. Also the module should be moved to vendorfolder, not copied.

4

I still deleted the cache folder and the path in the database was changed too. I can see the configured path under the module-menu and “installed shop-modules” but the path is crossed out. and you are right, i was move the module and do not copy. And the block i use at the same modul already works!?

my given path in the metadata.php

'extend'      => array(
        'oxcategory' => 'MYVENDOR/mymodule/application/models/mymodul_oxcategory',
),
5

Hi Egoist,
this seems to be a well-known problem, and one of the easiest ways to fix it is to use a simple cleanup script, which I have attached. Please check it out, you can’t do anything wrong with it. Simply copy it to the main shop dir and call it once per browser. Some feedback would be welcome… :slight_smile:

6

Ohh cool! thank you very much. I knew that clean up the oxconfig could resolve it, but i dont want to activate each module by hand.

This script was not working after the first try, because the var $sMod looks like ‘MyVendor/MyModule’ and not only ‘MyModul’ after checking up this possibility, it works very well and i will combine it with the cache-module.

But why there is no core method, which check this possibilities up?!

7

Okay, good to hear that it was helpful again… :slight_smile:
But please tell me more detailed: did you have to change anything in the script code? That would be strange because I am using it for several months without any problem (but may be I overlooked something).

But why there is no core method, which check this possibilities up?!

I also wondered about it first. But it is because of backwards compatibility. OXID isn’t able to decide between just an old module folder (without metadata) or a new vendor folder I guess. But I think this old behaviour should gradually be dropped to avoid such confusions.

PS:

i will combine it with the cache-module.

Which module exactly do you mean? :wink:

8

I was add your script to the ocb_cache module in my project. I add a new possibility to delete these type of cache with a method

public function deleteDbModuleCache(){

        $oConf = oxRegistry::getConfig();
        $aDisabled = $oConf->getConfigParam( 'aDisabledModules' );

        // get vendor module dirs
        $aVendorDirs = array();
        foreach ( glob( $oConf->getModulesDir() ) as $sDir )
        {
            if ( is_dir( $sDir ) && file_exists( $sDir.'/vendormetadata.php' ) )
                $aVendorDirs[] = str_replace( $oConf->getModulesDir(), '', $sDir );
        }

        // cleanup
        $aCache = array();
        $blDone = false;

        foreach ( $aDisabled as $sMod )
        {
            $tmp = explode('/', $sMod);
            if (count($tmp) == 2) {
                $sMod = $tmp[1];
            }

            if ( in_array( $sMod, $aVendorDirs ) ) {
                $blDone = true;
            } else {
                $aCache[] = $sMod;
            }
        }

        if ( $aCache !== $aDisabled || $blDone ) {
            $oConf->saveShopConfVar( 'arr', 'aDisabledModules', $aCache );
        }

    }

I added the first four lines in the foreach to your script.

9

I added the first four lines in the foreach to your script.

Okay, I see. But that shouldn’t be neccessary because aDisabledModules doesn’t contain pathes at all (normally). I am afraid there are different kinds of traps you can fall into and my script was intended only to fix the “temporary missing/wrong vendormetadata problem”. :wink: E.g. this one seems to be a slightly different topic:
https://bugs.oxid-esales.com/view.php?id=4942

PS: you could shorten the last “if” a little bit to:

if ( $blDone ) {

PPS: maybe your mistake was to use “$oConf->getModulesDir()”. That gives a different result as “getShopBasePath().‘modules/*’” (from my script)! :wink:

10

E.g. this one seems to be a slightly different topic

I dont really understand the difference between these two problems? In both cases there is a wrong aDisabledModules-Array and with your script it would get fixed?

PPS: maybe your mistake was to use “$oConf->getModulesDir()”. That gives a different result as “getShopBasePath().‘modules/*’” (from my script)!

I added these lines during use “getShopBasePath().'modules/*”.

11

In both cases there is a wrong aDisabledModules-Array and with your script it would get fixed?

No, it only fixed one case, but I’ve extended it now, so it handles both cases. :slight_smile:
And of course you can use “getModulesDir()” but you have to add .‘*’ in the glob.

12

Thank you very much.

13

Sometimes if you move a module to the vendorfolder, aModulesPaths is still the old value in DB or /tmp and the module cannot be activated. Then you can delete aModulePaths in oxconfig table, clear tmp, click on “Extension/modules” to delete old values and it can be activated. Also the module should be moved to vendorfolder.