Solicitud de Magento: ¿frontend o backend?

Question

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

Pensé en comprobar Mage::getSingleton('admin/session')->getUser() pero no creo que sea un método muy confiable.Espero una mejor solución.

Answer 1

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

yo estaba usando

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

por un tiempo, pero resulta que hay ciertas páginas de administración (el administrador de paquetes de Magento Connect) donde esto no es cierto.Por alguna razón, esta página establece explícitamente que la identificación de la tienda es 1, lo que hace que isAdmin regresa 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 opción es comprobar la propiedad "área" del paquete de diseño.

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

Independientemente de lo que elija inferir del entorno, cree un nuevo módulo Magento y agréguele una clase auxiliar

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, cuando necesites verificar si estás en el administrador, usa este asistente

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

De esta manera, cuando descubra agujeros en la lógica de verificación de su administrador, podrá corregir todo en un lugar centralizado.

Answer 2

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 3

Eche un vistazo a los métodos internos. Mage/Core/Model/Store.php querrás usar:

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

en conjunto con

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

Para actuar como alternativa cuando el ID de la tienda no está configurado como se esperaba (conexión Magento, etc.)

Answer 4

Me gusta la respuesta de la lógica del pitido: tiene sentido en el contexto de los observadores.También me gusta el punto de Alan de que no hay forma de conocer el estado del administrador en todos los contextos, lo cual es una función de que "el administrador" sea un estado al que se ingresa después de que se inicializan la aplicación y el controlador frontal.

El estado de administración de Magento se crea efectivamente a partir del envío del control a un controlador de acciones de administración;ver Mage_Adminhtml_Controller_Action::preDispatch().Este es el método que dispara el adminhtml_controller_action_predispatch_start evento, que es consumido por Mage_Adminhtml_Model_Observer::bindStore(), que es donde se "configura" inicialmente la tienda de administración.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 diseño tiene la información de su área configurada en el predispatch adminhtml.

No importa cómo se mire, el comportamiento administrativo en el que confiamos en tantos contextos (incluso algo de tan alto nivel como el sistema de observación 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 de 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 utilice el mismo modelo de observador, pero pase el contexto especificando un método de llamada diferente.

HTH.

editar:Se agregó código de ejemplo usando la configuración de Beep Logic como punto de partida.

Answer 5

Si me equivoco o no (pero lo he probado), algunos eventos (como el controlador_front_init_before) solo se pueden sobrescribir dentro del nodo global.Como resultado, esta anulación afectará tanto el frontend como el backend.

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