Bug in (Native) OXID PayPal Module – CE/PE 4.9.2

Recently, while developing a PE/CE-Template in version 4.9.1, we noticed a strange problem that deactivating OXID’s native PayPal module was whacking the template. Not pretty, since this customer wasn’t interested in offering PayPal as a payment provider in some of her markets.

Thankfully, OXID’s API has made nice provisions since 4.6 PE/CE to elegantly activate/deactivate modules. There is however one tiny bug that the native PayPal module developers left in the module’s deactivation-code.

Below public deactivate() function does the job in the module.

public function deactivate(oxModule $oModule)
        $blResult = false;
        $sModuleId = $oModule->getId();
        if ($sModuleId) {
            $sModuleId = $oModule->getId();
            $this->_callEvent('onDeactivate', $sModuleId);
            //removing recoverable options
            //resets cache
            if ($this->getModuleCache()) {
        $blResult = true;
In the above function module data is being deleted from database, after which the cache is being attempted to be reset (effectively delete parts of tmp/ which pertain to the module). Below function, used to clean the cache, however attempts to obtain the list of templates using getTemplates(), which is bound to return an empty list, owing to the above sequence of calls.
public function resetCache()
    $aTemplates = $this->getModule()->getTemplates();
    $oUtils = oxRegistry::getUtils();

    $oUtilsObject = oxUtilsObject::getInstance();

Because of this, the parts of the cache (/tmp) pertaining to the module remain un-deleted, causing the template to break upon module-deactivation.

Leave a Reply