Solicitud de Magento: ¿Frontend o Backend?

Question

¿Cómo puedo saber si la solicitud actual es para una página de back-end o frontend? Esta verificación se realizará dentro de un observador, por lo que tengo acceso al objeto de solicitud si eso ayuda.

Consideré revisar Mage::getSingleton('admin/session')->getUser() pero no creo que sea un método muy confiable. Estoy esperando una mejor solución.

Answer 1

Esta es una de esas áreas donde no hay una buena respuesta. Magento no proporciona un método/API explícito para esta información, por lo que con cualquier solución necesitará examinar el entorno e inferir cosas.

que estaba usando

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

por un tiempo, pero resulta que hay ciertas páginas de administración (el gerente Magento Conectar el paquete) que esto no es cierto. Por alguna razón, esta página establece explícitamente que el ID de la tienda sea 1, lo que hace que isAdmin devuelva como 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'); 
} 

Puede haber otras páginas con este comportamiento,

Otra buena apuesta es comprobar la propiedad "zona" del paquete de diseño.

Parece menos probable que se anule esta opción para una página que está en el administrador, ya que el área afecta la ruta a las plantillas de diseño de áreas de administración y los archivos XML de diseño.

Independientemente de lo que decida deducir del medio ambiente, crear un nuevo módulo de Magento, y añadir una clase de ayuda a que

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; 
    } 
} 

y luego cada vez que es necesario comprobar si estás en la administración, uso este helper

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

esta manera, cuando/si se descubre agujeros en la lógica de la comprobación de administración, se puede corregir todo en un lugar centralizado.

Answer 2

Tenga una mirada en el interior de los métodos Mage/Core/Model/Store.php usted desee utilizar:

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

En conjunción con

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

Actuar como punto de retorno, donde el ID de tienda no se establece como espera (Magento connect etc.)

Answer 3

Si puede usar un observador, puede limitarlo al área de 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 4

Me gusta la respuesta de beep logic: tiene sentido en el contexto de los observadores. También me gusta el argumento de Alan de que no hay forma de conocer el estado de administración en todos los contextos, que es una función de "el administrador" que es un estado que se ingresa después de inicializar la aplicación y el controlador frontal.

El estado de administración de Magento se crea efectivamente desde el envío de control a un controlador de acción de administrador; ver Mage_Adminhtml_Controller_Action::preDispatch(). Este es el método que desencadena el evento adminhtml_controller_action_predispatch_start, que es consumido por Mage_Adminhtml_Model_Observer::bindStore(), que es donde el almacén de administración inicialmente se "establece".De hecho, las áreas de configuración del observador (adminhtml vs frontend) "funcionan" debido a la clase de controlador de acción principal - consulte Mage_Core_Controller_Varien_Action::preDispatch(), específicamente Mage::app()->loadArea($this->getLayout()->getArea()); - solo tenga en cuenta que el objeto de disposición tiene su información de área configurada en adminhtml predispatch.

Independientemente de cómo lo corte, el comportamiento de administración del que dependemos en tantos contextos -incluso algo de alto nivel como el sistema de observadores de eventos- depende de la estructura de control de comandos.

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

En su definición observador:

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: Utilice un observador, incluso utilizar el mismo modelo de observador, sino que pasan en el contexto especificando un método de llamada diferente.

HTH.

edición: añadido código de ejemplo usando config de la lógica pitido como punto de partida

Answer 5

Si estoy equivocado o no (pero yo he probado), algunos eventos (como controller_front_init_before) sólo se pueden sobrescribir en el interior nodo global. Como resultado, esta anulación afectará tanto al frontend como al back-end.

Luego, venga la solución de Alan y Benmark al rescate para especificar si desea aplicar el observador solamente en frontend o backend.