Christian's Weblog

Magento automatisch installieren

2012-03-11T22:53:19+01:00

Via Vagrant / Puppet Bei der vorletzten PHPUG Rheinhessen hatte ich bereits eine automatische Magento Installation über Vagrant und Puppet vorgestellt. Damit ist es möglich eine komplette Virtuelle Maschine mit Magento innerhalb von Minuten hochzuziehen. Das ist super, wenn man mal eben ein wirklich leeres System benötigt. Das ganze ist keine Hexerei, denn Magento bietet über die install.php schon die Möglichkeit ohne den Aufruf der Oberfläche eine Installation von der Kommandozeile aus durchzuführen. Wer interesse hat schaut einfach unter https://github.com/cmuench/Magento-Vagrant-Puppet nach und klont sich die Puppet Module inklusive der Vagrant Datei. MageSpawner / Magento-Phing-Installer Letzte Woche veröffentlichte dann Matthias Zeis seinen MageSpawner. Der MageSpawner ist ein Shell Script, welches ebenfalls auf die gleiche Weise Magento installiert. In seinem Blog-Beitrag schlug Matthias vor, dass jemand ebenso sein Shell Script in ein Build-Script umbauen könnte. Da ich dies bereits vor einiger Zeit selbst vor hatte, habe ich dies nun wirklich gemacht. Das Ergebnis kann man unter https://github.com/netz98/Phing-Magento-Installer begutachten. Das Script setzt folgende Dinge vorraus: Linux / MacOS (nicht ausprobiert) wget sed MySQL-Client-Tools tar (zum entpacken) phing Phing kann unter über Pear schnell installiert werden. Der Installert ist in der build.xml Datei komplett enthalten. Um das Script anzuwerfen muss vorher die mitgelieferte build.properties.sample Datei in build.properties umbenannt werden. In der Property-Datei müssen dann die entsprechenden Konfigurationen wie z.B. Pfade des eigenen Systems oder die Datenbank-Zugangsdaten angepasst werden. Danach kann es auch schon losgehen. Das Script hat zwei wichtige Targets. install uninstall Der Aufruf ist dann folgendermaßen: phing -f build.xml install und phing -f build.xml uninstall Das Script arbeitet analog zu Matthias Zeis Script und man gibt auch hier nur den ersten Teil der in der Konfiguration definierten Basis-Domäne an. Wenn der Shop unter foo.magento.local angelegt werden soll, dann muss in der Konfiguration der folgende Eintrag existieren: mage.domain = magento.local Danach startet man die Installation. Bei der Frage nach dem "Shop Name" gibt man dann nur noch "foo" ein. Nach dem Auswählen des Zielsystems wird dann Magent vollautomatisiert installiert. Wie geht es weiter? Folgende Dinge sollen noch in Zukunft in das Script... Sample Data Installation Magento Enterprise Edition Support

Magento Adminbereich besser absichern / 3 einfach Möglichkeiten

2012-03-04T01:50:44+01:00

Admin-URL anpassen Die erste Maßnahme die bei jedem Shop in einer Liveumgebung durchgeführt werden sollte ist das Ändern der Admin-URL. Diese kann bequem in der Systemkonfiguration unter "Admin -> Admin Base URL" angepasst werden. Dort einfach "Use Custom Admin Base URL" auf "Yes" einstellen. Im deraufhin erscheinenden Textfeld kann dann die URL eingetragen werden. Die Base-URL sollte mit "https://" beginnen. Das SSL Zertifikat setze ich bei einem Live-Shop einfach einmal vorraus. Soll der Zugriff nur aus dem eigenen Firmennetzwerk oder von bestimmen IPs aus stattfinden, kann der Zugriff auf den Admin-Login über eine Web-Application-Firewall zusätzlich abgesichert werden. Auch über den Webserver kann der Zugriff auf besstimmte URLs limitiert werden. Berechtigungen limitieren Sind mehrere Benutzer im Adminbereich des Shops unterwegs, sollten die Berechtigungen der Benutzer genaustens konfiguriert werden. Jeder Benutzer sollte nur die Berechtigungen bekommen die auch wirklich benötigt werden. Bei einer Multistore-Umbgebung die mit der Magento Enterprise Edition betrieben wird, können zusätzlich die Berechtigungen auf einzelne Webseiten beschränkt werden. Es sollte tunlichst vermieden werden, dass mehre Benutzer sich einen Login teilen. Es muss genau nachvollziehbar sein, wer/wann/was im Shop angepasst hat. Ist die Enterprise Edition im Einsatz kann hier das Admin-Action-Log herangezogen werden. Das Admin-Action-Log hat zu den wichtigsten Daten eine Art Audit-Trail in dem Änderungen auch nachträglich nachvollzogen werden können. Das Limitieren der Benutzerberechtigungen bringt noch zusätzlich den Vorteil, dass die Benutzer nur noch die Menüpunkte sehen können, die sie auch bedienen dürfen. Das steigert zusätzlich die Useability. Das Einschränken der Berechtigungen gilt auch für Webservices. Diese können von extern auf die Daten des Shops über Core API zugreifen. Sollten Webservices aktiviert werden, dann gilt auch hier. Nur die Berechtigungen erteilen die auch wirklich von z.B. Drittanbieter benötigt werden. Zwei Wege Authentifizierung Eine rechte neue Variante ist die Zwei Wege Authentifizierung. Diese erweitert den Admin-Login um einen weiteren Faktor. Eine Möglichkeit bietet Google über seinen Authentifizierungsdienst. Eine freies Magento Modul wird im Webguys Adventskalender "Türchen 12" beschrieben. http://www.webguys.de/magento/turchen-12-doppelt-halt-besser-magento-backend-login-mit-google-authenticator/ Wer Google nicht traut und lieber auf eine Open Source Variante oder seinen eigenen Authentifizirungsserver setzen möchte kann sich das mir entwickelte N98_Yubikey Modul installieren. Nach der Installation des Moduls muss das Authentifizierungsverfahren aktiviert werden und die ID des Yubikeys einem Benutzer zugewiesen werden. Sobald ein Benutzer sich mit seinem Benutzernamen und Passwort einloggt wird zusätzlich noch nach einem Einmalpasswort gefragt. Der Benutzer drückt dann die Taste auf seinem Yubikey und ein 44 Zeichen langes Passwort wird generiert und an den Shop geschickt. Der Shop prüft gegen den Yubikey Server und leitet im Erfolgsfall dann den Benutzer in den Adminbereich weiter. Das tolle an Yubikeys ist, dass man seinen eigenen Authentifizierungsserver einsetzen kann. Die URLs zu den Servern können in der Magento Konfiguration eingetragen werden. Somit bin ich nicht mehr auf z.B. Google angewiesen. Ein weiterer Vorteil ist der unschlagbare Preis von 25 Dollar pro Yubikey. Wer das Modul ausprobieren möchte, kann es über Magento Connect beziehen: http://www.magentocommerce.com/magento-connect/catalog/product/view/id/11909/s/yubikey-authentification-for-admin-logins-8938/ Die Entwicklungsversion inkl. einer kleinen Anleitung ist auf github zu finden. https://github.com/netz98/N98_Yubikey

Eine bessere Übersicht bei Magento Katalog-Preisregeln

2012-03-03T22:12:22+01:00

Inspiriert von Fabrizios Verbesserungen bei der Webseite/Store/Store-View Darstellung (http://www.fabrizio-branca.de/magento-website-store-groups-store-views.html) kam mir die unübersichtliche Auflistung von Katalog-Preisregeln in den Sinn. Von Fabrizios Entusiasmus angesteckt habe ich mich nun hingesetzt und ein Magento Modul entwickelt. Das Modul tauscht das Grid unter "Promotions -> Catalog Price Rules" aus und entfernt den Pager. Es werden nun alle Regeln auf einer Seite angezeigt. Ebenso habe ich die einfache Auflistung durch eine Gruppierung nach Webseiten geändert. Wird eine Regel auf mehr als einer Webseite verwendet, wird die Regel bei jeder zugeordneten Webseite aufgelistet. Alle Regeln sind nach Priorität sortiert. Ist eine Regeln deaktiviert oder vom Datum her abgelaufen wird der Name der Regel durchgestrichen. Wer das Magento Modul einmal ausprobieren möchte kann es unter https://github.com/netz98/N98_ManageRules herunterladen. Eine passende Modman-Datei ist enthalten. Wenn das Paket von Magento freigeschaltet wurde, kann es natürlich auch über Connect bezogen werden.

DevOp: Puppet zum installieren von jsmin

2012-01-27T11:01:58+01:00

Hier mein puppet jsmin.pp, welches jsmin für die Kommandozeile unter Ubuntu isntalliert:

DevOp: Puppet zum installieren von PHPStorm

2012-01-27T12:21:23+01:00

Puppet zum installieren von PHPStorm: Die Puppet-Klasse installiert PHPStorm in das Verzeichnis /optÜber Parameter kann die Versionsnummer angegeben werden. Die Verwendung von Paramtern wird im puppet Handbuch unter http://docs.puppetlabs.com/learning/modules2.html erklärt. Das Puppet setzt zusätzlich die Default-Java VM Einstellungen von PHPStorm und erhöht den zur Verfügung stehenden Arbeitsspeicher. Zum automatischen erstellen von Menü-Einträgen für die neue PHPStorm Version habe ich das Template "phpstorm.desktop.erb" angelegt. Dort wird immer der aktuelle Pfad aktualisiert. Die Datei habe ich in ein eigenes dev-tools Modul gepackt. Die Struktur sieht wie folgt aus:

Eigene Tools in PHPStorm einbinden / Magento Cache über IDE leeren

2011-12-30T19:46:36+01:00

Ich als Magento Entwickler bin das ständige Cache leeren bereits gewohnt und habe mir für meine Linux Workstation ein Bash-Alias "clear-magento-cache" angelegt. alias clear-magento-cache="rm -Rf var/cache/mage--*" Den Befehl rufe ich dann immer in einem geöffneten Terminal Fenster auf. Wie ihr seht muss ich hierfür aber meine IDE verlassen. Besser wäre es man könnte direkt einen Button in der IDE klicken. Da ich seit einiger Zeit PHPStorm kennenlerne (man entdeckt jeden Tag etwas neues) dachte ich mir ich schaue mal was die IDE hier bereithält. Und ich konnte wieder etwas neues entdecken. In den Einstellungen (Strg + Alt + S) unter "External Tools" kann man sich eigene Tools hinterlegen. Diese lassen sich dann bequem in Gruppen einordnen. Also habe ich hier einen neuen Eintrag mit der Gruppe "Magento" angelegt. Bei "Programm" gibt man nun einfach "rm" an. Unter "Parameters" muss dann das folgende eingetragen werden: -Rf $ProjectFileDir$/var/cache Wir ihr seht kann man bequem das aktuelle Projektverzeichnis über eine Variable erhalten. In PHPStorm nennt sich dies Macro. Es gibt noch eine ganze Menge nützlicher Macros. Über den Button "Insert macro" werden alle Macros aufgelistet. Als Namen vergebe wir nun "Clear Magento Cache". Das war's eigentlich um die eigentliche Funktion zu erhalten. Das fertige Kommando kann nun im Menü unter "Tools -> Magento -> Clear Magento Cache" gestartet werden. Jetzt fehlt noch der Button für die Toolbar. Hier klicken wir nun einfach mit der rechten Maustaste in die Toolbar. Im erscheinenden Kontextmenü wählen wir "Customize Menus and Toolbars...". Im Ordnen "Main Toolbar" makieren wir den letzten Befehl (bei mir "Task toolbar" und klicken rechts den Button "Add After". Nun öffnet sich ein Dialog und wir können unser neues Kommando unter "External Tools" auswählen. Optional kann noch über den Button "Set icon" ein Symbol in der Größe 16x16 Pixel hinterlegt werden. Ich werde diese Funktion auf jeden Fall in der nächsten Zeit noch mehr ausbauen. Eine nette Sache ist auch die in PHPStorm eingebaute Phing unterstützung. Tipp von mir: Einfach das Build-Script über "External Tools" ansteuern und als Parameter den Build-Task übergeben. So lässt sich schnell ein Kommando mit internen PHP Funktionen bauen. Viel Spass beim tüfteln.

Magento 2.0 Entwicklungsversion - Ein erster Einblick

2011-10-15T15:24:47+02:00

Magento hat die Entwicklungsversion des 2.0 Branch in einem öffentlichen SVN Repository auf dem Server bereitgestellt. Um einen Blick auf die Entwicklung zu werfen kann man sich den Code einfach unter der URL http://mage2.magentocommerce.com/svn/public/ auschecken und einmal reinschauen. Ein Blick unter die Haube lohnt sich. Wer Angst hatte, dass sich mit Version 2 alles ändert, der kann an dieser Stelle beruhigt sein. Es ist nicht alles neu Designt worden. Man fühlt sich direkt heimisch und findet seine Klassen. Die Controller, Models und Blocks sind noch an der gleichen Stelle abgelegt. Alles was allderdings mit der Darstellung zu tun hat, findet man nun direkt im Modul. Kein lästiges scrollen mehr in der IDE!!! Design/Templates Die Templates findet man jetzt im Verzeichnis "view" innerhalb des Moduls. Dort gibt es dann die Trennung nach "frontend" und "adminhtml". Javascripts die zum Modul gehören kann man nun in das Verzeichnis "skin" ebenfalls innerhalb des Moduls ablegen. Ein Zugriff kann z.B. über das Template in der .phtml Datei geschehen. Beispiel aus der onepage.phtml: Was auffällt ist, dass die Modul-Kürzel abgeschafft wurden. Jetzt wird immer der volle Modulname verwendet. Dies sorgt für weniger Irritation. Die Layout XML Dateien findet man nun auch im Modul im Verzeichnis "view". Die hier abgelegte Datei ist jetzt das Standard-Layout. Weggefallen ist dafür der sogenannte "Base-Theme" da nun alle mit einer Extension ausgelieferten Dateien direkt im Verzeichnis view liegen. Wer in seinem Theme eine layout.xml Datei überschreiben möchte kann dies aber immer noch tun. Am Theme "iphone" kann man sich das ganze auch gut anschauen. Es wird jetzt einfach ein Verzeichnis mit dem Modulnamen z.B. Mage_Checkout angelegt. Dort kann dann eine eigene layout.xml hinterlegt werden die mit der originalen Datei gemerged wird. Interessant ist in diesm Fall der Artikel im Magento 2 Wiki der das neue angepasste XML mergen erklärt. Wiki: Configuration File MergingNeu ist jetzt auch, dass Themes mit Metainformationen ausgetattet werden können. Dazu dient die Datei "theme.xml" innerhalb des Theme Verzeichnisses. Darin können Mindestanforderungen definiert werden und dem Theme ein richtiger Namen gegeben werden. Das wird wahrscheinlich für den in Magento 2.0 eingeführten Layout-Manager benötigt. Autoloader Das Erstellen von neuen Magento Klassen geschieht auch in Version 2 weiterhin über Factory Methoden die das überschreiben von Models, Blöcken und Helpern ermöglichen. Aber auch hier fallen die "Modulkürzel" weg. Es wird stattdessen der gesamte Klassenname hinterlegt, was die Entwicklung und Suche ebenfalls vereinfacht. Ich könnte mir hier auch gut vorstellen, dass die Autoloader-Performance deutlich gestiegen ist. Apropos Autoloader... Dieser ist jetzt als Klasse Magento_Loader im Verzeichnis "lib" zu finden. Der Loader kann über eine sogenannte Class-Map arbeiten die für die notwendige Performance sorgt. Damit geht man bei Magento ähnliche Wege wie die Jungs von der Zend Framework 2 Entwicklung. Auch dort kann man jetzt mit einen Class-Map Autoloader arbeiten. Eine Erklärung wie sowas funktioniert findet ihr hier: http://zfcookbook.org/post/show/id/post-klassen_laden_im_zf2_mit_dem_classmapautoloader. Setup Scripte Die Setup-Scripte wurden nun ebenfalls voneinander getrennt. Setup-Script für Daten sind jetzt im Verzeichnis "data" des Moduls zu finden. Die SQL-Setup-Scripte sind weiterhin im Verzeichnis "sql" aufzubewahren. Hier hat sich soweit nicht viel geändert. Beispiel SQL Setup: Beispiel Daten Setup: Qualitätssicherung / Testing Ein großes Manko der 1.X Magento Versionen ist die Schwierigkei das System gescheit zu testen ohne einige Core-Klassen anzupassen. So ist es z.B. sehr schwer einzelne Controller zu testen. Ebenso sind die vielen Singletons im System eher hinderlich beim testen da man einiges nicht mehr so ohne weiteres für den nächsten Test-Case aufräumen kann. Auch hier wurde abhilfe geschaffen!!! Das ist für mich die größte Änderung an Magento 2. Das Vertrauen in die Software und die Stabilität sollten durch diese Maßnahme enorm steigen. Die Tests findet man im Verzeichnis "dev" der Installtion. Es ist alles sauber aufgetrennt. Es gibt Integration Tests und Tests die auf Unsauberkeiten, Dupletten, Code-Standard etc. im Code prüfen. Alles was von der Community bemängelt wurde wird nun sauber umgesetzt und auch im SVN bereitgestellt. Ich bin echt begeistert dies nun zu sehen. Im Test-Framework steckt eine Menge Arbeit der Magento Entwickler. Die Tests basieren auf PHPUnit, was den meisten Entwicklern sowieso bekannt ist. Damit sauber getestet werden kann haben die Magento Entwickler einige Listener für PHPUnit angelegt die neue Annotationen im Docblock auswerten können. Damit ist es möglich z.B für den Test-Case die Magento Store-Config zu setzen ohne, dass diese direkt im core_config_data gespeichert wird. Nach der Testausführung ist wieder alles beim alten. Ebenso kann man Test-Fixtures anlegen. Also z.B. ein paar Dummy-Produkte in einem Script zusammenbauen lassen. Diese Fixtures können dann ebenfalls zum Testen über den DocBlock herangezogen werden. Echt eine Super Sache! Beispiel eines Controller Tests der früher fast unmöglich war: Beispiel mit angepasster Store-Config: Zwischenfazit Aus meiner Sicht scheint sich bisher der Einstieg von Ebay echt bei der QS niederzuschlagen. Alles was bisher bemängelt wurde wird angegangen. Da es sich bei der jetzigen Version nur um eine frühe Alpha handelt darf man abwarten was noch passieren wird. Ich freue mich auf jeden Fall auf die neue Magento Version.

404 Fehler nach Login in Magento Adminbereich

2011-09-09T14:04:25+02:00

Wer die URL seines Magento Adminbereichs umgestellt hat sollte den Patch meines Arbeitskollegen Christian Kapitzke in die .htaccess Datei direkt unter der Rewrite Base einfügen. Dann klappt der Login wieder ohne Redirect. Der Fehler tritt nicht mehr in der Magento 1.11 EE oder der 1.6 CE auf. Patch gibt es bei github unter https://gist.github.com/1206043

Erfahrungen mit den Magento Enterprise Edition 1.9 Updates

2010-08-11T07:59:33+02:00

Diese letzten zwei Wochen hatte ich das "Vergnügen" zwei Magento Shops auf die Version 1.9 der Enterprise Edition zu hiefen. Ich möchte hier einige Erfahrungen zusammenfassen. Die neue Version enthält nicht mehr den mit in Version 1.8 eingeführten verschlüsselten Code. Es muss also kein IonCube Encoder Modul mehr auf allen Plattformen installiert werden. Man hat also bei Varien (oder wie es neuerdings heisst Magento Inc.) festgestellt, dass der eingeschlagene Weg schlecht war und die Entwickler und Administratioren einfach nur genervt hatte. Magento kämpft immer wieder um Performance. Bei mittelgroßen Systemen mag die Performance eines einfachen Root-Servers noch ausreichen. Im Enterprise Bereich wo die Begriffe Cluster, Load Balancing, etc. eine Rolle spielen muss man einfach sagen ist Magento zu langsam. Aus diesem Grund führt die neue Version einen Full-Page Cache ein. Allerdings keinen wirklichen, dess es gibt doch noch eine Menge dynamik in der Seite. Der neue Cache teilt die Webseite in dynamische und nicht dynamische Bereiche ein. Über eine cache.xml die in jedem Modul liegen bekommt Magento mitgeteilt wie es einen Block im Layout behandeln soll. Jedem Block kann ein eigenes Cache Model zugewiesen werden da z.B. eine Kategorie anders als ein persönlicher Begrüßungstext zu handhaben ist. Das hört sich auf den ersten Blick gut an. Allerdigns zeitgt die Praxis, dass man nun noch weniger versteht was im System passiert. Der Block selbst könnte ebenfalls noch vom Standard-Block-Caching gecached sein. Eine Dokumentation fehlt wie immer. Man muss sich das Wissen durch durchsichten des Codes aneigenen. Das kann so nicht sein. Ein System mit >1 Mio. Zeilen Code kann nicht jedesmal neu gesichtet werden. Ebenfalls neu ist ein Manager für Kunden- und Kunden-Adress-Attribute. Es lassen sich jetzt analog zum gewohnten Anlegen z.B. bei den Produkten die Attribute direkt über eine GUI anlegen. Das klingt auch wieder schön. Der negative Part (und mal wieder nicht in einer einzigen Zeile erwähnt) ist, dass vorher über die API von Magento angelegte Attribute nicht richtig migriert werden. Die Attribute werden dann zwar im neuen Manager angezeigt. Allerdings kann man nicht speichern. Und was noch besser ist... sind Attribute z.B. im Checkout eingebaut, dann werden diese nicht mehr gespeichert und zwischen Quote / Adressen usw. weitergereich. Es sind nämlich jetzt mindestens 5 Tabellen im Spiel in denen nun Daten fehlen da nicht korrekt migriert wurde. Die Attribute müssen nun einzelnen Formularen mit Elementen und Fieldsets zugewiesen werden (gilt nur für die Enterprise Editon). Die Lösung des Problems ist auf Datenbankebene die Attribute zu bearbeiten und zwar die Spalte "is_used_definied" in der Tabelle "eav_attribute". Dies kann auch gerne über ein Update Script eines eigenen Moduls geschehen. Danach ist das Speichern über den neuen Manager möglich und Magento erstellt die notwendigen Einträge in einen Tabellen. Das Speichern im Checkout funktioniert dann ebenfalls. Umgestellt wurde auch die Speicherung der Bestellungen. Diese sind nun komplett flach. Das heisst, das man sich ebenfalls um die Anlage seiner Attribute die in den Bestellungen hinzugefügt wurden selbst kümmern muss. Das wird wie erwartet nicht von Magento übernommen. Besonder schön ist, die nicht eingehaltene Abwärtskompatibilität. Warum kann man etwas nicht fertigstellen und dann auf den Markt werfen? Oder alte Features wenigstens für einen Release als Deprecated markieren? Immerhin bietet PHP die Möglichkeit mittels des Werfens einer E_DEPRECATED Warnung. Abwärtskompatibel? Das sieht anders aus! Eine Bitte an Magento: Nicht nur neue Features auf den Markt werfen sondern auch mal was dokumentieren. Es kann doch nicht sein, dass man es nicht hinbekommt einen Migration Guide für die Entwickler bereitzustellen in dem die groben API Änderungen enthalten sind.

D-Bus unter PHP nutzen

2010-05-23T14:08:51+02:00

Das unter Linux benutzte D-Bus System wird meistens via Python angesteuert. Man kann D-Bus allerdings auch mit PHP über die PECL Extension "dbus" nutzen. Im folgenden Artikel beschreibe ich kurz wie man mit PHP das Notizprogramm Tomboy ansteuern kann und alle Notizen auslesen kann. DBus für PHP installieren Zum Starten muss zuerst über den PECL Installer das PHP Modul installiert werden. Ich nutze das aktuelle Ubuntu Linux 10.04 mit installiertem PHP. Unter Ubuntu sollte der PECL Installer bereits vorinstalliert sein. Ansonsten kann dieser mit dem PEAR Installert ausgeliefert werden. Auf der Konsolte genügt der Aufruf von "pecl install dbus" damit dieser die C-Quelldateien läd und über phpize das PHP Modul konfiguriert und kompiliert. Wenn alles durchgelaufen ist wurde eine neue Shared Objekt Datei "dbus.so" erstellt. Unter Windows wahrscheinlich "dbus.dll". Diese muss in der php.ini Datei registriert werden. Hier einfach die folgenden Zeilen in die php.ini (am besten im dafür vorgesehenen Bereich in der php.ini) eintragen: extension = dbus.so Da ich php-cli nutze muss keine Webserverkonfiguration neu geladen werden wodurch wir hier mit der Installation von DBus für PHP schon fertig sind. Das Beispielprogramm if (!extension_loaded('dbus')) { die('Extension dbus is not loaded'); } $dbus = new Dbus(Dbus::BUS_SESSION, true); $tomboy = $dbus->createProxy( 'org.gnome.Tomboy', '/org/gnome/Tomboy/RemoteControl', 'org.gnome.Tomboy.RemoteControl' ); $noteTitles = $tomboy->ListAllNotes(); // gibt ein DBusArray Objekt zurück foreach ($noteTitles->getData() as $noteUri) { //echo $noteTitle = $tomboy->GetNoteTitle($noteUri); // Ausgeben des Titels echo $tomboy->GetNoteContents($noteUri); // Ausgeben der kompletten Notitz } Wer selbst ein wenig mit DBus und Tomboy spielen möchte findet eine Beschreibung der Tomboy Api in einem Artikel von Ryan Paul. Der Code ist dort allerdings in Python. Ein Mapping der Methoden ist aber durchaus in kurzer Zeit möglich. Kleiner Tipp zum selber programmieren: Die Desktop-Notfications lassen sich auch sehr leicht in die eigene Anwendung integrieren. Viel Spass beim Ausprobieren.