Le magasin actuel est 1 lors de l'exécution des scripts de mise à niveau

Une idée pourquoi Mage::app()->getStore()retourne la vue du magasin avec l'ID 1 lorsque dans les scripts de mise à niveau indépendamment de la vue du magasin dans laquelle j'exécute le script de mise à niveau (même administrateur)?
Je veux dire, je sais où est le code qui fait ça. Il Mage_Core_Model_App::getStore()y a ceci:

    if (!Mage::isInstalled() || $this->getUpdateMode()) {
        return $this->_getDefaultStore();
    }

et _getDefaultStoreressemble à ceci:

   if (empty($this->_store)) {
        $this->_store = Mage::getModel('core/store')
            ->setId(self::DISTRO_STORE_ID)
            ->setCode(self::DISTRO_STORE_CODE);
    }
    return $this->_store;

$this->_store est toujours vide lorsque vous atteignez la méthode ci-dessus.

J'obtiens le même résultat même si j'ajoute ceci en haut du script de mise à niveau:

Mage::app()->setCurrentStore(Mage::getModel('core/store')->load(Mage_Core_Model_App::ADMIN_STORE_ID));

Je suis curieux de savoir la logique métier d'avoir cette «fonctionnalité».

NB: n'oubliez pas que la portée du magasin d'administration n'est pas définie tant que la répartition n'a pas lieu et qu'un contrôleur d'extension ne Mage_Adminhtml_Controller_Actions'exécute (voir l' adminhtml_controller_action_predispatch_startévénement et l'observateur associé dans Mage_Adminhtml_Controller_Action::preDispatch()).

Je suis curieux de savoir la logique métier d'avoir cette «fonctionnalité».

Vous n'êtes pas le seul; Cela dit, nous ne le saurons peut-être jamais à moins que Moshe ou Dima ne veuillent discuter.

Les scripts d'installation s'exécutent tôt dans l'initialisation de l'application. La conception de ceci est probablement due pour que, au moment où le reste de la pile soit exécuté, les migrations et autres travaux nécessaires soient "effectués" - ce qui signifie que le système était prêt à être utilisé immédiatement même lorsqu'un module était en cours d'installation. ou mis à niveau. Je me demande si les architectes originaux ont d'abord pensé qu'il y aurait besoin d'un système plus initialisé. Je suppose que, alors qu'une grande partie du code suppose qu'une instance de magasin est disponible, la _getDefaultStore()logique garantit qu'il existe une instance de magasin.

Les paramètres complets sont disponibles dans 1.4.0.0 et versions ultérieures via des scripts de configuration des données.

Ok, pour utiliser le magasin d'administration dans vos scripts de mise à niveau, utilisez simplement

Mage::app()->setCurrentStore(Mage_Core_Model_App::ADMIN_STORE_ID);

Votre approche Mage::app()->setCurrentStore(Mage::getModel('core/store')->load(Mage_Core_Model_App::ADMIN_STORE_ID)); ne peut pas réussir, car il n'y a aucune vue de magasin chargeable réellement existante pour l'administrateur

J'utilise souvent un modèle comme celui-ci:

// remembering old current store
$currentStore = Mage::app()->getCurrentStore();

// switching to admin store
Mage::app()->setCurrentStore(Mage_Core_Model_App::ADMIN_STORE_ID);

// switching back to old current store
Mage::app()->setCurrentStore($currentStore->getStoreId());

Sinon, parfois, après l'exécution d'un script de mise à niveau, vos visiteurs seront parfois redirigés vers la page d'administration au lieu du frontend.

Mise à jour:

J'ai mal interprété la question ci-dessous, alors voici une nouvelle tentative d'expliquer ^^

Les scripts de mise à niveau sont appelés à partir d'une méthode plus profonde dans le core ( Mage_Core_Model_Resource_Setup::_modifyResourceDb(...))

Ici, j'ai essayé de lister la pile

• Mage_Core_Model_App::run($params)

• Mage_Core_Model_App::_initModules()

• Mage_Core_Model_Resource_Setup::applyAllUpdates()

• Mage_Core_Model_Resource_Setup::applyUpdates()

• Mage_Core_Model_Resource_Setup::_upgradeResourceDb($oldVersion, $newVersion)

• Mage_Core_Model_Resource_Setup::_modifyResourceDb($actionType, $fromVersion, $toVersion)

et maintenant regardez Mage_Core_model_App::run($params):

public function run($params)
{
    $options = isset($params['options']) ? $params['options'] : array();
    $this->baseInit($options);
    Mage::register('application_params', $params);

    if ($this->_cache->processRequest()) {
        $this->getResponse()->sendResponse();
    } else {
        $this->_initModules();
        $this->loadAreaPart(Mage_Core_Model_App_Area::AREA_GLOBAL, Mage_Core_Model_App_Area::PART_EVENTS);

        if ($this->_config->isLocalConfigLoaded()) {
            $scopeCode = isset($params['scope_code']) ? $params['scope_code'] : '';
            $scopeType = isset($params['scope_type']) ? $params['scope_type'] : 'store';
            $this->_initCurrentStore($scopeCode, $scopeType);
            $this->_initRequest();
            Mage_Core_Model_Resource_Setup::applyAllDataUpdates();
        }

        $this->getFrontController()->dispatch();
    }
    return $this;
}

la méthode _initModules()est appelée avant le $scopeCodeet $scopeTypeest déterminée.

Actuellement, je ne peux pas déterminer où le repli supposé est défini.

Donc, la réponse de base est qu'il entre en fait dans le 3e si ..... attendez quoi :(

if (!isset($id) || ''===$id || $id === true) {
    $id = $this->_currentStore;
}

Pour moi, cela renvoie vrai pour Mage::isInstalled()et faux pour $this->getUpdateMode()ce qui sonne faux. Mais cela ne se produit que sur le premier hit de getStore.

Il semble donc qu'il configure le magasin avant la définition du mode de mise à jour, puis lorsqu'il revient dans le script de configuration, il utilise l'appel de magasin par défaut qui utilise le code suivant:

$this->_store = Mage::getModel('core/store')
    ->setId(self::DISTRO_STORE_ID)
    ->setCode(self::DISTRO_STORE_CODE);

La valeur de self::DISTRO_STORE_IDest 1, je suppose, car il a besoin de quelque chose et n'a pas été configuré pour nous le magasin d'administration :(

J'ai donc un système qui n'a pas été enregistré avec l'ID 1 et le script de mise à jour semble bien fonctionner. Si nous ajoutons des tables / attributs, c'est bien et même lors de l'ajout d'un bloc cms spécifique au site, cela fonctionne également, mais nous obtenons tous les identifiants de magasin et les définissons spécifiquement lors de l'enregistrement des données spécifiques au magasin.