Magento Request – Frontend oder Backend?

Question

Wie kann ich feststellen, ob es sich bei der aktuellen Anfrage um eine Backend- oder Frontend-Seite handelt?Diese Prüfung wird in einem Beobachter durchgeführt, sodass ich Zugriff auf das Anforderungsobjekt habe, wenn das hilft.

Ich habe darüber nachgedacht, es zu überprüfen Mage::getSingleton('admin/session')->getUser() aber ich glaube nicht, dass das eine sehr zuverlässige Methode ist.Ich hoffe auf eine bessere Lösung.

Answer 1

Dies ist eines dieser Bereiche, in denen es keine gute Antwort gibt. Magento selbst bietet keine explizite Methode / API für diese Informationen, also müssen Sie mit jeder Lösung, um die Umwelt zu untersuchen und die Dinge zu prüfen.

Ich verwende

generasacodicetagpre.

eine Weile, aber es stellt sich heraus, dass es bestimmte Administratorseiten gibt (der Magento Connect Package Manager), wo dies nicht stimmt. Aus irgendeinem Grund setzt diese Seite explizit die Speicher-ID als 1, wodurch der generationspflichtige Code als FALSE zurückgibt.

generasacodicetagpre.

Es können andere Seiten mit diesem Verhalten auftreten,

Eine andere gute Wette besteht darin, die Eigenschaft "Bereich" des Designpakets zu überprüfen.

Dies scheint weniger wahrscheinlich für eine Seite, die im Administrator ist, außerdem überschrieben, da der Bereich den Pfad in die Admin-Bereiche-Designvorlagen und Layout-XML-Dateien beeinflusst.

Unabhängig von dem, was Sie sich aus der Umgebung entscheiden, erstellen Sie ein neues Magento-Modul und fügen Sie ihm eine Helferklasse hinzu

generasacodicetagpre.

und dann wann immer Sie überprüfen müssen, wenn Sie sich im Administrator befinden, verwenden Sie diesen Helfer

generasacodicetagpre.

Auf diese Weise, wenn / wenn Sie Löcher in Ihrer Admin-Überprüfungslogik entdecken, können Sie alles an einem zentralen Ort korrigieren.

Answer 2

Wenn Sie einen Beobachter verwenden können, können Sie es in den Ereignisbereich 'adminhtml' einschränken.

generasacodicetagpre.

Answer 3

Schauen Sie sich die Methoden innerhalb des generellen generationspabeditagcode an, die Sie verwenden möchten:

generasacodicetagpre.

in Verbindung mit

generasacodicetagpre.

, um als Fallback zu fungieren, in dem die Speicher-ID nicht so eingestellt ist, wie Sie erwarten (Magento Connect usw.)

Answer 4

Mir gefällt die Antwort von Beep Logic – sie macht im Kontext von Beobachtern Sinn.Mir gefällt auch Alans Argument, dass es keine Möglichkeit gibt, den Admin-Status in allen Kontexten zu kennen, was davon abhängt, dass „der Admin“ ein Status ist, der eingegeben wird, nachdem die App und der Front-Controller initialisiert wurden.

Der Admin-Status von Magento wird effektiv durch die Steuerungsverteilung an einen Admin-Action-Controller erstellt;sehen Mage_Adminhtml_Controller_Action::preDispatch().Dies ist die Methode, die das auslöst adminhtml_controller_action_predispatch_start Ereignis, das von verbraucht wird Mage_Adminhtml_Model_Observer::bindStore(), wo der Admin-Store zunächst „eingestellt“ wird.Tatsächlich „funktionieren“ die Beobachterkonfigurationsbereiche (adminhtml vs. frontend) aufgrund der Hauptaktionscontrollerklasse – siehe Mage_Core_Controller_Varien_Action::preDispatch(), konkret Mage::app()->loadArea($this->getLayout()->getArea()); - Beachten Sie nur, dass die Bereichsinformationen des Layoutobjekts im Adminhtml-Predispatch festgelegt sind.

Unabhängig davon, wie man es aufteilt, hängt das Administratorverhalten, auf das wir uns in so vielen Kontexten verlassen – selbst bei so hochrangigen Systemen wie dem Ereignisbeobachtersystem – von der Befehlskontrollstruktur ab.

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

In Ihrer Beobachterdefinition:

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:Verwenden Sie einen Beobachter, sogar dasselbe Beobachtermodell, übergeben Sie jedoch den Kontext, indem Sie eine andere Aufrufmethode angeben.

HTH.

bearbeiten:Beispielcode hinzugefügt, der die Konfiguration der Beep-Logik als Ausgangspunkt verwendet

Answer 5

Ob ich falsch bin oder nicht (aber ich habe es getestet), einige Ereignisse (wie controller_front_init_beforfor) können nur im globalen Knoten überschrieben werden.Infolgedessen wirkt sich diese Überschreibung sowohl das Frontend als auch das Backend aus.

Kommen Sie dann ALANs und Benmarks Lösung, um die Rettung anzugeben, um anzugeben, ob Sie den Beobachter auf Frontend nur anwenden oder nur Backend anwenden möchten.