Bieżący sklep to 1 podczas uruchamiania skryptów aktualizacji

Masz pojęcie, dlaczego Mage::app()->getStore()zwraca widok sklepu o identyfikatorze 1, gdy jest on wewnątrz skryptów aktualizacji niezależnych od widoku sklepu, w którym uruchamiam skrypt aktualizacji (nawet admin)?
Wiem, gdzie jest kod, który to robi. W Mage_Core_Model_App::getStore()tam jest taka:

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

i _getDefaultStorewygląda tak:

   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 jest zawsze pusty po osiągnięciu powyższej metody.

Otrzymuję ten sam wynik, nawet jeśli dodam go na górze skryptu aktualizacji:

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

Jestem ciekawy logiki biznesowej posiadania tej „funkcji”.

Uwaga: nie zapominaj, że zakres sklepu administratora nie jest ustawiony, dopóki nie zostanie wysłana i nie zostanie uruchomiony kontroler rozszerzający Mage_Adminhtml_Controller_Action(zobacz adminhtml_controller_action_predispatch_startzdarzenie i powiązany obserwator w Mage_Adminhtml_Controller_Action::preDispatch()).

Jestem ciekawy logiki biznesowej posiadania tej „funkcji”.

Nie jesteś jedyny; powiedziawszy, możemy nigdy nie wiedzieć, chyba że Moshe lub Dima będą chcieli omówić.

Skrypty instalacyjne są uruchamiane na początku inicjalizacji aplikacji. Konstrukcja tego prawdopodobnie wynika z tego, że zanim reszta stosu zostanie wykonana, niezbędne migracje i inne prace zostaną „wykonane” - co oznacza, że ​​system był gotowy do użycia od razu, nawet gdy moduł był instalowany lub zaktualizowane. Zastanawiam się, czy pierwotni architekci początkowo kiedykolwiek sądzili, że będzie potrzeba bardziej zainicjowanego systemu. Przypuszczę, że chociaż większość kodu zakłada, że dostępna jest instancja sklepu, to_getDefaultStore() logika zapewnia, że ​​istnieje instancja sklepu.

Ustawienia pełnego zakresu są dostępne w wersji 1.4.0.0 i nowszej za pośrednictwem skryptów konfiguracji danych.

Ok, aby użyć sklepu administratora w skryptach aktualizacji, wystarczy użyć

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

Twoje podejście Mage::app()->setCurrentStore(Mage::getModel('core/store')->load(Mage_Core_Model_App::ADMIN_STORE_ID)); nie może się powieść, ponieważ nie istnieje tak naprawdę wczytywalny widok sklepu dla administratora

Często używam takiego wzoru:

// 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());

W przeciwnym razie czasami po wykonaniu skryptu aktualizacji odwiedzający będą czasami przekierowywani na stronę administratora zamiast do interfejsu użytkownika.

Aktualizacja:

Źle zinterpretowałem poniższe pytanie, więc oto nowa próba wyjaśnienia ^^

Skrypty aktualizacji są wywoływane z metody głębiej w rdzeniu ( Mage_Core_Model_Resource_Setup::_modifyResourceDb(...))

Tutaj próbowałem wymienić stos

• 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)

a teraz spójrz na 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;
}

metoda _initModules()jest wywoływana przed $scopeCodei $scopeTypejest określana.

Obecnie nie mogę ustalić, gdzie zdefiniowano zakładany powrót.

Więc podstawowa odpowiedź jest taka, że ​​faktycznie dostaje się do 3. jeśli ..... poczekaj co :(

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

Dla mnie zwraca prawdę Mage::isInstalled()i fałsz, dla $this->getUpdateMode()których brzmi to źle. Ale dzieje się to tylko przy pierwszym trafieniu getStore.

Wygląda więc na to, że konfiguruje sklep przed ustawieniem trybu aktualizacji, a następnie, gdy wraca do skryptu konfiguracji, używa domyślnego wywołania sklepu, które używa następującego kodu:

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

Wartość self::DISTRO_STORE_ID1 to chyba dlatego, że coś potrzebuje i nie została skonfigurowana dla nas w sklepie administratora :(

Tak naprawdę mam system, który nie przechowuje z identyfikatorem 1 i skrypt aktualizacji wydaje się działać dobrze. Jeśli dodajemy tabele / atrybuty, jest w porządku i nawet przy dodawaniu bloku cms specyficznego dla strony działa to również działa, ale otrzymujemy cały identyfikator sklepu i ustawiamy je konkretnie podczas zapisywania specyficznych danych sklepu.