Richiesta Magento - Frontend o Backend?

Question

Come posso dire se la richiesta corrente è per un backend o una pagina frontengata?Questo controllo verrà fatto all'interno di un osservatore, quindi ho accesso all'oggetto di richiesta se questo aiuta.

Ho considerato il controllo del Mage::getSingleton('admin/session')->getUser() ma non penso che sia un metodo molto affidabile.Spero in una soluzione migliore.

Answer 1

Questa è una di quelle aree in cui non c'è una buona risposta. Magento stesso non fornisce un metodo / API esplicito per queste informazioni, quindi con qualsiasi soluzione dovrai esaminare l'ambiente e inferire le cose.

Stavo usando

Mage::app()->getStore()->isAdmin()

.

Per un po ', ma si scopre che ci sono alcune pagine di amministrazione (il gestore del pacchetto Magento Connect) dove questo non è vero. Per qualche motivo questa pagina imposta esplicitamente l'ID del negozio per essere 1, il che rende isAdmin return come falso.

#File: app/code/core/Mage/Connect/controllers/Adminhtml/Extension/CustomController.php
public function indexAction()
{
    $this->_title($this->__('System'))
         ->_title($this->__('Magento Connect'))
         ->_title($this->__('Package Extensions'));

    Mage::app()->getStore()->setStoreId(1);
    $this->_forward('edit');
}

.

Ci possono essere altre pagine con questo comportamento,

Un'altra buona scommessa è quella di controllare la proprietà "Area" del pacchetto di progettazione.

Sembra meno probabile che sia sovrascritto per una pagina che è nell'amministratore, poiché l'area influisce sul percorso verso i modelli di progettazione delle aree di amministrazione e dei file XML del layout.

Indipendentemente da ciò che scegli di dedurre dall'ambiente, creare un nuovo modulo Magento e aggiungere una classe di helper ad esso

class Namespace_Modulename_Helper_Isadmin extends Mage_Core_Helper_Abstract
{
    public function isAdmin()
    {
        if(Mage::app()->getStore()->isAdmin())
        {
            return true;
        }

        if(Mage::getDesign()->getArea() == 'adminhtml')
        {
            return true;
        }

        return false;
    }
}

.

E poi ogni volta che devi controllare se sei nell'amministratore, usa questo aiutante

if( Mage::helper('modulename/isadmin')->isAdmin() )
{
    //do the thing about the admin thing
}

.

In questo modo, quando / se scopri i fori nella tua logica di controllo dell'amministratore, è possibile correggere tutto in un luogo centralizzato.

Answer 2

Se sei in grado di utilizzare un osservatore, puoi limitarlo all'area dell'evento 'adminhtml'.

<config>
...
  <adminhtml>
    <events>
      <core_block_abstract_prepare_layout_after>
        <observers>
          <mynamespace_mymodule_html_before>
            <type>singleton</type>
            <class>mynamespace_mymodule/observer</class>
            <method>adminPrepareLayoutBefore</method>
          </mynamespace_mymodule_html_before>
        </observers>
      </core_block_abstract_prepare_layout_after>
    </events>
  </adminhtml>
</config>

.

Answer 3

Dai un'occhiata ai metodi all'interno Mage/Core/Model/Store.php che vorresti usare:

Mage::app()->getStore()->isAdmin()

.

In congiunzione con

Mage::getDesign()->getArea() == 'adminhtml'

.

Agire come un fallback in cui l'ID del negozio non è impostato come ti aspetti (Magento Connect ecc.)

Answer 4

Mi piace la risposta del segnale acustico della logica - ha senso nel contesto degli osservatori. Mi piace anche il punto di Alan che non c'è modo di conoscere lo stato amministrativo in tutti i contesti, che è una funzione di "l'amministratore" che è stato inserito dopo che l'app e il controller anteriore sono inizializzati.

Lo stato amministrativo di Magento è creato in modo efficace dalla spedizione di controllo a un controller di azione amministratore; Vedi Mage_Adminhtml_Controller_Action::preDispatch(). Questo è il metodo che spara l'evento adminhtml_controller_action_predispatch_start, che viene consumato da Mage_Adminhtml_Model_Observer::bindStore(), che è dove è inizialmente il negozio di amministrazione ". Infatti, le aree di configurazione dell'osservatore (Amministratore VS Frontend) "funziona" a causa della classe del controller dell'azione principale - vedere Mage_Core_Controller_Varien_Action::preDispatch(), in particolare Mage::app()->loadArea($this->getLayout()->getArea()); - Basta notare che l'oggetto Layout ha le informazioni sull'area impostata nel predispatch adminhtml.

Non importa come ti affeziona, il comportamento di amministratore su cui ci affidiamo in tanti contesti - anche qualcosa di alto livello come il sistema di osservatore di eventi - si basa sulla struttura del controllo dei comandi.

<config>
  <!-- ... -->
  <adminhtml>
    <events>
      <core_block_abstract_prepare_layout_after>
        <observers>
          <mynamespace_mymodule_html_after>
            <type>singleton</type>
            <class>mynamespace_mymodule/observer</class>
            <method>adminPrepareLayoutAfter</method>
          </mynamespace_mymodule_html_after>
        </observers>
      </core_block_abstract_prepare_layout_after>
    </events>
  </adminhtml>
  <frontend>
    <events>
      <core_block_abstract_prepare_layout_after>
        <observers>
          <mynamespace_mymodule_html_after>
            <type>singleton</type>
            <class>mynamespace_mymodule/observer</class>
            <method>frontendPrepareLayoutAfter</method>
          </mynamespace_mymodule_html_after>
        </observers>
      </core_block_abstract_prepare_layout_after>
    </events>
  </frontend>
</config>

.

Nella definizione dell'osservatore:

class Mynamepace_Mymodule_Model_Observer
{
    public function adminPrepareLayoutAfter()
    {
        $this->_prepareLayoutAfter('admin');
    }

    public function frontendPrepareLayoutAfter()
    {
        $this->_prepareLayoutAfter('frontend');
    }

    protected function _prepareLayoutAfter($area)
    {
        switch($area){
           case 'admin':
               // do admin things
               break;

           case 'frontend':
               // do frontend things
               break;

           default:
               // i'm a moron
        }
    }
}

.

tl; DR : Utilizzare un osservatore, usa anche lo stesso modello di osservatore, ma passare nel contesto specificando un metodo di chiamata diverso.

hth.

Modifica : Aggiunto il codice di esempio utilizzando la configurazione del segnale acustico della logica come punto di partenza

Answer 5

Sia che io sia sbagliato o meno (ma l'ho mai testato), alcuni eventi (come controller_front_init_bront) possono essere sovrascritti solo all'interno del nodo globale.Di conseguenza, questo override influenzerà sia il frontend che il backend.

Allora viene la soluzione di Alan e Benmark al salvataggio per specificare se si desidera applicare l'osservatore solo su Frontend o Solo Backend.