Willkommen auf der privaten Homepage von Johannes Jarolim, Salzburg, Österreich. Welcome to the private homepage of Johannes Jarolim, Salzburg, Austria, Europe.
Sieben Artikel mit

Schlagwort php

Pimcore: Viewhelper aus Plugin heraus registrieren

Lang gesucht und schließlich gefunden: Wie registriere ich eigene Viewhelper aus einem Pimcore-Plugin heraus.

Der Anwendungsfall

Wir erstellen ein Frontend-User-Authentifizierungs-Plugin, dass Pimcore nach Aktivierung (ganz vereinfacht) folgende Funktionalitäten zur Verfügung stellen soll:

  • Transparenter Schutz von Documents via Zend_Controller_Plugin
  • Ein Controller, mit dessen Hilfe der Login- und Logoutvorgang erfolgt
  • Ein ViewHelper, mit dessen Hilfe eine LoginBox dargestellt werden kann

Die ersten beiden Funktionalitäten stellen kein Problem dar – Doch wie bekomme ich den ViewHelper registriert?

Das Problem

Um eine abgeschlossene Funktionalität des Plugins zu gewährleisten, sollen die View Helper Klassen im Plugin-Verzeichnis liegen. Idealerweise sind die View Helper ohne weiteren Aufwand verwendbar, sobald das Plugin aktiviert wurde. Wir müssen daher mit Code, der ausschließlich im Plugin-Verzeichnis liegt, einen weiteren Helper-Path registrieren. Dazu müssen wir Zugriff auf die Pimcore_View-Instanz erhalten.

Da Pimcore im Grunde genommen aber keine Zend_Application, sondern eine Zend-Komponenten-nutzende Applikation ist, fallen Lösungswege wie zB. Konfigurations-Injection in die Bootstrap-Klasse flach.

Ein Lösungsweg via Controller Action Helper

Als Grundvoraussetzung haben wir das Plugin mit folgender Verzeichnisstruktur:

/plugins/FrontendUserAuth
/plugins/FrontendUserAuth/controllers
/plugins/FrontendUserAuth/install
/plugins/FrontendUserAuth/lib
/plugins/FrontendUserAuth/lib/Plugin.php
...

Die Plugin.php extended die Klassen Pimcore_API_Plugin_Abstract, welche selber ein Ancestor der Klasse Pimcore_API_Abstract ist. Wir finden hier die Methode preDispatch, welche von Pimcore vor dem Start des Display-Loops ausgeführt wird. Wir überschreiben die Methode in unserem Plugin und registrieren unseren Zend_Controller_Action_Helper, der den neuen ViewHelper-Pfad registrieren soll:

class FrontendUser_Plugin extends Pimcore_API_Plugin_Abstract implements Pimcore_API_Plugin_Interface {
  ...
  public function preDispatch() {
    Zend_Controller_Action_HelperBroker::addHelper(new FrontendUser_Controller_Action_Helper_ViewHelperInjector());
  }
  ..
}

Die neue Klasse erstellen wir hier:

/plugins/FrontendUserAuth/lib/FrontendUserAuth/Controller/Action/Helper/ViewHelperInjector.php

Zur Ausführungszeit des Controller Action Helpers bekommen wir dann mittels getActionController() den gerade ausgeführten Action Controller in die Hand: Voila, wir können global einen ViewHelperPfad registrieren, der in unserem Plugin-Directory Tree liegt:

<?php

  class FrontendUserAuth_Controller_Action_Helper_ViewHelperInjector extends Zend_Controller_Action_Helper_Abstract {

    public function preDispatch() {

      $controller = $this->getActionController();
      $view = $controller->view; /* @var $view Pimcore_View */
      $view->addHelperPath(PIMCORE_PLUGINS_PATH . '/FrontendUserAuth/lib/FrontendUserAuth/View/Helper', 'FrontendUserAuth_View_Helper_');

    }

  }

View Helper

Danach erstellen wir einen kleinen View Helper

/plugins/FrontendUserAuth/lib/FrontendUserAuth/View/Helper/LoginBox.php

welcher hier im Beispiel ganz einfach ein Loginform ausgibt:

<?php

  class FrontendUserAuth_View_Helper_LoginBox extends Zend_View_Helper_Abstract {

    public function loginBox() {
      return new FrontendUserAuth_Form_LoginForm();
    }

  }

Schlußendlich benutzen wir den ViewHelper in einem View Script der Website und freuen uns über eine neue, sauber abgekapselte, Funktionalität:

<div class="login-area">
  <?php echo $this->loginBox(); ?>
</div>

Einsatz des Zend_Paginators in sauber abstrahierten Modell-Umgebungen

Saubere Paginierung von Daten ist ein Thema, über das man als Webentwickler öfter stolpert. Als eifriger Nutzer der Komponenten des Zend Frameworks nutze ich natürlich gerne die Zend_Paginator Komponente. Diese separiert mittels Adaptern die Paginierung von der Datenquelle und stellt für mich durchaus eine der besten Implementierungen in diesem Themengebiet dar. Mehr lesen …

WordPress – Inline Mediaupload

As side-product to my commercial or open source work, i often create prototypes. The WordPress plugin Inline Mediaupload is the elaborated result of a feasability study for the next generation of my plugin Yet-Another-Photoblog (YAPB). In this study i verified that the new WordPress 3.3 Media Upload Feature may be directly integrated into the normal post/page edit form.

Mehr lesen …

Pimcore – Gutes CMS mit verbesserungsbedürftiger Positionierung

Im Rahmen meiner Arbeit ist mir das CMS Pimcore unter die Finger gekommen: Dieses Open Source CMS wurde durch eine für Salzburger Verhältnisse großen Agentur namens Elements entwickelt.

Mehr lesen …

Your own photo mosaic page with WordPress and Yet Another Photoblog

You’re using YAPB, you want to create or use your own theme and now you’re stuck on how to create a mosaic page featuring all your photos? Thanks god – Here’s a post describing exactly that topic ;-) Mehr lesen …

WordPress und Übersetzungen

Wie wird WordPress bzw. Plugins oder Themes mehrsprachig? Mich hat das grundsätzlich interessiert, da ich mir derzeit anschaue, ob ich Yapb (Yet Another PhotoBlog) als WordPress Plugin umsetze. Grund für meine Neugier:

Was muß ich schon Anfangs wissen, um das Plugin am Ende auch wirklich ohne große Arbeit Übersetzen zu können (Ich brauche keinen Abschließenden Aha-da-hab-ich-an-der-Realität-vorbeiprogrammiert Effekt).

Naja – WordPress benutzt das freie GNU-Gettext (bzw. hier ein Link zur Gettext-Seite selber), welches grob folgende Arbeitsschritte vorraussetzt:

  1. Alle zu übersetzenden Texte im Quellcode durch Funktionsaufrufe ersetzen
    zb. print(‘This is english’); durch print(__(‘This is english’, ‘pluginname’)); wobei beim Entwickeln wirklich Englisch verwendet werden sollte.
  2. Ein Tool wie zB. poEdit drüberlaufen lassen, alle diese Textschnipsel herausholen lassen und in eine .po-Datei speichern. Diese agiert als Resourcencontainer für nicht übersetzte Textschnipsel.
  3. Diese jetzt Schritt für Schritt in die gewünschte Sprache übersetzen
  4. Das Ergebnis zu einer .mo-Datei (zB. pluginname-de_DE.mo) kompilieren und abspeichern

WordPress selber erlaubt dann die Einbindung dieser Textdomain und ersetzt dann alle so vorbereiteten Textschnipsel durch die deutschen Übersetzungen, wenn der User das so in WordPress eingestellt hat.

Sollte der Benutzer dann eine noch nicht übersetzte Sprache verwenden, wird standardmäßig der Englische Text angezeigt, der ja immer noch im Quelltext vorliegt.

Fazit: Selbst wenn dies wieder mal der falsche Ansatz ist und ich Yapb als eigenständige WebApplikation entwickle, hab ich wieder was dazugelernt: Ein schöner Ansatz für Übersetzungen. Die Übersetzung geht gut von der Hand, wenn man statt den Commandline-Tools der GNU Foundation mit poEdit arbeitet. Ich denke, dass jedes seriöse Übersetzungsbüro .mo-Dateien akzeptiert.

More Infos: Falls sich jemand für das Thema interessiert und schnell in die Materie kommen möchte, kann ich diese beiden Artikel empfehlen:

Zusammen ergeben die 3 Artikel ein schönes Bild – Nach ein bisschen lesen und nachmachen sollte jeder in der Lage sein, eigene Übersetzungsdateien zu erstellen und zu benutzen.

Der Große Compiling-Day

Finally: Klemens und ich haben den Server in einer epochalen Nacht und Nebel – Compiling Aktion auf den neuesten Stand gebracht:

  • PHP 4.4.1
  • GDLib 2.0.33
  • Freetype2

Dank dem Freetype-Plugin funktioniert jetzt auch die Captcha-Abfrage bei den Kommentaren im Photoblog, was ich persönlich ziemlich lässig finde. Zusätzlich habe ich einiges über Linux-Compiling, dessen Tücken und natürlich über den famosen safe_mode von PHP gelernt. Mein Fazit über den safe_mode ist hier sehr schön zusammengefasst: Artikel zum Safemode auf support.webedition.de