Das PostNuke Kompendium: Internet-, Intranet- und Extranet-Portale erstellen und verwalten GERMAN

Xpert.press

Die Reihe Xpert.press vermittelt Professionals in den Bereichen Softwareentwicklung, Internettechnologie und IT-Management aktuell und kompetent relevantes Fachwissen über Technologien und Produkte zur Entwicklung und Anwendung moderner Informationstechnologien.

Markus Gossmer · Michael Schumacher · Andreas Schauperl · Michael Nagy

Das PostNuke Kompendium Internet-, Intranet- und Extranet-Portale erstellen und verwalten Mit 24 Abbildungen

123

Markus Gossmer Hintere Gasse 54 70794 Filderstadt Michael Schumacher Wilhelm-Leuschner-Str. 16 73732 Esslingen Andreas Schauperl Oderstr. 1-1 71083 Herrenberg Michael Nagy Rastatter Weg 1 71686 Remseck

Bibliografische Information der Deutschen Bibliothek Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.ddb.de abrufbar.

ISSN 1439-5428 ISBN-10 3-540-21942-0 Springer Berlin Heidelberg New York ISBN-13 978-3-540-21942-0 Springer Berlin Heidelberg New York Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes. Springer ist ein Unternehmen von Springer Science+Business Media springer.de © Springer-Verlag Berlin Heidelberg 2005 Printed in The Netherlands Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutzgesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Text und Abbildungen wurden mit größter Sorgfalt erarbeitet. Verlag und Autor können jedoch für eventuell verbliebene fehlerhafte Angaben und deren Folgen weder eine juristische Verantwortung noch irgendeine Haftung übernehmen. Satz: Druckfertige Daten der Autoren Herstellung: LE-TeX Jelonek, Schmidt & Vöckler GbR, Leipzig Umschlaggestaltung: KünkelLopka Werbeagentur, Heidelberg Gedruckt auf säurefreiem Papier 33/3142/YL - 5 4 3 2 1 0

Vorwort

Content Management Systeme zur optimierten Verwaltung großer Sites erfreuen sich wachsender Beliebtheit, nicht zuletzt durch das immer größer werdende Angebot an freien CM-Systemen. PostNuke ist – auch dank einer sehr aktiven deutschen Community – in diesem Segment bereits eine gesetzte Größe. Dieses Buch setzt sich in knapper und präziser Darstellung mit allen Aspekten dieses leistungsfähigen Portal-Systems auseinander, von der Installation über Nutzung des Berechtigungssystems bis hin zur Programmierung eigener Module. Es ist ein Buch für alle, die


irgendwann an der selbst programmierten Homepage verzweifelt sind und schon lange mit einem CMS und all seinen dynamischen Features liebäugeln,




ihren Internet- oder Intranet-Auftritt direkt auf einem weit verbreiteten Open Source CMS aufsetzen wollen und




sich mit PostNuke beschäftigt haben und mehr über das System wissen wollen.

Das Buch gliedert sich in drei große Teile: Praxis, Konzepte und Programmierung. Praxis: Im ersten, grundlagenorientierten Teil bis einschließlich Kapitel 4 vermitteln wir einen Eindruck von der Leistungsfähigkeit von PostNuke und helfen Ihnen bei der Einrichtung einer ServerUmgebung auf Basis eines Apache Webservers, PHP und einer MySQL-Datenbank. Anschließend werden Sie durch den PostNukeInstallationsprozess geführt. In einer Art Crash-Kurs werden Sie dann mit allen Basis-Funktionen des CMS vertraut gemacht. Neben

Vorwort






V

der ersten Content-Pflege mit dem integrierten WYSIWYG-Editor legen Sie neue Benutzer und spezielle Gruppen an, vergeben Berechtigungen, installieren weitere Blöcke und Module im System usw. Nach diesen Kapiteln sind Sie bereits in der Lage, PostNuke fundiert zu verwenden. Konzepte: Der zweite große Teil des Buches – bis Kapitel 17 – besitzt mehr den Charakter eines Nachschlagewerkes. So werden Sie tiefer in die Feinheiten des umfangreichen Berechtigungssystems eingeführt. Die mitgelieferten Blöcke und Module werden ebenso detailliert beschrieben wie die Erstellung eigener Xanthia-Themes (was technisches Verständnis im Bereich HTML oder CSS voraussetzt). Nach den Verzeichnisstrukturen, den PostNuke-DatenbankTabellen und der Einrichtung von Multisites leiten wir über zu Rettungs-Tools wie PSAK und zur Sicherung und Wiederherstellung von PostNuke-Daten und Dateien. Mit pnmini bauen Sie ein hochoptimiertes Mini-PostNuke, anschließend wird Performance & Tuning diskutiert. Nach der Anleitung für den direkten Zugriff auf die aktuellsten PostNuke-Sourcecode-Dateien (CVS), die Beschreibung der Sprachcodes und den Bezug von Sprachpaketen wird dieser Teil mit gesammelten Tipps & Tricks zu PostNuke abgeschlossen. Programmierung: Die letzten Kapitel richten sich dann an alle PHP-Programmierer. Neben der Erläuterung, wie man eigene Module entwickelt, geben wir Ihnen eine umfangreiche deutsche Beschreibung der PostNuke-API und der wichtigsten Smarty-Tags an die Hand. Kenntnisse in PHP und SQL werden vorausgesetzt. Eine kurze Abhandlung der Unterschiede zwischen 0.750 und 0.760, ein Glossar und eine Link-Liste schließen das Kompendium ab. Wir empfehlen das sequentielle Durcharbeiten des Buches, da die späteren Kapitel auf den Inhalten der früheren Kapitel aufbauen. Wir setzen PostNuke bereits seit Jahren in verschiedenen Projekten im kommerziellen Umfeld ein, egal ob als einfaches Basis-CMS, im komplexen Extranet-Verbund, in der Programmierung oder integrativ mit anderen Software-Systemen. Dort hat es seine Erweiterbarkeit, Flexibilität und Stabilität eindrucksvoll unter Beweis stellen können.

VI






Vorwort

Die Erstellung des Kompendiums wäre in dieser Form niemals ohne die Hilfe Anderer möglich gewesen. Wir danken daher folgenden Personen für ihre konstruktive Kritik, ihre Vorschläge und Mithilfe an diesem Buch:


Bianca Bohne




Gudrun Rau




Wolfgang Staiger




Naim Steimer




Roland Mack




Robin Richter

Ihr Autoren-Team: Markus Gossmer, Michael Nagy, Andreas Schauperl und Michael Schumacher

Stuttgart, im März 2005

Vorwort






VII

Inhaltsverzeichnis

Teil 1: Praxis 1

Was ist PostNuke? ....................................................................1 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8

2

Was ist ein CMS? ...............................................................1 Beispielhaftes Anforderungsprofil .....................................2 Die PostNuke-Historie........................................................2 Leistungsfähigkeit des PostNuke-CMS .............................3 Produktdetails und Voraussetzungen .................................5 Unternehmenskriterien .......................................................6 Zusammenfassung ..............................................................8 Ausblick ..............................................................................8

Installation einer Webserver-Umgebung...............................9 2.1 Aufsetzen einer Server-Umgebung mit XAMPP ..............9 2.2 Zusammenfassung ............................................................11 2.3 Ausblick ............................................................................12

3

Die PostNuke-Installation ......................................................13 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9

4

Download von PostNuke..................................................13 Installation mit install.php ................................................13 Alternative: manuelle Installation ....................................16 Installation absichern ........................................................16 Die config.php...................................................................17 Deutsches Sprachpaket installieren ..................................18 Grundkonfiguration ..........................................................19 Zusammenfassung ............................................................23 Ausblick ............................................................................23

Umgang mit PostNuke............................................................25 4.1 Die Startseite und ihre Funktionen...................................25

Inhaltsverzeichnis






IX

4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14 4.15

Anmelden am System (Login)....................................... 27 Benutzerspezifische Konfiguration ............................... 27 Benutzer-Verwaltung..................................................... 28 Gruppen.......................................................................... 30 Blöcke und Module........................................................ 31 WYSIWYG HTML-Editor „Type Tool“ ...................... 38 Content-Pflege: Den ersten Artikel erstellen................. 39 Einrichtung einer echten Autoren-Gruppe .................... 43 Topics ............................................................................. 45 Kategorien ...................................................................... 46 Wiki................................................................................ 47 Hooks ............................................................................. 48 Zusammenfassung ......................................................... 50 Ausblick ......................................................................... 50

Teil 2: Konzepte 5

Sicherheit................................................................................. 51 5.1 5.2 5.3 5.4 5.5 5.6 5.7

PHP................................................................................... 51 Apache.............................................................................. 53 SSL ................................................................................... 54 Berechtigungen und Zugriffsrechte in PostNuke............ 55 Allgemeine PostNuke Sicherheitstipps ........................... 61 Zusammenfassung............................................................ 62 Ausblick ........................................................................... 62

6

Blöcke ...................................................................................... 63

7

Module..................................................................................... 79

8

Xanthia-Themes ................................................................... 135 8.1 8.2 8.3 8.4 8.5 8.6 8.7

9

Einführung...................................................................... 135 Themes administrieren................................................... 138 Xanthia konfigurieren .................................................... 141 Theme erstellen .............................................................. 144 pnRender ........................................................................ 155 Zusammenfassung.......................................................... 156 Ausblick ......................................................................... 156

Die PostNuke-Verzeichnisstruktur .................................... 157 9.1 Das PostNuke-Verzeichnis ............................................ 157

X






Inhaltsverzeichnis

9.2 Beispiel: language, modules und themes .......................160 9.3 Zusammenfassung ..........................................................162 9.4 Ausblick ..........................................................................162 10

Datenbank-Tabellen einer PostNuke-Installation ............163

11

Multisites................................................................................167 11.1 11.2 11.3 11.4 11.5

12

Troubleshooting, Backup und Recovery............................177 12.1 12.2 12.3 12.4 12.5

13

Das PostNuke Swiss Army Knife (PSAK) ..................177 Backup ..........................................................................178 Recovery .......................................................................180 Zusammenfassung ........................................................180 Ausblick ........................................................................180

pnmini.....................................................................................181 13.1 13.2 13.3 13.4 13.5 13.6 13.7 13.8 13.9 13.10

14

Einrichtung des Webservers.........................................168 Einrichtung unterschiedlicher Themes.........................170 Einrichtung unterschiedlichen Contents ......................172 Zusammenfassung ........................................................174 Ausblick ........................................................................175

Vorbereitung ...............................................................181 Notwendige Module ...................................................182 Verzeichnisse löschen.................................................182 Notwendige Blöcke ....................................................183 Blöcke löschen............................................................183 Dateien löschen...........................................................184 Notwendige Datenbank-Tabellen...............................185 Ergebnis ......................................................................186 Zusammenfassung ......................................................186 Ausblick ......................................................................186

Performance & Tuning ........................................................187 14.1 14.2 14.3 14.4 14.5 14.6 14.7

Tools zur Performance-Messung .................................187 Anzahl Seitenabrufe in Abhängigkeit von Bandbreite 188 Hardware.......................................................................190 Software ........................................................................191 PostNuke-Bordmittel nutzen ........................................194 Zusammenfassung ........................................................194 Ausblick ........................................................................194

Inhaltsverzeichnis






XI

15

Das PostNuke-CVS .............................................................. 195 15.1 15.2 15.3 15.4 15.5

16

CVS-Module ................................................................ 195 Die Zugangsdaten ........................................................ 196 Bauen einer PostNuke-Umgebung aus dem CVS....... 197 Zusammenfassung ....................................................... 200 Ausblick ....................................................................... 200

Sprachpakete und Sprachentabelle ................................... 201 16.1 Sprachpakete beziehen................................................. 201 16.2 Sprachen, ihre Kürzel und Fundort ............................. 202

17

Tipps & Tricks zu PostNuke............................................... 205 17.1 17.2 17.3 17.4 17.5

Allgemein..................................................................... 205 Benutzer / Sessions ...................................................... 207 Blöcke und Module...................................................... 209 Themes ......................................................................... 210 Ausblick ....................................................................... 212

Teil 3: Programmierung 18

Die PostNuke-Programmierung......................................... 213 18.1 18.2 18.3 18.4 18.5 18.6

Programmierung von autarken Blöcken...................... 213 Sicherheit: die 12 goldenen Regeln der Entwicklung. 217 Grundlagen zur Modulentwicklung............................. 218 Entwicklung des Moduls „Rooms“ ............................. 224 Zusammenfassung ....................................................... 257 Ausblick ....................................................................... 258

19

Smarty ................................................................................... 259

20

Die PostNuke-API ................................................................ 265

21

PostNuke 0.760 ..................................................................... 335

22

Begriffe .................................................................................. 337

23

Links ...................................................................................... 349

Index............................................................................................... 351

XII






Inhaltsverzeichnis

1 Was ist PostNuke?

In diesem Kapitel lernen Sie, was das weit verbreitete Open Source Content Management System (CMS) „PostNuke“ in der Version „0.750 Gold“ leistet. Die in Details modifizierte Version „0.760“ ist angekündigt bzw. zur Drucklegung des Buches schon erschienen. Die Unterschiede zwischen beiden Versionen werden im Anhang erläutert.

1.1 Was ist ein CMS? Content Management Systeme (CMS) erstellen Internet-Seiten auf Basis eines vorgefertigten Layouts (Templates), in welches Inhalte (Content) aus einer Datenbank dynamisch eingefügt werden. Das Look and Feel bleibt so auf allen Seiten der Internet-Präsenz einheitlich. Ein CM-System kann natürlich auch im Intranet oder zur Realisierung von Extranets eingesetzt werden. Bei Content kann es sich um Artikel und jegliche Art von Dateien wie Dokumente und Bilder handeln. Redakteure und Autoren können tagesaktuell und weltweit diese Inhalte bearbeiten, ohne sich mit HTML-Details oder Programmierung befassen zu müssen. Dazu bieten CM-Systeme wie PostNuke grafische Editoren oder andere vergleichbare Tools. Darüber hinaus lässt sich ein CM-System wie PostNuke an beinahe jede Anforderung an Darstellung oder Funktionalität anpassen.

1.1 Was ist ein CMS?






1

1.2 Beispielhaftes Anforderungsprofil Das folgende Anforderungsprofil einer fiktiven Firma wird in diesem Buch als Veranschaulichungsbeispiel zur Umsetzung verschiedener Funktionalitäten herangezogen. Stellen Sie sich vor, Sie haben die Aufgabe erhalten, den InternetAuftritt ihrer Firma mit einem kostenlosen CMS zu gestalten. Das öffentliche Portal soll vor allem durch die MarketingAbteilung gepflegt werden können – ohne HTML- oder Programmierkenntnisse. Das Layout des Portals selbst darf durch die Mitarbeiter nicht geändert werden – oder nur im Rahmen enger Vorgaben. Eine Kontrollinstanz soll alle Texte vor ihrem Erscheinen prüfen und nach erfolgreicher Prüfung freigeben. Ihr Chef wünscht sich zudem einen Intranet-Auftritt, der an die Internet-Präsenz optisch angelehnt ist, jedoch mehr Funktionalitäten bietet. Zu einem späteren Zeitpunkt soll es möglich sein, auf Kunden und Partner zugeschnittene Bereiche – so genannte Extranets – anzubieten, in denen spezifische Inhalte hinterlegt werden können. Nur die Mitarbeiter der Partnerfirmen dürfen Zugang zu diesen Seiten bekommen. Das Layout orientiert sich diesmal aber an der Corporate Identity des Partners. Eine weitere Forderung: der Internet-, Intranet- und ExtranetAuftritt soll mit einem einzigen über das Internet erreichbaren Server umgesetzt werden, möglichst ohne Anschaffungskosten für die CMS-Software – auf alle Fälle aber erweiterbar und damit zukunftssicher. All diesen Anforderungen wird das kostenlose Content Management System PostNuke gerecht.

1.3 Die PostNuke-Historie Hervorgegangen ist PostNuke aus dem von F. Burzi entwickelten CMS PHPNuke. Dabei setzt sich der Name PostNuke aus post[lat.] (nach) und Nuke (Spitzname von F. Burzi) zusammen. Mittlerweile hat sich die Entwicklung von PostNuke und PHPNuke entkoppelt. Zusätzlich gibt es noch einige Nuke-Derivate (oft Forks genannt), die auf PostNuke aufsetzen. Dabei sind beispielsweise die CMS Xa-

2






1 Was ist PostNuke?

raya und eNvolution aus dem Streit über die Art und Form der Einführung einer neuen Layout-Engine in PostNuke entstanden. Die PostNuke-Historie ist vielschichtig und lang und begann mit der Version 0.51. Die Versionen 0.720 bis 0.726 bilden bereits die Basis für eine Vielzahl an Präsenzen. Das Buch beschreibt die Version 0.750 Gold (mit Ausblick auf 0.760 und teilweise 0.8). PHPSplash |- Thatware |- PHPNuke |- ... |- PostNuke |- Envolution | |- maxdev | |- MDPro |- Nuke on Jboss |- Xaraya |- ... Von PHPNuke leiten sich noch andere Nuke-Systeme wie CpgNuke, MyPHP-Nuke (und davon OPN), NSN Nuke, OpenPHPNuke, tis, diverse VKPs (vorkonfigurierte Pakete), XOOPS und 2fvkp ab. PostNuke ist extrem beliebt. Eine Suche in Google nach dem Begriff PostNuke liefert bereits über vier Millionen Treffer, davon knapp 600.000 aus deutschen Landen.

1.4 Leistungsfähigkeit des PostNuke-CMS PostNuke ist im Quelltext verfügbar und darf frei verwendet werden. Das System selbst ist hochmodular und kann durch das Hinzufügen von Modulen um jede erdenkliche Funktionalität erweitert werden. Viele Module sind dabei ebenfalls kostenlos erhältlich. Sollte doch einmal eine Funktionalität fehlen, bietet es Programmierern durch die PostNuke-API die Möglichkeit, eigene Blöcke (einfache Oberflächen-Bausteine ohne umfangreiche oder tiefere Funktionalität) und Module zu entwickeln. Da der Programmcode öffentlich zugänglich ist, kann auch

1.4 Leistungsfähigkeit des PostNuke-CMS

PostNuke ist Open Source Software und unterliegt der GPL-Lizenz. Eine deutsche Übersetzung der GPL findet sich auf www.gnu.de/ gpl-ger.html.






3

der PostNuke-Kernel, das Herzstück von PostNuke, an individuelle Bedürfnisse angepasst werden. Für PostNuke ist der Betrieb eines Webservers Voraussetzung, beispielsweise eines Apache oder Internet Information Server (IIS). Siehe dazu das Kapitel Sicherheit

Neben der einfachen Artikel-Verwaltung und der davon vollständig losgelösten Layoutgestaltung legen die PostNuke-Entwickler einen weiteren Schwerpunkt auf die Benutzerverwaltung. Durch ein ausgeklügeltes Rechtesystem lassen sich komplexe ZugriffsSzenarien realisieren. So lassen sich Kontrollinstanzen für ContentFreigabe umsetzen; Autoren verfassen Texte, die durch Redakteure freigegeben werden können; Extranet-Benutzer sehen andere Inhalte und haben andere Funktionen als Intranet-Benutzer usw.

Siehe dazu das Kapitel XanthiaThemes

Das Layout einer PostNuke-Seite wird über ein so genanntes “Theme” realisiert. Dieses kann man sich als eine Art Maske vorstellen, die das Aussehen in Grundzügen vorgibt, und in die der jeweilige Content eingefügt wird.

Siehe dazu das Kapitel Sprachpakete und Sprachentabelle

PostNuke ist sprachenunabhängig und kann um jede beliebige Sprache mittels Sprachpaketen erweitert werden. Die Sprachpakete bestehen aus einer Reihe von Textdateien, welche die jeweiligen Übersetzungen der PostNuke-Oberfläche beinhalten. Sprachpakete können damit von Ihnen selbst erstellt und bearbeitet werden.

Siehe dazu das Kapitel Module

Module realisieren Funktionen wie zum Beispiel eine umfangreiche Download-Bibliothek, automatische Konvertierung der eigenen Seite zur Darstellung auf PDAs und Mobiles, automatische Verlinkung von Inhalten usw. PostNuke verfügt darüber hinaus über eine systemweite, datenbankbasierte Such-Funktion. Die Konfigurationseinstellungen von PostNuke sowie dessen Content werden bis auf wenige Ausnahmen wie Dateien in einer SQL-Datenbank abgelegt. Damit stehen dem Administrator sämtliche Möglichkeiten zur weiteren Content-Verarbeitung sowie Anbindung von PostNuke über SQL und ODBC an Fremdsysteme zur Verfügung. In der Version „0.750 Gold“ ist PostNuke so konzipiert, dass es nur die frei verfügbare MySQL-Datenbank verwendet. PostNukeVersionen ab 0.8 werden weitere Datenbankserver wie beispielsweise Oracle oder MS SQL unterstützen.

4






1 Was ist PostNuke?

1.5 Produktdetails und Voraussetzungen Die nachfolgende Übersicht ist in ihrer Struktur an die gängigen Ausschreibungen und an die Auflistung der Produktinformationen unter http://www.contentmanager.de angelehnt.


Unterstützte Betriebssysteme: plattformunabhängig; jedes, auf dem ein PHP-fähiger Webserver ausgeführt werden kann. Windows ab Version NT 4, Linux, UNIX oder FreeBSD empfohlen.




Unterstützte Webserver: jeder PHP-fähige Webserver, z.B. Abyss, Apache, IIS, Netscape, OmniHTTPd, usw.




Unterstützte Datenbanken: in PostNuke Version 0.750 Gold nur MySQL; in PostNuke ab Version 0.8 zusätzlich PostgreSQL, Oracle und MS SQL.




Unterstützte Scriptsprachen: PHP > Version 4.1




Weitere Software für Betrieb notwendig: Nein




Hardware-Voraussetzungen: 150 MB freier Festplattenspeicher, davon 10 MB für PostNuke, Prozessor ab 266 MHz, 512 MB Hauptspeicher.




Performance: Ist Performance gefordert, sollte man besonderen Wert auf schnelle Festplatten und viel Hauptspeicher legen – hauptsächlich ein Tribut an den relationalen Datenbank-Server.




Lizenz/Kosten: GPL/kostenlos




Zielgruppe: Mittelstand (KMU); Vereine; Privatanwender




Existiert eine Media-Datenbank: Ja, über zusätzliche DrittModule wie z.B. „Photoshare“.




Verwendung von Templates: PostNuke bietet mit dem Xanthia-Modul eine auf Smarty aufsetzende Templating-Engine (siehe Kapitel Xanthia-Themes) ohne proprietäre Skriptsprache.




Scriptsprachen in Templates einsetzbar: Ja, über Smarty oder PHP.




Content-Revisionssicherheit: Über zusätzliche Module wie z.B. „Pagesetter“ realisierbar.




Content-Pflege: Direkt im Browser im WYSIWYG-Editor oder über Schnittstellen wie XMLRPC.




Einbindung externer Content, Content Syndication: Zum Beispiel über RSS-Feeds.




Existiert eine API: Ja (pnAPI)

1.5 Produktdetails und Voraussetzungen

Anforderungen laut Ausschreibungen






5




Erweiterbarkeit: Über Module und Blöcke, meist kostenlos erhältlich.




Skalierbarkeit: Nur beschränkt durch die Server-Performance.




Caching: Caching-Verhalten ist über das Xanthia-Modul frei wählbar. ADODB-Caching in Vorbereitung.




Kategorisierung von Inhalten möglich: Ja




Benutzer-Profile und Profilmanagement möglich: Ja




Personalisierte Webseiten möglich: Ja (über Berechtigungssystem)




Erkennung von Benutzern: Über Anmeldung im Browser (Cookies für PHP Session-Management).




Administration: Vollständig im Browser.




Sicherheit: Über Benutzer, Gruppen und Zugriffsrechte; komplett frei definierbar; drei Gruppen vordefiniert (anonyme Besucher, Benutzer, Admins).




Benachrichtigung: Mailing innerhalb des PostNuke-Systems möglich.

1.6 Unternehmenskriterien Unternehmen beurteilen die Leistungsfähigkeit eines CMS meist nach folgenden Kriterien.

1.6.1 Bedienung PostNuke ist auf allen Berechtigungs-Ebenen und in allen Modulen ausschließlich über den Browser bedienbar. Das Standard-System ist für Benutzer effizient und einfach zu handhaben. Installiert der Administrator Drittmodule, kann sich natürlich die Bedienung der neuen Komponenten von denen der Standard-Komponenten unterscheiden. Je nach Anforderung können die verschiedensten WYSIWYGEditoren integriert werden.

6






1 Was ist PostNuke?

1.6.2 Funktionalität Bereits die Standard-Installation ist umfangreich ausgestattet, meist kommt man schon mit einem kleineren Funktionsumfang aus. PostNuke wächst mit den Anforderungen. Sollte eine Funktion nicht vorhanden sein, kann man aus über 200 weiteren Modulen und Blöcken auswählen. Alternativ können eigene Module und Blöcke über die PostNuke-API mit PHP erstellt werden.

1.6.3 Benutzerverwaltung PostNuke verfügt über ein sehr umfangreiches Rechtesystem. Fast jedes Modul und nahezu jeder Bereich der Präsenz lässt sich sicherheitstechnisch auf die unterschiedlichsten Bedürfnisse hin anpassen. Beispiele:


Die Struktur der Redakteure und die Anforderung des Unternehmens ist abbildbar.




Jeder Bereich kann über eigene Autoren verfügen (Presse, Service, Produkt etc.)




Definition beliebiger Benutzer und Gruppen ist möglich




Berechtigungen können sowohl für Benutzer als auch Gruppen gesetzt werden




Freigabefunktion ist vorhanden

Dies ist bei größeren Projekten mit vielen Benutzern im Unternehmensumfeld ein entscheidender Vorteil.

1.6.4 Technische Leistungsfähigkeit Das Open Source CMS setzt auf klassische Webserver-Umgebungen auf. Das Betriebssystem ist frei wählbar, der Einsatz eines Apacheoder IIS-Webservers ist empfohlen, eine SQL-Datenbank und PHP sind ein Muss.

1.6 Unternehmenskriterien






7

1.6.5 Erweiterbarkeit PostNuke ist hochmodular und wird mit einer ganzen Reihe von Modulen geliefert. PostNuke ist darüber hinaus frei programmierbar. Es verfügt über eine eigene API, mit der sich Blöcke und Module mit User- und Administrations-Bereich erstellen lassen. Durch den Einsatz von Standard-Software wie dem MySQL-Datenbankserver lässt sich ein einfacher Datenaustausch mit anderen Systemen realisieren.

1.6.6 Investitionssicherheit PostNuke erfreut sich wachsender Beliebtheit und besitzt eine umfangreiche Entwicklergemeinde. Viele Firmen bieten zudem Dienstleistungen in Installation, Entwicklung und Betreuung von PostNuke-basierten Seiten an.

1.7 Zusammenfassung Dieses Kapitel gab Ihnen einen Einblick in die Leistungsfähigkeit des CMS PostNuke. Zusätzlich wurden Entscheidungskriterien für Unternehmen diskutiert und Hardware- sowie Software-Voraussetzungen erläutert. Das in diesem Kapitel erwähnte Anforderungsprofil einer fiktiven Firma dient als Grundlage für alle Beispiele der folgenden Kapitel.

1.8 Ausblick Das nächste Kapitel beschäftigt sich mit der Installation einer Server-Umgebung, die für den Betrieb eines PostNuke-CMS notwendig ist.

8






1 Was ist PostNuke?

2 Installation einer WebserverUmgebung

Dieses Kapitel richtet sich an alle, die eine eigene Server-Umgebung bestehend aus Webserver, Datenbank-Server und PHP aufsetzen möchten oder müssen, die für den Betrieb eines PostNuke-Portals notwendig ist. Wenn Sie bereits einen Server mit dieser Software einsetzen (z.B. bei Ihrem Internet-Provider), dann können Sie dieses Kapitel überspringen. Für alle, die dieses Kapitel lesen, sei angemerkt, dass aus Gründen der Einfachheit das vorkonfigurierte XAMPP-Paket für Windows beschrieben wird, welches die von PostNuke benötigten Anwendungen wie Webserver, SQL-Datenbank und PHP in einem einfach zu installierenden Komplett-Paket beinhaltet. Das XAMPP-Paket ist allerdings nur eine von vielen Möglichkeiten, eine Webserver-Umgebung aufzusetzen. Bei Fragen – auch zu den verschiedenen Linux-Varianten – kann Ihnen auch Ihr InternetProvider weiterhelfen.

XAMPP steht als Abkürzung für die Anfangsbuchstaben der Komponenten Apache, MySQL, Perl und PHP. Das X ist ein Platzhalter für ein beliebiges Betriebssystem.

2.1 Aufsetzen einer Server-Umgebung mit XAMPP (Windows) „So mancher wird schon die Erfahrung gemacht haben: Ein Apache-Webserver installiert sich nicht so leicht. Noch schwieriger wird es, wenn weitere Pakete wie MySQL, PHP oder Perl dazukommen. XAMPP ist eine Distribution von Apache, MySQL, PHP und Perl, die es ermöglicht diese Programme auf sehr einfache Weise zu installieren.“ [Zitat XAMPP-Homepage unter http://www.apachefriends.org] Gerade für wenig erfahrene Anwender und/oder bei Testsystemen bietet sich diese Art der Installation gegenüber der Einzelinstallation

2.1 Aufsetzen einer Server-Umgebung mit XAMPP (Windows)






9

der Anwendungen als Einstieg an. Mit zunehmender Erfahrung und wachsenden Anforderungen kann das System problemlos mithalten, die Flexibilität der verwendeten Software-Produkte hat unter der Vereinigung nicht gelitten. Die in XAMPP enthaltenen Anwendungen unterscheiden sich nicht von den jeweiligen „Stand Alone“-Versionen. Alle Handbücher, Anleitungen und Tipps aus Webforen und Newsgroups lassen sich so auch auf die Programme im XAMPP-Paket anwenden.

2.1.1 XAMPP-Varianten Von XAMPP gibt es zahlreiche Varianten. Welche man benötigt, hängt zunächst von der verwendeten Betriebssystem-Plattform ab. Linux-Anwender benötigen XAMPP für Linux (früher auch als LAMPP bekannt), Windows-Anwender dementsprechend XAMPP für Windows (analog als WAMPP bezeichnet). XAMPP für Windows ist zur Drucklegung des Buches in den zwei Ausprägungen „XAMPP“ und „XAMPP Lite“ erhältlich.

In der kleineren Version „XAMPP Lite“ sind neben den namensgebenden Bestandteilen Apache, MySQL, PHP, und Perl noch ADODB, SQL Lite und phpMyAdmin enthalten. Für den Betrieb von PostNuke ist diese Variante mehr als ausreichend. Wer zusätzlich SSL, einen FTP- und einen Mailserver benötigt, sollte zum vollständigen XAMPP-Paket greifen. Beide Alternativen sind als gepacktes Archiv und selbstextrahierende Datei verfügbar.

2.1.2 Installation von XAMPP Lite unter Windows 1. Laden Sie die „XAMPP Lite“-Variante als EXE-Datei von http://www.apachefriends.org herunter. 2. Führen Sie die EXE-Datei aus. Geben Sie als Installationspfad beispielsweise c:\programme an. Die EXE-Datei wird darin automatisch einen xampplite-Unterordner anlegen (im folgenden einfach als XAMPP-Verzeichnis bezeichnet). 3. Führen Sie die setup_xampp.bat aus dem XAMPPVerzeichnis aus. Damit werden einige Pfade in Konfigurationsdateien angepasst. 4. Die Installation ist damit abgeschlossen. Die heruntergeladene EXE-Datei kann gelöscht werden.

10






2 Installation einer Webserver-Umgebung

5. Um Probleme mit Zeichensätzen und Umlauten (Stichwort: UTF8) o.ä. von vornherein auszuschließen, öffnen Sie aus dem XAMPP-Verzeichnis die Datei mysql\bin\my.cnf (wird unter Windows nur als „my“-Zielwahl dargestellt) und suchen Sie nach einer Zeile der Art set-variable = defaultcharacter-set=utf8. Löschen Sie diese Zeile.

2.1.3 Start, Test und Stopp der XAMPP-Umgebung unter Windows 1. Wechseln Sie direkt ins XAMPP-Verzeichnis und starten Sie die Datei xampp_start.exe. Damit wird der Apache Webserver und der MySQL-Datenbankserver gestartet. Erlauben Sie bei installierter Firewall die Netzwerkkommunikation des Apache HTTP und MySQL-Datenbankservers. Das erscheinende DOS-Fenster muss geöffnet bleiben. 2. Sie können mit dem Windows Taskmanager im Tab „Prozesse“ überprüfen, ob mindestens zwei Apache.exe und ein mysqld.exe gestartet wurden. 3. Starten Sie ihren Webbrowser und greifen Sie auf http://localhost zu. Sollten Sie von einer anderen Maschine auf Ihre Installation zugreifen wollen, verwenden Sie http://maschinenname oder http://IP-Adresse. Erscheint hier ein XAMPP-Startbildschirm, so läuft das XAMPP-System und der anschließenden Installation von PostNuke steht nichts mehr im Wege. 4. Sie stoppen XAMPP, in dem Sie aus dem XAMPPVerzeichnis die Datei xampp_stop.exe ausführen.

2.2 Zusammenfassung Das Kapitel richtete sich an alle, die keine funktionsfähige ServerUmgebung, bestehend aus Webserver, Datenbankserver und PHP besitzen. Mit XAMPP Lite wurde solch eine Umgebung exemplarisch unter Windows eingerichtet.

2.2 Zusammenfassung






11

2.3 Ausblick Das folgende Kapitel wird sich mit der Installation des PostNuke Content Management Systems 0.750 Gold/0.760 befassen. Zudem werden Sie erste Grundkonfigurationen vornehmen, weitere Benutzer einrichten und Content pflegen und managen.

12






2 Installation einer Webserver-Umgebung

3 Die PostNuke-Installation

Nachdem die Server-Umgebung auf einem öffentlichen InternetServer bei Ihrem Provider oder bei Ihnen im Haus eingerichtet ist, können Sie mit der Installation von PostNuke beginnen. Anschließend werden Sie das System in den wichtigsten Einstellungen konfigurieren.

3.1 Download von PostNuke 1. Falls der Web- und/oder Datenbankserver nicht gestartet ist, starten Sie diese bitte, z.B. Ihre XAMPP-Installation. 2. Laden Sie „PostNuke 0.750 Gold“ im Original von http://www.postnuke.com oder dem deutschsprachigen PostNuke-Portal unter http://www.post-nuke.net herunter. Das Paket enthält noch keine deutsche Sprachdateien – das holen wir später in diesem Kapitel nach. 3. Extrahieren Sie die Datei in die Document Root Ihres WebServers. Im Fall von XAMPP findet sich dieses unter xampplite\htdocs. Dies dauert unter Umständen einige Minuten. 4. Benennen Sie anschließend das dort neu entstandene Verzeichnis PostNuke-0.750 in postnuke um.

3.2 Installation mit install.php 1. Starten Sie Ihren Webbrowser und rufen Sie das Installationsskript von PostNuke auf, indem Sie folgende URL eingeben: http://localhost/postnuke/html/install.php

3.1 Download von PostNuke






13

2. Wählen Sie am besten die deutsche Installationssprache. Dies hat Auswirkungen auf die Sprache der Installationsdialoge sowie die Sprache der Oberfläche, mit der PostNuke später startet. 3. Nach einigen Dialogen wie Lizenzbedingungen usw. werden Sie zur Eingabe von folgenden Daten aufgefordert:

Alternativ können Sie die PostNukeDatenbank z.B. mit phpMyAdmin anlegen.

14









Datenbank-Host: befindet sich die PostNuke-Installation und der MySQL-Datenbankserver auf dem gleichen Rechner (bei der Installation von XAMPP die Regel), geben Sie einfach „localhost“ ein, ansonsten den DNS-Namen oder die IP-Adresse des MySQL-Servers. Beachten Sie bei der Installation auf dem Rechner eines Internet-Providers, dass dieser den Zugriff des Webservers auf den MySQL-Server erlaubt.




Datenbank-Benutzername: im Fall einer Standard-XAMPPInstallation root, ansonsten ein entsprechender MySQLBenutzer.




Datenbank-Passwort: im Fall einer Standard-XAMPPInstallation brauchen Sie kein Passwort angeben, ansonsten das Passwort des entsprechenden MySQL-Benutzers.




Datenbank-Name: wenn Sie die Rechte haben, eine eigene Datenbank zu erzeugen, geben Sie beispielsweise phoenix ein, ansonsten wird hier der Ihnen (vom Provider) zugewiesene Datenbankname eingetragen. Wichtig ist, dass der Datenbankname mit einem Buchstaben beginnt.




Datenbank-Tabellen-Typ: wählen Sie hier vorzugsweise MyISAM aus; der schnellere Tabellentyp INNODB befindet sich noch im Entwicklungsstadium.




Alle anderen Einstellungen wie Tabellenpräfix, IntranetBenutzung o.ä. können so übernommen werden.

4. Nächster Dialog: wählen Sie im Falle einer Neuinstallation von PostNuke den Button Neue Installation. Existiert bereits eine ältere PostNuke-Installation, wählen Sie Upgrade. 5. Nächster Dialog: Wählen Sie die Checkbox neue Datenbank anlegen im Neuinstallations-Dialog an, wenn die MySQL-Datenbank (z.B. phoenix) vor der Installation von PostNuke noch nicht existieren sollte. Im Beispiel einer lokalen Installation mit XAMPP müssen Sie die Checkbox also anhaken.

3 Die PostNuke-Installation

6. Die folgenden Dialoge müssen von Ihnen sinnvoll ergänzt und können einfach bis zum Abschluss der Installation bestätigt werden. 7. Sie können ihr Portal nun über http://localhost/postnuke/html/index.php oder über den Link im letzten Installationsdialog zur neu eingerichteten PostNuke-Seite aufrufen.

Wenn Sie die Zugangsdaten des Administrators bei der Installation nicht geändert haben, lauten diese „Admin“ mit Passwort „Password“.

Abb. 3.1: Die PostNukeStartseite mit ExtraLite-Theme

3.2 Installation mit install.php






15

3.3 Alternative: manuelle Installation Die Benutzeroberfläche ist nach der manuellen Installation komplett in englisch gehalten.

1. Legen Sie eine neue Datenbank an, z.B. mit phpMyAdmin, Datenbankname: postnuke. 2. Importieren Sie die Datei Phoenix-0.7.5.0.sql aus dem Ordner postnuke/phoenix-sql in Ihre neue Datenbank. 3. Die Tabellen werden angelegt und gefüllt, das Präfix für die Tabellen lautet pn. 4. Öffnen Sie die Datei config.php aus dem Ordner postnuke/html.

Session initialisation failed? Überprüfen Sie die prefixEinstellung in der config.php oder leeren Sie Ihre SessionTabelle.

5. Passen Sie folgende Zeilen an: $pnconfig['dbhost'] = 'IP oder DNS-Name Ihres Datenbank-Servers'; $pnconfig['dbuname'] = 'Datenbank-Benutzername'; $pnconfig['dbpass'] = 'Passwort des Datenbank-Benutzers'; $pnconfig['dbname'] = 'postnuke'; $pnconfig['prefix'] = 'pn'; $pnconfig['encoded'] = '0'; Sie können ihr Portal nun über http://localhost/postnuke/html/index.php aufrufen und sich mit dem Benutzer „Admin“, Passwort „Password“ einloggen.

3.4 Installation absichern Um die Installation abzusichern, wechseln Sie bitte in das Installationsverzeichnis von PostNuke (im Falle von XAMPP ist dies das Verzeichnis xampplite/htdocs/postnuke/html) und löschen Sie die Datei install.php sowie das installVerzeichnis. Damit verhindern Sie, dass Dritte durch eine Neuinstallation administrativen Zugriff auf Ihr PostNuke-System erhalten oder Ihr Portal überschreiben und damit zerstören können.

16






3 Die PostNuke-Installation

Seit der Version 0.750 Gold müssen Sie diese Dateien sogar löschen, da Ihnen ansonsten die Administration des Systems mit einem Hinweis auf noch vorhandene Installationsroutinen verwehrt wird.

3.5 Die config.php Die Installationsroutine von PostNuke legt die Zugangsdaten zur MySQL-Datenbank in der Datei config.php direkt im PostNukeHauptverzeichnis ab. Sollten Probleme mit der Installation, speziell mit dem Zugang zur Datenbank auftreten, hilft ein Blick in diese Datei. Die config.php ist folgendermaßen aufgebaut:


$pnconfig['dbtype'] = 'mysql'; Der Datenbank-Typ. Theoretisch jedes von ADODB unterstützte Datenbanksystem, in PostNuke 0.750 Gold nur MySQL




$pnconfig['dbtabletype'] = 'myisam'; Der Tabellen-Typ. Theoretisch jeder Tabellentyp, der von dem verwendeten Datenbanksystem unterstützt wird. Bei MySQL „myisam“ oder „innodb“.




$pnconfig['dbhost'] = ‚localhost'; Der Name des Rechners, auf dem Ihr Datenbank-Server läuft. Sind wie im Falle von XAMPP Datenbank- und Webserver auf der gleichen Maschine installiert, genügt die Angabe „localhost“.




$pnconfig['dbuname'] = 'RDyxcfTGWE465674pc=='; Der Benutzername zum Zugriff auf die Datenbank. Verschlüsselt, wenn encoded auf 1 gesetzt wurde, ansonsten im Klartext gespeichert.




$pnconfig['dbpass'] = 'TgEZgd4566b='; Das zum Benutzernamen gehörende Passwort. Verschlüsselt, wenn encoded auf 1 gesetzt wurde, ansonsten im Klartext gespeichert.




$pnconfig['encoded'] = '1'; Gibt an, ob die Zugangsdaten zur Datenbank verschlüsselt in der config.php abgelegt sind. Sollten Sie jemals den Benutzernamen oder das Passwort zum Zugriff auf die Datenbank ändern müssen, dann setzen Sie diese Variable auf 0 und tragen Benutzername und Passwort bei $pnconfig['dbuname'] und $pnconfig['dbpass'] im Klartext ein, oder verwenden das PostNuke Swiss Army Knife (siehe das Kapitel Troubleshooting, Backup und Recovery), um die Datenbank-Zugangsdaten verschlüsselt erzeugen zu können.

3.5 Die config.php

„Problem in Database Connection“? Eventuell hilft ein Editieren der Datei config.php.






17




$pnconfig['dbname'] = 'phoenix'; Der Name der Datenbank, in dem PostNuke Informationen speichern und abrufen darf.




$pnconfig['prefix'] = 'nuke'; Der Präfix aller Tabellennamen in der PostNuke-Datenbank. Wichtig, wenn für mehrere PostNuke-Installationen nur eine Datenbank zur Verfügung steht. In diesem Fall würden Sie dann für jede Installation einen anderen Präfix verwenden (Stichwort: Multisites).




$pnconfig['system'] = '0'; Die verwendete BetriebssystemPlattform für PostNuke. „0“ für Unix, Linux und sonstige UNIX-Plattformen, „1“ für Microsoft Windows-Plattformen.




$pndebug['debug'] = '0'; Wird diese Variable auf „1“ gesetzt, so öffnet sich beim Zugriff auf eine beliebige Seite des PostNuke-Systems ein neues Browserfenster und Debug-Informationen mit der Angabe der Zeit, die für die Erstellung der Ausgabe benötigt wurde sowie der Anzahl der durchgeführten SQLAbfragen. Das Debug-Modul nennt sich nach dem Namen des Autors „Lens Debug“ und findet sich unter html\includes\classes\lensdebug.




$pndebug['debug_sql'] = '0'; Wird diese Variable auf „1“ gesetzt, so werden wie oben SQL-Abfragen in einem separaten Fenster dokumentiert.

3.6 Deutsches Sprachpaket installieren 1. Laden Sie das „deutsche Sprachpaket 0.750“ von http://www.post-nuke.net herunter. Sie können Ihre Server-Umgebung und PostNuke ohne Probleme nebenbei weiter betreiben. Sie können in der PostNukeOberfläche über den „Sprachen“Block beliebig zwischen deutsch und englisch wechseln.

18






2. Entpacken Sie die ZIP-Datei direkt in das PostNukeVerzeichnis (im Falle von XAMPP in das Verzeichnis xampplite/htdocs/postnuke) und überschreiben Sie alle eventuell vorhandenen Dateien. 3. Rufen Sie Ihr Portal unter http://localhost/ postnuke/html auf. Ihr Portal verfügt nun über eine englische und deutsche Benutzeroberfläche.

3 Die PostNuke-Installation

Für andere Sprachpakete wie beispielsweise französisch gilt das Vorgehen analog. Im Kapitel Sprachpakete und Sprachentabelle wird beschrieben, wo Sie die Sprachpakete beziehen können.

3.7 Grundkonfiguration Nach der Installation sollten Sie einen Blick auf die allgemeinen Einstellungen Ihres PostNuke-Systems werfen. Dort ändern Sie die wichtigsten Angaben wie den Slogan Ihrer Seite, die StandardSprache oder die Zeitzone Ihres Systems. Zusätzlich können wir die selbständige Benutzerregistrierung deaktivieren.

3.7.1 Allgemeine Einstellungen 1. Loggen Sie sich als Administrator im System ein. 2. Klicken Sie im linken Bereich der Seite – dem HauptmenüBlock – auf den Link Administration. Abb. 3.2: Die Icons in der admin.php

3.7 Grundkonfiguration






19

3. Klicken Sie auf das Icon Einstellungen. Beachten Sie: die Administrations-Icons sind alphabetisch sortiert, allerdings nur nach deren englischsprachiger Bezeichnung.

20









Name: bei einer kommerziellen Seite meist der Firmenname.




Logo (Druckansicht): muss zunächst nicht geändert werden. Bezeichnet das Logo, welches oben links in der Druckansicht angezeigt wird. Sie finden das voreingestellte logo.gif im Verzeichnis postnuke/html/images.




Slogan: bei kommerziellen Seiten meist das Motto oder der Werbeslogan der Firma. Name und Slogan ergeben den Gesamttitel der Seite in der Art „Name :: Slogan“, der in der Titelzeile des Browsers angezeigt wird.




Meta Keywords: Feldinhalt kann gelöscht werden, da MetaKeywords von Suchmaschinen nicht mehr interpretiert werden.




Meta-Keywords dynamisch erzeugen: nein (nicht notwendig, kostet nur Rechenzeit).




Standard-Theme: legt fest, mit welchem Theme PostNuke startet.




Lokales Zeitformat: abhängig vom Server-Standort; wenn der Server in Deutschland steht, sollten Sie hier de_DE eintragen.




Zeitzone: wieder standort-abhängig. Hier gilt für Deutschland GMT +1:00.




Startseite: bezeichnet das Modul, dessen Inhalte angezeigt werden, wenn nur http://servername/postnuke (ohne Angabe von weiteren Parametern) aufgerufen wird.




pnAntiCracker aktivieren: wenn diese Option aktiviert ist, kann in einem Artikel kein Scriptcode (JavaScript, VBScript) eingefügt werden. Wird dies dennoch versucht, wird der Administrator durch pnAntiCracker über diesen Vorgang ausführlichst per Mail informiert.




Sprache der Website: wählen Sie hier [deu] aus (deutsches Sprachpaket vorausgesetzt).




Eingabefeld für die Fußzeile: hier können Sie beispielsweise Kontaktinformationen (auch im HTML-Code) hinterlegen, die auf jeder Seite am Ende einer PostNuke-Oberfläche angezeigt werden.




Backend-Titel: geben Sie hier noch einmal z.B. Ihren Firmennamen an. Diese Einstellung wird später u.a. von RSS-Feeds verwendet.

3 Die PostNuke-Installation




Backend-Sprache: wählen Sie wieder [de-de] aus. Auch das ist wieder nur für Funktionen wie RSS-Feeds interessant, die im Hintergrund der PostNuke-Seite aktiv sind (deswegen auch der Begriff „Backend“).




In Beiträgen erlaubte HTML-Tags: schalten Sie die Tags frei, die Sie Ihren Autoren zur Erstellung von Artikeln zur Verfügung stellen wollen. So können Sie die Einhaltung Ihres Corporate Identity steuern oder Tags abschalten, die die Sicherheit Ihres Internet- oder Intranet-Auftrittes gefährden.




Eingebette HTML-Entitäten in normale Zeichen wandeln: ist diese Option aktiviert, werden Sonderzeichen wie zum Beispiel ein „>“ in die entsprechende HTML-Darstellung „>“ umgewandelt. Sollte aktiviert bleiben.




Klicken Sie auf Änderungen speichern. Abb. 3.3: Die EinstellungsSeite unter Administration – Einstellungen

Alle anderen Einstellungen brauchen nicht geändert werden.

3.7 Grundkonfiguration






21

3.7.2 Benutzer-Einstellungen Standardmäßig sind nach der Installation der Administrator und ein anonymer Benutzer angelegt.

Wenn Sie verhindern wollen, dass sich Benutzer in Ihrem Portal autark registrieren können und damit einen Benutzer-Account erhalten, müssen Sie dieses Verhalten abschalten. Standard-Benutzer dürften zum Beispiel Artikel hinzufügen, die aber nur von Administratoren freigegeben werden können. Um die eigenständige Benutzer-Registrierung abzuschalten, gehen Sie wie folgt vor: 1. Loggen Sie sich als Administrator im System ein. 2. Klicken Sie im linken Bereich der Seite – dem HauptmenüBlock – auf den Link Administration. 3. Klicken Sie auf das Icon Benutzer-Administration. 4. Klicken Sie auf Konfiguration trierung.

Benutzerregis-

5. Das Verhalten schalten Sie über die Option Benutzerregistrierung ermöglichen ab. Überprüfen Sie auch gleich die übrigen Einstellungen und passen Sie diese notfalls an Ihre Bedürfnisse an. Davon sind die wichtigsten Optionen:

22









optionale Felder anzeigen: Sollen zusätzlich definierte (dynamische) Benutzerdaten in den persönlichen Benutzereinstellungen unter Benutzerprofil ändern angezeigt werden? Festgelegt werden diese Felder unter dem Menüpunkt Dynamische Benutzerdaten hier in der Benutzeradministration.




Kennwort vom System erzeugen lassen: Das System legt ein gültiges Passwort fest. Diese Option sollten Sie aus Sicherheitsgründen immer einschalten.




IDN-Domains: Erlauben von Umlaut-Adressen bei E-Mail und URL.

3 Die PostNuke-Installation

3.8 Zusammenfassung Das PostNuke-System wurde aufgesetzt, abgesichert und erste Konfigurationen vorgenommen. Das Portal ist damit voll funktionsfähig und einsatzbereit.

3.9 Ausblick Im nächsten Kapitel üben Sie den Umgang mit dem Portal, erstellen die ersten Artikel als Administrator/Benutzer, verwenden die Freigabefunktion, ändern das Layout Ihrer Seite usw.

3.8 Zusammenfassung






23

4 Umgang mit PostNuke

Nach der Installation präsentiert sich die Startseite von PostNuke unter http://servername/postnuke/html in einem spartanischen Look & Feel, welches durch das Theme „ExtraLite“ definiert wird. An dieser Stelle wird noch nicht tiefer auf Themes und deren Techniken eingegangen; es genügt zunächst zu wissen, dass ein Theme die Optik und das Verhalten einer Seite festlegt. Jedes Theme kann dies unterschiedlich realisieren. Alle folgenden Beschreibungen beziehen sich daher auf das Theme „ExtraLite“. Falls noch nicht geschehen, starten Sie Ihre Server-Umgebung (z.B. XAMPP), um Ihre PostNuke-Installation nutzen zu können.

4.1 Die Startseite und ihre Funktionen Jeder Benutzer des Systems kann sich aus den vom Administrator installierten Themes sein eigenes aktivieren – falls vom Admin erlaubt – und damit „seine“ PostNuke-Seite individuell gestalten. Im allgemeinen bietet jedes Theme folgende Bereiche: Abb. 4.1: Die StandardAufteilung eines Themes

Header (Banner, Site-Logos, Suche)

linke Blöcke

Content-Fenster (mittlere Blöcke + Modul-Inhalte)

rechte Blöcke

Footer (Impressum, Kontakt, Banner, RSS usw.)

4.1 Die Startseite und ihre Funktionen






25

Welches Modul bei Aufruf der Startseite seine Ausgaben an den ContentBlock schicken soll, wird in den allgemeinen Einstellungen unter „Startseite“ eingestellt.




Seitenkopf / Header: Hier befindet sich meist ein Logo, in der Regel auch ein Suchfeld. Auch eine Menüleiste lässt sich hier gut unterbringen.




Seitenfuß / Footer: Hier werden üblicherweise Kontaktinformationen hinterlegt, etwa die Adresse, Links zum Impressum, Kontaktformulare oder ähnliches. Die Informationen stammen aus den allgemeinen Einstellungen.




Dreispaltiges Layout: Die linke und rechte Spalte werden meist ausschließlich mit Blöcken – den sogenannten Sideblocks – belegt. Im mittleren Bereich, dem Content-Fenster, befinden sich Blöcke und der eigentliche Inhalt einer PostNuke-Seite.

4.1.1 Linke Spalte


Ein Menü-Block, der das Hauptmenü enthält.




Ein Block, der anzeigt, wie viele Besucher und Mitglieder sich momentan im System befinden.




Ein Block zur Sprachauswahl für die Oberfläche. Zeigt alle installierten Sprachen an, in unserer Beispielinstallation also Deutsch und Englisch.

4.1.2 Mittlere Spalte / Content-Fenster


Ein Block für eine Nachricht von Administratoren




Die neuesten Beiträge (dies ist ausnahmsweise kein Block, sondern die Ausgabe eines Moduls, in diesem Fall des StoryModuls).

4.1.3 Rechte Spalte

26









Ein Block namens „weitere Beiträge“, der Links auf andere Artikel enthält.




Ein Umfrage-Block.




Ein Block, der auf den meist gelesenen (bzw. aufgerufenen) Beitrag hinweist.

4 Umgang mit PostNuke




Der Anmelde-Block, mit dem sich Benutzer am System anmelden können.




Je nach Gestaltung der Inhalte im CMS wird PostNuke hier weitere Blöcke kontext-sensitiv anzeigen.

4.2 Anmelden am System (Login) Wie bereits erwähnt findet sich meist ein Block namens Anmeldung auf der PostNuke-Startseite. Es genügt, Ihren PostNukeBenutzernamen (z.B. Admin) und das entsprechende Passwort in die Felder einzugeben. Der Block kann noch weitere Funktionen wie Selbst-Registrierung von Benutzern anbieten. Durch den LoginVorgang wird eine so genannte Session (zu deutsch etwa „Sitzung“) erzeugt. Diese gilt so lange, bis Sie sich wieder abmelden oder vom System automatisch abgemeldet werden, je nach Konfiguration in den allgemeinen PostNuke-Einstellungen, die durch den Administrator vorgenommen werden kann. Mit http://servername/postnuke/html/user.php rufen Sie in jedem PostNuke-System Funktionen wie Anmeldung, Registrierung oder vergessenes Passwort anfordern auf. Dies ist zum Beispiel nützlich, falls kein dafür zuständiger Block vorhanden sein sollte. Abb 4.2: Die user.php – einmal im ausgeloggten, dann im eingeloggten Zustand

4.3 Benutzerspezifische Konfiguration Unter dem Link Einstellungen im Hauptmenü können PostNuke-Benutzer sich ihr System zu einem gewissen Grad individuell anpassen. Die wichtigsten Einstellungen sind:

4.2 Anmelden am System (Login)






27




Startseite einstellen: Anzahl der anzuzeigenden Artikel auf der Startseite plus Angabe eines persönlichen Menüs (z.B. sinnvoll für einen persönlichen ToDo-Zettel). Der Inhalt dieses Menüs ist frei definierbar und kann auch HTML-Code enthalten.




Theme-Auswahl: Ist die Einstellung dürfen Benutzer Theme individuell einstellen im Bereich Administration - Einstellungen gesetzt, so dürfen Benutzer hier ihr favorisiertes Theme aussuchen.




Kommentar-Konfiguration: Hier lassen sich Ansicht, Sortierung und Länge von Kommentaren einstellen. Darüber hinaus kann hier angegeben werden, ob Wertungen angezeigt werden sollen. Auch im Falle der Wertungsunterdrückung werden Wertungen weiter angewendet, jedoch nicht mehr angezeigt.

4.4 Benutzer-Verwaltung In 0.750 Gold: Um Benutzer editieren oder löschen zu können, müssen Sie deren Benutzernamen eingeben, da es keine Auswahlliste für bestehende Benutzer gibt.

Das Anlegen, Editieren und Löschen von Benutzern erfolgt unter Administration - Benutzer-Administration.

4.4.1 Benutzer anlegen Um später als „normaler“ Benutzer einen Artikel im System einreichen zu können, legen Sie zum Test einen Benutzer mueller an, der im Laufe des Kapitels noch eine Rolle spielen wird. Gehen Sie dazu wie folgt vor: 1. Loggen Sie sich als Administrator im System ein. 2. Klicken Sie im linken Bereich der Seite – dem HauptmenüBlock – auf den Link Administration. 3. Klicken Sie auf das Icon Benutzer-Administration. 4. Legen Sie unter Neuen Benutzer hinzufügen einen neuen Benutzer an, beispielsweise mit Namen mueller. Der neue Benutzer (der automatisch Standard-Benutzerrechte zugewiesen bekommen hat) darf später

28






4 Umgang mit PostNuke




das Portal und alle Module verwenden (hat mindestens lesenden Zugriff auf alle Bereiche)




Artikel und anderen Content wie Downloads oder Link-Listen erstellen (aber nicht freigeben)




Content kommentieren oder bewerten




hat aber keine Rechte, um das Gesamtsystem PostNuke zu administrieren.

4.4.2 Kennwort vom System zurücksetzen lassen/neues Kennwort anfordern Als Benutzer haben Sie die Möglichkeit, sich ein neues Passwort von PostNuke zusenden zu lassen, wenn Sie Ihr altes Passwort vergessen haben sollten. Diese Funktion wird nicht direkt im LoginBlock angeboten. Gehen Sie dazu wie folgt vor: 1. Nutzen Sie im ausgeloggten Zustand den Link Vergessenes Kennwort anfordern direkt über den Aufruf der nachfolgenden URL: http://<servername>/postnuke/html/user.php. 2. Geben Sie zunächst nur Ihren Benutzernamen und Ihre im System eingetragene E-Mail-Adresse an. Sie erhalten eine EMail mit einem Bestätigungscode (wenn Ihre ServerUmgebung für den Versand von E-Mail eingerichtet ist). 3. Diesen Code geben Sie nach Klick auf den Zurück-Link im gleichen Formular zusätzlich mit an. Im Anschluss wird Ihnen eine zweite E-Mail zugestellt, die Ihr neu zugeteiltes Passwort enthält.

4.4.3 Passwort eines Benutzers zurücksetzen 1. Loggen Sie sich als Administrator im System ein. 2. Klicken Sie im linken Bereich der Seite – dem HauptmenüBlock – auf den Link Administration. 3. Klicken Sie auf das Icon Benutzer-Administration.

4.4 Benutzer-Verwaltung






29

4. Geben Sie den Namen des Benutzers ein, dessen Passwort geändert werden soll, wählen Sie modifizieren aus und klicken Sie auf Ok. 5. Im folgenden Dialog können Sie das neue Passwort vergeben.

4.4.4 Dynamische Benutzerdaten Unter Benutzer-Administration – dynamische Benutzerdaten können weitere, eigene Attribute zu Benutzerdaten definiert werden, falls Ihnen die Standard-Attribute bei der Benutzerpflege nicht ausreichen.

4.5 Gruppen Unter Administration - Gruppen können Sie einzelne Benutzer in beliebigen Gruppen zusammenfassen. Das sollten Sie immer dann machen, wenn mehrere Benutzer dieselben Aufgaben durchführen sollen oder Sie nicht jedem Benutzer Zugriffsrechte separat vergeben möchten. Die Vorteile liegen auf der Hand:


potentielle Minimierung des Verwaltungsaufwands




die Rechtevergabe für Gruppen ist sicherer, logischer und ist weniger fehleranfällig als die Rechtevergabe an einzelne Benutzer




schneller Wechsel der Gruppenzugehörigkeit ist möglich




Rechte können durch Zugehörigkeit von Benutzern in mehreren Gruppen kumuliert werden.

Standardmäßig sind die Gruppen Admins und Users vorhanden. Alle ausgeloggten Benutzer gehören automatisch zur Gruppe „unregistrierte (Gruppe)“. Die unregistrierte Gruppe ist nur ein logisches Konstrukt und kann daher im Gruppenmodul nicht administriert werden. Im Berechtigungsmodul können den „Unregistrierten“ aber durchaus Rechte zugewiesen werden – genau so wie der Gruppe „alle Gruppen“, die ebenfalls nur ein logisches Konstrukt darstellt.

30






4 Umgang mit PostNuke

Wird ein Benutzer oder eine Gruppe gelöscht, werden auch alle zugehörigen Zugriffsrechte gelöscht. Löschen Sie eine Gruppe, der noch Benutzer zugeordnet sind, so bleiben die Benutzer erhalten. Die Benutzer haben dann im schlimmsten Fall keine Gruppenzugehörigkeit mehr, und gehören auch nicht zur Gruppe der unregistrierten Benutzer! Nimmt man den Benutzern im eingeloggten Zustand die Gruppenzugehörigkeit weg, haben diese sofort keine Berechtigungen mehr auf das System, können sich also auch nicht mehr ausloggen. Um dann noch lesenden Zugriff auf das Portal zu bekommen, müssen diese sich manuell über den Aufruf der URL http://servername/postnuke/ html/user.php?module=NS-User&op=logout abmelden – oder einfach die lokalen Cookies löschen.

Löschen von Benutzern und Gruppen

Der eigentliche Sinn von Benutzern und Gruppen liegt in der Zuweisung von Berechtigungen, was in diesem Kapitel noch kurz erläutert werden wird. Genauere Details zu Berechtigungen finden sich dann im gesonderten Kapitel Sicherheit.

4.6 Blöcke und Module 4.6.1 Grundlagen Blöcke und Module machen die Funktion, das Verhalten und letztlich auch das Aussehen einer PostNuke-Seite aus. Das CMS wird bereits in der Grundinstallation mit einer für den Anfänger unübersichtlichen Zahl von Blöcken und Modulen ausgeliefert. Darüber hinaus gibt es im Internet hunderte weitere kostenlose oder kostenpflichtige Funktionsbausteine zum Download. Ein Modul ist ein eigenständiges Programm innerhalb von PostNuke, zuständig für eine ganz bestimmte, mehr oder minder komplexe Aufgabe, z.B. zur Verwaltung einer Adress-Datenbank oder einer Download-Sektion. Die Dateien zu Modulen finden sich im Dateisystem von PostNuke unterhalb von postnuke/html/modules. Blöcke sind die kleinste, frei positionierbare Informationseinheit, die das CMS PostNuke darstellen kann. Blöcke können links, mittig

4.6 Blöcke und Module






31

oder rechts positioniert werden. Letztlich ist es Sache eines Themes, ob es diese drei Einstellmöglichkeiten überhaupt umsetzt. Die meisten Themes arbeiten jedoch mit der klassischen Seitenaufteilung „linke Blöcke – Content Fenster in der Mitte – rechte Blöcke“. Es gibt zwei verschiedene Blockarten:


Autarke Blöcke mit überschaubarem eigenen Funktionsumfang. Diese werden im postnuke/html/includes/blocksVerzeichnis abgelegt und dadurch dem Modul „Core“ (dem PostNuke-Kernel) zugeordnet.




Modulblöcke, die nur in Verbindung mit einem Modul arbeiten. Ein Modul legt seine Blockdateien im jeweiligen Modulverzeichnis unterhalb von postnuke/html/modules/ <modulname>/pnblocks ab.

Ältere Module haben in der Vergangenheit ihre Blockdateien ebenfalls in postnuke/html/includes/blocks abgelegt. Daher sind einige Blöcke dem Core zugeordnet, die eigentlich einem Modul angehören. Darüber hinaus gibt es Module ohne Blöcke und ohne direkte Ausgabe im Content-Fenster. Solche Module dienen zum Beispiel der Anbindung externer Editoren an PostNuke. Die Funktionen und Eigenschaften aller Core-Blöcke werden im Kapitel Blöcke erläutert. Die Modulblöcke werden zusammen mit ihrem jeweiligen Modul im Kapitel Module erläutert. Beachten Sie: Je mehr Blöcke oder Module auf der Seite aktiv sind, desto langsamer wird der Gesamtdurchsatz des Systems. Darüber hinaus steigt die Gefahr, sein System durch Sicherheitslöcher verwundbar zu machen. Installieren und aktivieren Sie also nur Blöcke und Module, die Sie wirklich brauchen. Alle restlichen sollten Sie deaktivieren und löschen. Welche Module minimal für ein CMS benötigt werden, ist z.B. im Kapitel pnmini ersichtlich. Anhand eines Beispiels soll die Installation von Blöcken und Modulen gezeigt werden. Interessante Module und Blöcke anderer Hersteller finden sich im ersten Anlauf auf der Homepage von PostNuke (http://www.postnuke.com) oder dem deutschen PostNuke-Portal (http://www.post-nuke.net).

32






4 Umgang mit PostNuke

Angenommen, die fiktive Firma benötigt für ihre Marketingabteilung einen kleinen Newsticker. Solch eine Funktion findet sich im Standard-PostNuke-Paket nicht, weder als Block noch als Modul. Mit einer Suche nach „Newsticker“ auf postnuke.com wird man aber schnell fündig (oder direkt vom Autor unter http://www.bytebros.cc). Laden Sie das Newsticker-Modul einmal in der neuesten Version herunter. Zur Installation des Moduls und seiner Blöcke gehen Sie vor wie im folgenden beschrieben.

4.6.2 Modul installieren 1. Entpacken Sie das ZIP-Archiv des Newsticker-Moduls. 2. Verschieben Sie alle extrahierten Dateien so ins postnuke/html/modules-Verzeichnis, dass sich dort der Ordner newsTicker findet, der die Dateien aus dem ZIP-Archiv enthält. In dem Ordner postnuke/html/modules/ newsticker müssen sich dann direkt Dateien wie pnadminapi.php, pnadmin.php usw. finden. Das Modul bringt eigene Blöcke mit, was man am Unterordner pnblocks erkennen kann.

Die Installationsbeschreibung ist unabhängig vom verwendeten Modul.

3. Wechseln Sie als Administrator in Ihr PostNuke-System. 4. Klicken Sie im linken Bereich der Seite – dem HauptmenüBlock – auf den Link Administration. 5. Klicken Sie auf das Icon Module. 6. Durch Klick auf anzeigen werden alle bereits installierten Module aufgelistet. Hier taucht unser frisch eingefügtes Newsticker-Modul nicht auf, da die momentan angezeigte Liste aus der Datenbank geladen wird. Klicken Sie also auf erneut erzeugen, damit auch das langsamere Dateisystem nach Modulen durchsucht und damit die Liste aktualisiert wird. 7. Klicken Sie in der Modulauflistung beim Newsticker-Modul auf initialisieren. 8. Klicken Sie anschließend in der Modulauflistung beim Newsticker-Modul auf aktivieren. Das Modul ist installiert und wartet auf seinen Einsatz. Der Hauptmenü-Block enthält jetzt automatisch einen neuen Eintrag „newsTicker“, der auf die Benutzer-Oberfläche des Newsticker-Moduls ver-

4.6 Blöcke und Module






33

weist. Der Link funktioniert nur deshalb nicht, da dieses Modul keine Oberfläche für Standard-Benutzer anbietet. Abb. 4.3: Auszug einer ModulAuflistung unter Administration – Module

Die Administration des Moduls wird – wie bei allen Modulen – in der Administrations-Oberfläche von PostNuke vorgenommen (im linken Bereich der Seite – dem Hauptmenü-Block – über den Link Administration).

4.6.3 Modul administrieren Das Modul kann jetzt über ein eigenes Icon direkt in der Administrationsoberfläche von PostNuke konfiguriert werden. Legen Sie hier einige neue News-Einträge an, die später in einem Block auf der Oberfläche durchscrollen sollen. Wir werden nachher einen Block anlegen, der die News-Einträge auch auf der Oberfläche scrollbar anzeigt.

4.6.4 Aufruf von Modulen pnAPI-konforme Module (= newStyle-Module)

34






Module können neben der Nutzung von Icons in der Administration oder Links in der Oberfläche auf zwei direktere Arten aufgerufen werden, abhängig davon, ob man deren Administrations- oder die Benutzeroberfläche angezeigt bekommen möchte. Man muss nur die URLs dazu kennen, die folgendermaßen lauten:


Administrationsoberfläche des Moduls aufrufen: index.php?module=ModulName&type=admin[&func=Funktion]




Benutzeroberfläche des Moduls aufrufen: index.php?module=ModulName[&type=user][&func=Funktion]

4 Umgang mit PostNuke

Die Parameter bedeuten:


module=ModulName: weist die index.php an, das Modul mit dem angegebenen Namen zu laden, z.B. index.php?module=newsTicker




type=admin/user: legt fest, welche Benutzeroberfläche aufgerufen werden soll. Wird diese Angabe weggelassen, geht PostNuke standardmäßig davon aus, dass man die Benutzeroberfläche (= „user“) des Moduls laden möchte.




func=Funktion: Wird „func=Funktion“ angegeben, wird PostNuke versuchen, die angegebene Funktion im Modul auszuführen. Wird dieser Teil weggelassen, versucht PostNuke, das Hauptprogramm im Modul aufzurufen (die so genannte MainFunktion). Damit gelangt man auf die jeweilige Startseite des Moduls. Wird die Funktion nicht gefunden oder ist keine Main-Routine implementiert, erscheint die Fehlermeldung Failed to load module <ModulName> (at function: „“).

Diese Art von URLs gilt nur für Module, die nach neueren Standards entwickelt wurden. Diese Module werden als „pnAPIkonform“ bezeichnet. Einige der Core-Module, die zu PostNuke mitgeliefert werden, stammen allerdings noch historisch aus Thatware- und PHPNuke-Zeiten und werden deshalb noch nach einem alten Standard aufgerufen. Dies wird sich in kommenden Versionen von PostNuke ändern. Der Vollständigkeit halber sei auch die alte Art und Weise des Aufrufs erläutert: ad-




Administrationsoberfläche des Moduls aufrufen: min.php[?module=ModulName][&op=Funktion]




Benutzeroberfläche des Moduls aufrufen: modules.php[?op=Funktion][&name=ModulName][&file=Datei]

Wird „op=Funktion“ nicht angegeben, ergänzt PostNuke dies automatisch zu „modload“, welche dann die unter „file=Datei“ angegebene PHP-Datei lädt. Ist „file“ nicht angegeben, wird nach einer index.php im angegebenen Modul gesucht. Wird der Parameter „name=ModulName“ für den Aufruf von Admin-Funktionen weggelassen, geht PostNuke dann ins Pleistozän der Nuke-Systeme zurück und versucht das Modul „PastNuke“ zu laden.

4.6 Blöcke und Module

old-StyleModule

Hinweis: „op“ kennt sogar nur den Parameter „modload“.






35

4.6.5 Modul deinstallieren Bevor Sie ein Modul deinstallieren wollen, löschen Sie über die Block-Administration erst dessen zugehörige Blöcke, falls Sie davon welche auf Ihrer Site einsetzen. Anschließend können Sie problemlos das Modul in der Modul-Administration deinstallieren und sogar aus dem Verzeichnissystem löschen.

4.6.6 Blöcke administrieren Über Administration – Blöcke erhalten Sie eine Liste mit allen installierten bzw. den auf Ihrer Seite aktiven Blöcken. Die wichtigsten Eigenschaften im Überblick:

36









Reihenfolge: Die Block-Liste ist gruppiert nach Blöcken, die zentriert, links und rechts angezeigt werden.




Position: Zeigt an, ob der Block links, mittig oder rechts angezeigt werden soll. Inhalte mittig positionierter Blöcke werden im Content-Fenster über der Ausgabe der Module angezeigt – jedoch ist das abhängig vom verwendeten Theme.




Titel: Der auf der CMS-Oberfläche angezeigte Titel des Blocks. Dieser wird auch verwendet, um für Blöcke Berechtigungen zu vergeben (siehe Kapitel Sicherheit). Wird der Titel bei der Erstellung des Blockes nicht angegeben, setzen die meisten Blöcke einen eigenen, vordefinierten Titel.




Modul: Gibt an, zu welchem Modul der Block gehört. Wird das zugehörige Modul entfernt, ohne den Block zu entfernen, erhält man im Block eine Fehlermeldung Block type not found. Der Block muss dann gelöscht und neu angelegt werden, da er auch nach einer Neuinstallation des Moduls nicht mehr funktionieren wird.




Name: Bezeichnet eigentlich den Typ des Blocks.




Sprache: Für welche ausgewählte Sprache soll der Block angezeigt werden? Hinweis: in der Liste gibt es zwei „Alle“Einträge. Wenn Sie einen Block immer anzeigen lassen wollen, egal welche Sprache über die Oberfläche ausgewählt wurde, müssen Sie immer den ersten „Alle“-Eintrag aus der Liste auswählen.

4 Umgang mit PostNuke




Optionen: Hier ist das Aktivieren/Deaktivieren, Editieren und Löschen von Blöcken möglich. Editieren ermöglicht das Ändern von Einstellungen im Block. Für jeden Block lässt sich hier immer der Titel, dessen Position, die Sprache und die Aktualisierungshäufigkeit für externe Inhalte einstellen (sollte der Block Inhalte externer Systeme einbeziehen, wird hier die Zeit angegeben, in welchen Intervallen die externen Quellen angezapft werden dürfen. In der Zwischenzeit wird sich der Block aus seinem Cache bedienen. Bei stark frequentierten PostNukeSeiten empfehlen wir das längste Refresh-Intervall, das Sie gerade noch verkraften können, um den Traffic auf die externen Server einzuschränken). Weitere Einstellungsmöglichkeiten sind vom Block abhängig.

Die Option Symbole zur Block-Verkleinerung unter Administration – Blöcke – konfigurieren sorgt dafür, dass Blöcke vom Benutzer eingeklappt/minimiert werden können. PostNuke merkt sich die Einstellungen auch nach der Abmeldung des Benutzers. Möchten Sie dafür andere Icons einsetzen, können Sie die Dateien upb.gif und downb.gif im Verzeichnis postnuke/html/images/global/upb.gif ersetzen.

Sollte ein Block keine Ausgabe erzeugen, wird er innerhalb der PostNukeOberfläche in der Regel ausgeblendet.

Hinweis: Wenn Sie bei einer mehrsprachigen Seite sprachabhängige Blocktitel einsetzen möchten (z.B. „Hauptmenü“ und „Main Menu“), müssen Sie für jede Sprache jeweils einen Block vom gleichen Typ anlegen und ihn in der Landessprache benennen. Ein englischer Block bekommt einen englischen Titel, gilt nur für die englische Sprache, wird sonst aber gleich konfiguriert wie ein deutscher Block. Das Sie so für ein und dieselbe Aufgabe mehrere Blöcke vom gleichen Typ administrieren müssen, ist nicht elegant. Sind für diese Blöcke Zugriffsregeln definiert, können diese entsprechend komplexer ausfallen. PostNuke verwaltet die Liste und die Eigenschaften der anzuzeigenden Blöcke übrigens in der Datenbank-Tabelle blocks.

4.6.7 Block hinzufügen Um einen Block aus dem Newsticker-Modul hinzuzufügen, gehen Sie wie folgt vor:

4.6 Blöcke und Module






37

1. Klicken Sie im linken Bereich der Seite – dem HauptmenüBlock – auf den Link Administration. 2. Klicken Sie auf das Icon Blöcke. 3. Wählen Sie neuer Block – Titel: Marketing-News – Block: newsTicker/Scrolling News Ticker – Position: links – Sprache: alle (der erste Eintrag in der Liste) – Übernehmen – Übernehmen. Da das Newsticker-Modul die Festlegung weiterer BlockEigenschaften ausnahmsweise in die Modul-Administration verlegt, müssen hier keine weitere Blockeigenschaften festgelegt werden. Abb. 4.4: Der NewstickerBlock

4.6.8 Hauptmenü-Block dynamisieren Editieren Sie den Block Hauptmenü und


schalten Sie die Anzeige von „Modulen“ und „zu prüfen“ ein.




löschen Sie aus dem Inhalts-Bereich alle Zeilen nach „Logout“ (oder verwenden Sie diese Zeilen für eigene Menüpunkte).

Damit wird der Menü-Block hochdynamisch und passt sich dem Umfang der Installation automatisch an.

4.7 WYSIWYG HTML-Editor „Type Tool“ Wenn Sie im Stories-Modul mit Type Tool arbeiten, verwenden Sie als Formatierungstyp „HTML vorformatiert“.

In der zum Redaktionsschluss vorliegenden Version wird der z.B. im Stories-Modul eingebundene WYSIWYG HTML-Editor Type Tool in der Version 8.0 verwendet. Der Editor „Type Tool“ erlaubt die Formatierung von Texten ohne Programmier- und HTMLKenntnisse wie aus den meisten Office-Programmen gewohnt. Nach dem Abspeichern ist der Artikel genau so wieder abrufbar, wie er vom Benutzer eingegeben und formatiert wurde.

Abb. 4.5: Symbolleisten des Type ToolEditors

38






4 Umgang mit PostNuke

Type Tool aktiviert man über Administration – typetool – Type Tool aktivieren. Der Editor wird allerdings erst bei einem Klick in ein Text-Eingabefeld aktiviert – und auch erst nach Bestätigung der erscheinenden Abfrage. Wenn Sie TypeTool das erste Mal für die Erstellung eines Artikels einsetzen und beispielsweise andere Schriftgrößen oder Schriftauszeichnungen wie Fettdruck verwenden, funktioniert das im Editor ohne Probleme. Spätestens bei Abruf des Artikel über die Startseite werden Sie enttäuscht sein: einige Formatierungen werden einfach als HTML-Code ausgegeben statt korrekt interpretiert zu werden. Die Lösung ist einfach: nicht alle HTML-Tags sind nach der Standard-Installation freigeschaltet. Sie müssen Formatierungs-Tags wie oder erst explizit erlauben. Klicken Sie dazu im linken Bereich der Seite – dem Hauptmenü-Block – auf den Link Administration und anschließend auf das Icon Einstellungen.

4.8 Content-Pflege: Den ersten Artikel erstellen Dieser Abschnitt beschreibt die Pflege von Artikeln im CMS. PostNuke behandelt dabei Administratoren und Standard-Benutzer unterschiedlich. Von Standard-Benutzern erstellte Artikel sind nie sofort im System abrufbar, sondern müssen von Administratoren erst kategorisiert und freigegeben werden. Da PostNuke nach einer Neuinstallation nur einen Benutzer – den Administrator – kennt, zeigen wir die Erstellung eines Artikels zunächst aus Sicht eines Administrators. Im anschließenden Unterkapitel legen wir einen Standard-Benutzer mit weniger Rechten an, dessen erstellten Artikel ein Administrator anschließend freigeben soll. Dies ist der Standard-Workflow bei Einsatz eines Content Management Systems.

Im CMS-Umfeld weit verbreitet: Benutzer/ Autoren erstellen Artikel, Administratoren/Redakteure geben diese frei.

4.8.1 Als Administrator In unserem Beispiel erstellen Sie nun als Administrator einen Artikel. Wenn Sie Ihre PostNuke-Seite aufgerufen haben, sehen Sie auf

4.8 Content-Pflege: Den ersten Artikel erstellen






39

der rechten Seite einen Login-Block. Loggen Sie sich mit dem in der Installation konfigurierten Admin-Account ein (Benutzername: Admin, Passwort: das bei der Installation vergebene Admin-Passwort). Um Ihren ersten eigenen Artikel zu erstellen, gehen Sie bitte folgendermaßen vor: 1. Klicken Sie im linken Bereich der Seite – dem HauptmenüBlock – auf den Link Administration. 2. Klicken Sie auf das Icon Beitrag hinzufügen. 3. Lassen Sie uns der Welt in einem Artikel mitteilen, dass wir eine neue PostNuke-Seite aufgesetzt haben. Geben Sie dem Artikel einen aussagekräftigen Titel wie Unsere neue Webseite auf Basis von PostNuke ist online. 4. Wählen Sie einen so genannten Topic aus. Eine frische PostNuke-Installation kennt nur die beiden Topics PostNuke und Linux. Wählen Sie zunächst das PostNuke-Topic aus. Wir werden in einem der nächsten Abschnitte genauer erläutern, was es mit den Topics auf sich hat. 5. Wählen Sie die zur Zeit einzig mögliche Kategorie Beiträge aus. Auch hier wird einer der nächsten Abschnitte Aufschluss über diese Einstellmöglichkeit geben. 6. Möchten Sie den Artikel direkt auf Ihrer Startseite angezeigt bekommen? Dann wählen Sie auf der Startseite – ja. 7. Wenn es Besuchern Ihrer Seite erlaubt sein soll, Kommentare zu diesem Artikel zu verfassen, wählen Sie Kommentare erlauben – ja. 8. Wenn Ihre PostNuke-Installation mehrere Sprachen unterstützt und Ihr Artikel unter jeder ausgewählten Sprache angezeigt werden soll, wählen Sie Sprache – Alle. Für diesen ersten Artikel soll diese Einstellung genügen. 9. Verfassen Sie unter Beitrag Text einen kurzen Einleitungstext. Hier sollte erwähnt werden, worum es in dem folgenden Artikel geht und warum es sich lohnt, ihn zu lesen. Wenn Sie HTML-Kenntnisse haben, können Sie hier HTMLCode verwenden. Den WYSIWYG-Editor werden wir später in diesem Kapitel hinzuschalten.

40






4 Umgang mit PostNuke




Formatierungstyp – HTML vorformatiert: Zeilenumbrüche müssen hier ausschließlich über den HTML-Tag
vorgenommen werden. Diesen Formatierungstyp sollten Sie auch immer dann verwenden, wenn Sie über den WYSIWYG-Editor Artikel erstellen.




Formatierungstyp – Text (mit erlaubtem HTML): Hier führt jeder manuelle Zeilenumbruch mittels Return-Taste UND ein
zu einem Zeilenumbruch in der Anzeige des Artikels.

Bei Verwendung des WYSIWYGEditors sollte immer der Formatierungstyp „HTML vorformatiert“ verwendet werden.

10. Das Eingabefeld erweiterter Text beinhaltet den eigentlichen Artikel. Auch hier kann wieder HTML verwendet werden. Für die Formatierungstypen gilt dasselbe wie zuvor beschrieben. 11. Um ein Gefühl für die Aufteilung in Beitrag Text und erweiterter Text zu bekommen, schauen Sie sich die Seite http://www.spiegel.de an. Auch hier unterteilen sich sämtliche Artikel in eine Kurzeinleitung (Beitrag Text) und dem eigentlichen Inhalt des Artikels (erweiterter Text), welcher erst durch klicken auf den mehr...-Link sichtbar wird. 12. Der Inhalt des Feldes Anmerkung wird bei der Anzeige unter dem Artikel kursiv dargestellt. Das Feld kann zum Beispiel für Quellangaben genutzt werden. 13. Wenn Sie den Artikel zu einem gewissen Zeitpunkt auf der Homepage erscheinen lassen wollen, programmieren Sie den Erscheinungszeitpunkt. Sinnvoll ist solch eine Funktion beispielsweise für Artikel, die zu Weihnachten oder Silvester erscheinen sollen. Eine andere Anwendung findet sich im Bereich Investor Relations einer Firma. Hier ist es sehr wichtig, bestimmte Nachrichten genau ab einem bestimmten Zeitpunkt erscheinen zu lassen, z.B. zum Termin einer Hauptversammlung. Als Administrator haben Sie jetzt die Möglichkeit, Ihren erstellten Artikel vor dem Erscheinen auf der Homepage noch einmal anzuschauen oder diesen sogar sofort freizugeben. Wir nutzen unser Admin-Privileg und geben unseren Artikel sofort frei. Nach dem Wechsel auf die Startseite sehen wir unseren ersten eigenen Artikel. Wenn wir zur Ansicht des Artikels wechseln (durch Klick auf weiterlesen...), dürfen wir diesen auch wie-

4.8 Content-Pflege: Den ersten Artikel erstellen






41

der editieren oder sogar löschen. Sobald die Änderungen gespeichert sind, sind diese den Besuchern Ihrer Seite verfügbar.

4.8.2 Als Benutzer Autoren sind Benutzer mit erweiterten Rechten zur Artikel-Erstellung

Um als Autor einen Artikel zu erstellen, gehen Sie dazu wie folgt vor: 1. Loggen Sie sich als Benutzer im System ein, z.B. mit dem eben erstellten Benutzer mueller. 2. Klicken Sie im linken Bereich der Seite – dem HauptmenüBlock – unter dem Unterabschnitt Modules auf den Link Beiträge einreichen. 3. Als Benutzer darf man „nur“ Artikel-Attribute wie Titel, Topic, Sprache, Text und erweiterter Text pflegen. 4. Der Artikel kann erst nach einer Vorschau zur Freigabe versendet werden. Der Artikel ist damit noch nicht im Portal verfügbar, auch nicht über die Suchmaschine des CMS. Dazu muss der Administrator ihn erst freigeben.

4.8.3 Freigabe von Artikeln Um von Benutzern erstellte Artikel freizugeben, gehen Sie wie folgt vor: Abb. 4.6: Der Wartend-Block: Hier wartet Content auf Freigabe

1. Loggen Sie sich als Administrator im System ein. 2. Sind nicht freigegebene Artikel im System vorhanden, erscheint auf der linken Seite ein Block namens wartend, über den Sie zum Freigabe-Dialog gelangen. 3. Der Artikel kann hier vom Administrator noch einmal nachbearbeitet und anschließend freigegeben werden.

42






4 Umgang mit PostNuke

4.9 Einrichtung einer echten Autoren-Gruppe Die Anforderung unserer fiktiven Firma verlangt, dass unterschiedliche Berechtigungen für Administratoren, für Autoren und „normale“ Benutzer des Systems festgelegt werden sollen.


Besucher der Internet-Seite




Benutzer: Benutzer dürfen nur lesend auf das Portal zugreifen, also keinen Content erstellen. Diese Gruppe wird z.B. für Praktikanten verwendet.




Autoren: Autoren besitzen zusätzlich das Recht, Artikel zu erstellen und zu bearbeiten, dürfen diese aber nicht freigeben oder löschen und haben darüber hinaus keine administrativen Aufgaben zu erfüllen. Unser Benutzer mueller wird also in die Gruppe der Autoren wechseln.




Administratoren: diese sollen nach wie vor PostNuke in vollem Umfang administrieren dürfen.

Um diese Anforderungen umzusetzen, müssen Sie als Admin zunächst eine neue Gruppe Autoren erzeugen, zu der Sie den Benutzer mueller zuordnen müssen. Der Benutzer gehört damit zur Users- und zur Autoren-Gruppe. Beide Vorgänge – das Erzeugen der Gruppe als auch die Benutzer-Zuordnung – führen Sie im Modul Gruppen durch, welches sich unter Administration – Gruppen findet. Wechseln Sie nun in die Administration des Moduls Zugriffsrechte (im linken Bereich der Seite – dem Hauptmenü-Block – unter dem Link Administration - Zugriffsrechte). Der Gruppe Users muss jetzt das Recht genommen werden, Inhalte dem Portal hinzufügen zu dürfen. Dazu müssen Sie die dritte Berechtigungs-Regel Gruppe: Komponente: Instanz: Berechtigung:

Die Verwendung der Begriffe „Stories-Modul“ und „NewsModul“ ist synonym und bezeichnet immer das „News“Modul. Das Modul „AddStory“ ist für Admins, „Submit News“ für Benutzer gedacht.

Users .* .* kommentieren

abändern auf Gruppe:

Users

4.9 Einrichtung einer echten Autoren-Gruppe






43

Komponente: .* Instanz: .* Berechtigung: lesen Die Berechtigung „kommentieren“ reicht aus, um Inhalte erzeugen zu dürfen. Das Recht „lesen“ verhindert dies. Damit können jetzt Praktikanten problemlos der Gruppe Users hinzugefügt werden. Im Anschluss daran erzeugen Sie eine neue Gruppenberechtigung für die Gruppe der Autoren, die folgendermaßen aussieht: Gruppe: Komponente: Instanz: Berechtigung:

Autoren (Stories::.*)|(Submit news::) .* editieren

Diese Regel erteilt allen Benutzern der Autoren-Gruppe im Stories- oder Submit-News-Modul Editieren-Rechte. Mit dem Recht „Editieren“ kann ein Autor auch Kategorien editieren.




(Stories::.*)|(Submit news::) Recht gilt für alle Bereiche aus dem Stories-Modul oder für das gesamte Submit News-Modul




.* Recht gilt für alle konkreten Objekte dieser Module, also z.B. für alle Artikel oder Kategorien.

Achten Sie darauf, dass die neu erzeugte Berechtigung, die jetzt am Ende der Liste erscheint, unbedingt VOR dem Eintrag Users|.*|.*|lesen angeordnet wird. Abb. 4.7: Die Gruppenrechte unter Administration – Zugriffsrechte

Grund: In PostNuke werden Rechte von oben nach unten abgearbeitet Trifft eine Regel für einen Bereich zu, wird für diesen Bereich keine weitere Regel ausgewertet. Sollen also die Autoren für einen

44






4 Umgang mit PostNuke

Bereich andere Rechte als die Gruppe Users erhalten, müssen die Rechte erst den Autoren gewährt und dann den Users entzogen werden. Das Zugriffsrechte-Konzept ist sehr mächtig. Für Details sei daher auf das Kapitel Sicherheit verwiesen.

4.10 Topics Topics (zu deutsch „Themen“) bieten die Möglichkeit, Artikel in Themenbereichen zusammenzufassen. Nach einer Installation sind nur die beiden Topics „PostNuke“ und „Linux“ vorhanden. Für eine Webseite mit Artikeln über Linux und den Betrieb von PostNuke mag das ausreichen, im Falle unserer fiktiven Firma jedoch nicht. Nehmen wir daher an, dass Besucher Ihrer Seite zielgerichteter auf interessante Informationen geleitet werden sollen: ein Topic „Presse“ soll eingerichtet werden. Andere Topics wären „Service“, „Jobs“, „Produkte“, „Über uns“, „Investor Relations“ u.a. Gehen Sie wie folgt vor: 1. Loggen Sie sich als Administrator im System ein. 2. Klicken Sie im linken Bereich der Seite – dem HauptmenüBlock – auf den Link Administration. 3. Klicken Sie auf das Icon Topics. 4. Im Bereich neues Topic hinzufügen müssen nun die gewünschten Werte eingegeben werden:


Topic Name: Der Topic-Name wird intern verwendet, beispielsweise bei der Rechtevergabe. Prinzipiell kann er beliebig gewählt werden, im Interesse der Übersichtlichkeit sollte er aber dem Topic-Text angepasst sein. Hier wird zwischen Groß- und Kleinschreibung unterschieden, geben Sie daher am besten presse ein.




Topic-Text: Der Topic-Text ist für die Besucher an mehreren Stellen sichtbar, beispielsweise im Titel eines Artikels oder auf der Suchseite. Er sollte daher aussagekräftig und selbstbeschreibend sein. Geben Sie hier Presse ein.

4.10 Topics






45




Topic Bild: Optional können Sie ein Bild angeben, das je nach Theme zusätzlich zum Artikel angezeigt wird (jedoch nicht im ExtraLite-Theme).

5. Ein Klick auf Topic hinzufügen und Sie sind fertig. Jetzt können Artikel auch in diesen Themenbereichen erzeugt werden.

4.11 Kategorien Topics gelten systemweit auch in anderen Modulen, Kategorien gelten nur im StoriesModul.

Kategorien stellen im Stories-Modul eine zusätzliche Strukturierung von Artikeln dar und ermöglichen es dem Administrator, Artikel nach anderen Gesichtspunkten als nach Topics zu gruppieren. Kategorien wären beispielsweise „Artikel“, „Exklusiv-Bericht“, „Frisch eingetroffen“, „2005“, „wichtig“ o.ä., Bereiche also, die in jedem Topic verwendet werden könnten. Im weitesten Sinne dienen Themen der vertikalen, Kategorien der horizontalen Gruppierung von Artikeln. Um Kategorien zu definieren, gehen Sie wie folgt vor: 1. Loggen Sie sich als Administrator im System ein. 2. Klicken Sie im linken Bereich der Seite – dem HauptmenüBlock – auf den Link Administration.

Wird eine Kategorie gelöscht, können auch alle der Kategorie zugehörigen Artikel gelöscht oder in eine andere Kategorie verschoben werden.

3. Klicken Sie auf das Icon Beitrag hinzufügen. 4. Neben der Dropdown-Listbox Kategorie befinden sich die Links zur Kategorie-Administration. Wählen Sie hinzufügen. Folgende Informationen müssen Sie nun angeben:


Kategorie-Name: beispielsweise „2005“.




Theme überlagern: Ggf. ein Theme, das für diese Kategorie genutzt werden soll. Wählen Sie hier zunächst „Theme nicht überlagern“. Damit erscheint der Beitrag im standardmäßig eingestellten Theme „ExtraLite“.

5. Über sichern legen Sie die Kategorie an.

46






4 Umgang mit PostNuke

4.12 Wiki Eine alternative Möglichkeit, Texte mit Textauszeichnungen zu versehen, ist die Verwendung von Wiki-Syntax (wiki = hawaiianisch für „einfach“). Hier werden Textstellen mittels einfacher Regeln – meist durch das Einschließen in bestimmte Zeichenfolgen – später bei der Ausgabe kursiv oder fett gedruckt. Sie geben die sogenannten Wiki-Codes einfach mit dem Text ein. Die Vorschau-Funktion eines Artikels zeigt bereits das endgültige Erscheinungsbild.

4.12.1 Aktivierung von Wiki Hierzu müssen Sie unter Administration - Module in der Liste der vorhandenen Module auf den Link editieren des News-Moduls klicken und dort die Checkbox Aktiviere Wiki für dieses Modul selektieren (Stichwort: Hooks; diese werden gleich erläutert). Für jedes andere Modul gilt dieser Mechanismus analog.

Die Aktivierung von Wiki macht nur bei Modulen Sinn, in denen Sie Texte pflegen können.

4.12.2 Grundlegende Formatierungen (Wiki-Syntax) Erstellen Sie einfach einen neuen Artikel und geben Sie beispielsweise ___Hallo___ ein. Dabei ist es unerheblich, ob Sie TypeTool verwenden oder nicht. Auch der Formatierungstyp spielt keine Rolle. PostNuke sollte den Begriff Hallo nach der Speicherung des Artikels fett gedruckt darstellen. Weitere Formatierungsmöglichkeiten sind: Zeilenumbruch: Trennlinie: Kursiv: Fett: Fett-kursiv:

%%% ---__kursiv__ ___fett___ _____fkursiv_____

3 x Prozent 4 x Bindestrich 2 x Unterstrich 3 x Unterstrich 5 x Unterstrich

Auch beim Einfügen von Links ist die Wiki-Systax hilfreich. Eingeschlossen in eckige Klammern wird beispielsweise bei der Eingabe von [http://www.postnuke.de] oder [Postnuke.de|http:// www.postnuke.de] ein Link zu dieser Seite erzeugt, im zweiten Fall

4.12 Wiki






47

wird dazu der Text „Postnuke.de“ verlinkt. Links zu Bilddateien führen dazu, dass dieses Bild in den Text eingefügt wird. Mit [http://www.google.de/logos/Logo_60wht.gif] binden Sie beispielsweise das Google-Suchmaschinen-Logo in Ihren Artikel ein.

4.13 Hooks Eine StandardInstallation bietet Hooks der Module AutoLinks, Ratings und Wiki.

Hooks (= englisch für „Haken/einhaken“) sind Modul-Funktionen, die auf Ereignisse (Events) in anderen Modulen reagieren. Sie sind demnach Routinen, die automatisch aufgerufen werden, wenn bestimmte Ereignisse im System wie die Speicherung oder Löschung von Content o.ä. stattfinden. Das News-Modul kann beispielsweise vor der Ausgabe eines Artikels den PostNuke-Kernel um den Aufruf aller Hooks bitten, die für das News-Modul aktiviert wurden. Nehmen wir an, AutoLinks hat einen Umformungs-Hook implementiert, und AutoLinks sind für das News-Modul aktiviert. Die Hook-Routine des AutoLinks-Moduls wartet darauf, Content anderer Module entgegenzunehmen und Text gegen Links zu ersetzen, den Content also umzuformen (Transform-Hook).

Abb. 4.8: Ablauf eines HookCalls

News-Modul (Content-Anzeige)

Hook-Tabelle: News + AutoLinks

AutoLinks-Modul (Content-Transform)

PostNuke-Kernel (pnMod)

Call von Hooks mittels pnModCallHooks()

Rückgabe an Kernel

Aufruf, Weitergabe der Content-URL

Weder weiß das News-Modul, welche nachfolgenden Module per Hook-Aufruf seinen Content weiterverarbeiten, noch weiß das AutoLinks-Modul irgendetwas über das News-Modul (außer die Adresse zu dem Content, den es von diesem geliefert bekommt). Der PostNuke-Kernel kümmert sich im richtigen Moment um das Zusammenschalten und die Koordination. Damit sind Hooks eine sehr elegante und flexible Möglichkeit, Module miteinander zu verheiraten.

48






4 Umgang mit PostNuke

Mit dieser auch im Windows-Umfeld weit verbreiteten Technologie wird eine Zusammenarbeit zwischen Modulen ermöglicht, ohne dass sich die Module explizit untereinander kennen oder für einander entwickelt sein müssen. Nicht alle Module nutzen Hooks bei allen Ereignissen, und nicht alle Module stellen Hooks für alle Ereignisse zur Verfügung. Es ist immer Sache des Modul-Entwicklers, Funktionen seines Moduls per Hook auch anderen Modulen zur Verfügung zu stellen. Dagegen gehört es zum guten Stil der PostNuke-Modulprogrammierung, an entsprechenden Stellen im eigenen Modulcode die passenden Hooks im System aufzurufen. Wann genau welcher Hook aufgerufen wird, ob zum Beispiel sofort nach dem Auslesen aus der Datenbank oder erst kurz vor der Darstellung eines Artikels, ist Sache des Modulentwicklers. Die Hook-Konfiguration findet sich in der Administration der Module. Ist unter Administration – Module – News – editieren der Hook für AutoLinks aktiviert, wird jeder NewsArtikel nach dessen Generierung und vor dessen Ausgabe durch das AutoLinks-Modul manipuliert. Sie können dies testen, in dem Sie den AutoLinks-Hook für das News-Modul aktivieren, im AutoLinks-Modul einige Schlagwörter mit Verlinkung anlegen und anschließend einen News-Artikel mit diesen Schlagwörtern erstellen. Gehen Sie dazu wie folgt vor: 1. Autolinks aktivieren: Klicken Sie im linken Bereich der Seite – dem Hauptmenü-Block – auf den Link Administration. 2. Klicken Sie auf das Icon Module. 3. Klicken Sie beim Modul News auf den Link editieren. 4. Aktivieren Sie die Checkbox Aktiviere für dieses Modul.

AutoLinks

AutoLinks sind nicht casesensitiv (nicht abhängig von Groß/Kleinschreibung)

5. Autolinks anlegen: Klicken Sie im linken Bereich der Seite – dem Hauptmenü-Block – auf den Link Administration. 6. Klicken Sie auf das Icon AutoLinks, dann auf AutoLink hinzufügen. 7. Erstellen Sie einen Eintrag mit dem Schlüsselwort „PostNuke“, dem Titel „zur PostNuke Homepage“ und der URL „http://www.postnuke.com“. 8. Erstellen Sie einen neuen News-Artikel, der den Begriff „PostNuke“ enthält.

4.13 Hooks






49

9. Sobald der Artikel freigegeben ist, wird das Wörtchen „PostNuke“ vor der Anzeige automatisch mit einem AutoLink ersetzt. Für weitere Details zu Hooks sei auf das Kapitel Die PostNukeProgrammierung verwiesen.

4.14 Zusammenfassung Sie haben einen Gesamtüberblick über PostNuke erhalten und sind mit allen relevanten Teilen in der Bedienung und Administration in Berührung gekommen. Jetzt sind Sie in der Lage, PostNuke auf eigene Faust weiter zu erkunden.

4.15 Ausblick Als nächstes werden Sie mit der Absicherung Ihres Systems vertraut gemacht. Das beinhaltet die Konfiguration Ihrer Server-Umgebung und geht bis zur Einrichtung von Berechtigungen im PostNukeSystem.

50






4 Umgang mit PostNuke

5 Sicherheit

Die Absicherung eines PostNuke-Systems beginnt wie immer an der Basis – bei Hardware und Betriebssystem. Eine PostNukeInstallation kann nur so sicher wie die dahinter liegende Infrastruktur sein. Als Grundvoraussetzung für alle hier vorgestellten Schritte gilt, dass unberechtigte Dritte keinerlei Zugriff auf die vorgestellten System- oder Konfigurationsdateien erhalten dürfen. Für unberechtigte Benutzer sollen diese weder schreibbar noch lesbar sein.

5.1 PHP Die Absicherung von PHP erfolgt hauptsächlich über die Konfigurationsdatei php.ini und wird in der Regel vom Provider durchgeführt. Wichtige Einstellungen sind:


register_globals = On, Off: Legt fest, ob an ein PHP-Skript übergebene Variablen global verfügbar sein sollen. Wenn Sie diese Option einschalten, geben Sie einem böswilligen Benutzer die Gelegenheit, beliebige Variablen mit beliebigen Werten zu definieren. Dazu werden nicht einmal spezielle Werkzeuge benötigt, ein normaler Webbrowser reicht. Empfehlung: unbedingt deaktivieren.




display_errors = On, Off: Legt fest, ob Fehlermeldungen im Webbrowser angezeigt werden. Für die Entwicklung von PostNuke-Komponenten ist diese Funktion sinnvoll, im produktiven Einsatz eher störend. Empfehlung: deaktivieren.




log_errors = On, Off: Legt fest, ob Fehler in Logdateien des Webservers eingetragen werden. Vor allem im Zusammenspiel mit der vorhergehenden Option sinnvoll, damit auftretende Fehler nachvollziehbar bleiben. Empfehlung: aktivieren.

5.1 PHP






51

Um Probleme von vornherein zu vermeiden, sollten post_max_size und upload_max_filesize auf den gleichen Wert gesetzt werden.




post_max_size = Megabyte: Maximalgröße einer POSTAnfrage. Wird dieser Wert überschritten, erfolgt ein Abbruch der Verbindung. Auf diese Weise lassen sich Denial of Service (DoS)-Angriffe einschränken.




file_uploads = On, Off: Legt fest, ob Dateien bei POSTAnfragen übertragen werden können.




upload_max_filesize = Megabyte: Maximalgröße einer Datei in einer POST-Anfrage. Wird dieser Wert überschritten, erfolgt ein Abbruch der Verbindung.

Die nächsthöhere Stufe der Absicherung ist der sogenannte „Safe Mode“ von PHP. Dieser zeichnet sich vor allem durch eine strengere Prüfung von Dateisystemberechtigungen aus. Beispielsweise wird der Zugriff auf Dateien verweigert, die anderen Benutzern als demjenigen gehören, der PHP ausführt. So ist z.B. die Manipulation durch das Ersetzen von Dateien wesentlich erschwert. Konfiguriert wird der Safe Mode über einige Optionen in der php.ini:


safe_mode = On, Off: Legt fest, ob der Safe Mode aktiv ist oder nicht. Empfehlung: aktivieren.




safe_mode_gid = 0, 1: Wenn die Option aktiviert (= 1) ist, wird bei Zugriffen auf das Dateisystem nur die Gruppenzugehörigkeit des Benutzers, der das PHP-Skript ausführt, geprüft.




safe_mode_include_dir = Verzeichnis: Innerhalb des angegebenen Verzeichnisses inkl. Unterverzeichnisse werden bei include() und require()-Befehlen die Benutzer- und Gruppenzugehörigkeit von Dateien nicht mehr geprüft.




safe_mode_exec_dir = Verzeichnis: Ist diese Option gesetzt, können mit Funktionen wie system() oder exec() nur noch Programme im angegebenen Verzeichnis ausgeführt werden.




open_basedir = Verzeichnis: Diese Einstellung wird mit zum Safe Mode gerechnet, wirkt sich aber auch aus, wenn dieser abgeschaltet ist. Ist ein Verzeichnis angegeben, dann können mit Funktionen wie fopen() nur noch dort und in Verzeichnissen unterhalb davon Dateien geöffnet werden.

Eine weiteres Sicherheitsrisiko stellen Umgebungsvariablen dar, über die man beispielsweise die Ausführung von Systemfunktionen

52






5 Sicherheit

beeinflussen kann. Mit folgenden Einstellungen kann der Zugriff darauf kontrolliert werden:


safe_mode_allowed_env_vars = beliebige Umgebungsvariablen bzw. deren Präfixe, durch Komma getrennt: Legt fest, welche Umgebungsvariablen geändert werden dürfen. Wird z.B. PHP_ angegeben, dann dürfen nur Variablen geändert werden, deren Name mit PHP_ beginnt.




safe_mode_protected_env_vars = beliebige Umgebungsvariablen, durch Komma getrennt: Das Gegenteil zu safe_mode_allowed_env_vars. Hier aufgeführte Variablen dürfen nicht geändert werden. Diese Einstellung hat Vorrang gegenüber safe_mode_allowed_env_vars.




disable_functions = beliebige PHP-Funktionen, durch Komma getrennt: Verhindert den Einsatz der angegebenen PHP-Funktionen, egal ob der Safe Mode aktiv ist.

Im praktischen Einsatz kommt man oft bei Internet-Providern und Web-Hostern mit dem PHP Safe-Mode in Kontakt. Wenn Probleme beim Betrieb eines PostNuke-CMS auf PHP-Ebene auftauchen, dann meist weniger mit dem Safe Mode, sondern mehr mit Dateiund Verzeichnisberechtigungen.

5.2 Apache Dateien, die zum Webserver gehören, sowie dessen Konfiguration dürfen durch Dritte nicht veränderbar sein. Beim Zugriff per HTTP dürfen nur Daten ausgeliefert werden, die dafür auch wirklich vorgesehen sind. Für die Absicherung von Apache Webserver gegen Angriffe auf Dateisystemebene ist es wichtig zu wissen, welche Dateien im normalen Betrieb geschrieben und gelesen werden. Zunächst sind das die ausführbaren Dateien, die Apache-Programmdatei, die einzelnen Apache-Module und die Hauptkonfigurationsdatei httpd.conf. Diese Dateien sollten sich an Orten befinden, auf die nur Administratoren oder Benutzer mit entsprechenden Rechten Zugriff haben – dies ist üblicherweise nach einer Standardinstallation auf Serverplattformen der Fall.

5.2 Apache






53

Bei der Vergabe von Zugriffsrechten muss sichergestellt werden, dass alle betreffenden Verzeichnisse und Dateien mit korrekten Zugriffsbeschränkungen ausgestattet werden.

Außerdem kann in jedem Verzeichnis unterhalb der Document Root eine sogenannte .htaccess-Datei liegen, die meist Direktiven zur Absicherung von Dateien und Verzeichnissen enthält. Es sei nur ein kleines Beispiel gezeigt. Für weitergehende Dokumentation schauen Sie sich die Dokumentation zum Apache Webserver an. Mit einem Eintrag in einer .htaccess wie Order deny,allow Deny from all Allow from 213.178.172 wird festgelegt, dass die Datei postnuke/html/admin.php nur von Maschinen zugreifbar ist, die eine IP-Adresse aus dem Bereich 213.178.172 besitzen. Damit kann die Administrationsoberfläche von PostNuke nur von bestimmten physikalischen Maschinen aufgerufen werden. Zusätzlich zur Kontrolle über IP-Bereiche (oder als Alternative, falls dies nicht praktikabel ist) kann als Bestandteil von HTTP auch eine Zugangskontrolle auf der Basis von Benutzernamen und Passwörtern erfolgen (eine so genannte HTTP-Authentifizierung).

5.3 SSL Wer schon einmal ein Netzwerk-Überwachungstool (so genannte „Sniffer“) ausprobiert hat, weiß, dass vertrauliche Daten wie Benutzername oder Passwörter mit HTTP im Klartext übertragen werden. SSL (Secure Socket Layer) verschlüsselt die Datenübertragung zwischen Webbrowser und Webserver durch eine Verschlüsselung names RSA. Die Stärke der Verschlüsselung ist variabel und beträgt heutzutage meist mindestens 128 Bit. Wenn Sie einen PostNuke-Webserver betreiben möchten, der SSL beherrscht, benötigen Sie ein SSL-Zertifikat, welches von Firmen wie VeriSign ausgestellt werden kann. Da dies mit nicht unwesentlichen Kosten verbunden ist, haben Sie auch die Möglichkeit, mit Tools wie openssl eigene Zertifikate zu erzeugen. Die selbsterzeugten Zertifikate haben allerdings den Nachteil, dass diese von

54






5 Sicherheit

Browsern standardmäßig als nicht vertrauenswürdig eingestuft werden. Verwechseln Sie eine abhörsichere SSL-Verbindung zwischen Browser und PostNuke-Server nicht mit Techniken wie IPSec oder PGP. IPSec wird meist als Richtlinien-Protokoll in VPN-Umgebungen verwendet, um exklusive Tunnel über unsichere InternetVerbindungen zu realisieren. VPN-Techniken würde man einsetzen, um einen im privaten Firmennetz angesiedelten PostNuke IntranetServer über das Internet erreichen zu können. Die Kommunikation ist dabei immer verschlüsselt und nur von bestimmten Benutzern nutzbar. PGP ist ein Standard u.a. zur Verschlüsselung von E-Mails und kommt im PostNuke-Umfeld daher nicht zum Einsatz.

Informationen zu SSL und zur Zertifikatserzeugung finden Sie auf openssl.org

Durch die verwendete leistungsfähige Standard-Softwarebasis wie Webserver, Netzwerk-Betriebssysteme, Datenbankserver o.ä. werden natürlich auch Sicherheitskonzepte wie geschützter Zugang per VPN, Failover durch Hot- und Cold-Standby, Clustering und weitere Techniken unterstützt. Generell gilt: je leistungsfähiger Ihre Sicherheits-Infrastruktur, desto besser für PostNuke – es kann davon nur profitieren.

5.4 Berechtigungen und Zugriffsrechte in PostNuke Zurück zu PostNuke. Über Administration – Zugriffsrechte gelangen Sie in die Administration der Berechtigungen für Benutzer und Gruppen. Jeder Block und jedes Modul veröffentlicht seine individuellen Berechtigungen im Zugriffsrechte-Modul – da jedes Modul natürlich andere Aufgaben wahrnimmt. Im Rechte-Modul werden diese Berechtigungen mit Benutzern und Gruppen verknüpft. Gleichzeitig gibt man an, welche Art von Zugriff – von keinem Recht bis zum Administrations-Recht – für die erstellten Berechtigungen gefordert ist. Damit entstehen Zugriffsregeln. Es ist dann wieder Sache des betroffenen Blocks oder Moduls, die Regeln zu interpretieren und korrekt umzusetzen.

5.4 Berechtigungen und Zugriffsrechte in PostNuke






55

Letzten Endes bedeutet das: es ist Sache des Programmierers, in „seinem“ Modul/Block auf Berechtigungen zu prüfen. Daher ist jedes Modul unterschiedlich „sicher“ und bietet unterschiedliche Ebenen der Zugriffssteuerung. Mit den Modulen im Standard-Paket können Berechtigungen jedoch effektiv genutzt werden.

5.4.1 Grundlagen Anhand des News-Moduls werden einige notwendige Begriffe aus dem Zugriffsrechte-Modul erläutert. Eine Berechtigung bzw. eine Regel besteht immer aus vier Teilen: 1. Für welche Gruppe oder Benutzer gilt diese Regel? 2. Für welches Modul oder für welchen Block gilt diese Regel? Man kann sogar Unterbereiche in einem Modul oder Block verwenden. Diesen Teil der Regel nennt man Komponente. 3. Für welche konkreten Inhalte im Modul oder Block gilt diese Regel? Diesen Teil der Regel nennt man Instanz. 4. Welche Art des Zugriffs ist erlaubt? Für die Angabe von Komponenten und Instanzen lassen sich reguläre Ausdrücke verwenden. Ein Ausdruck der Art (Stories::.*)|(Submit news::) definiert zwei Gruppen von Komponenten, die mit booleschem ODER verknüpft sind. Das Wildcard .* dient als Platzhalter für beliebigen Text, womit in diesem Fall alle Bereiche im News-Modul gemeint sind. Die Angaben, welches Modul welche Komponenten und Instanzen anbietet, finden sich als tabellarische Auflistung in einem PopUp-Fenster, erreichbar im Zugriffsrechte-Modul bei Klick auf die Links Komponente bzw. Instanz. Ein initialisiertes Modul – egal, ob aktiviert oder deaktiviert – bietet alle Komponenten und Instanzen für sich und seine Blöcke

56






5 Sicherheit

dem Zugriffsrechte-Modul an. Ein nicht initialisiertes Modul veröffentlicht dagegen keine Block-Komponenten/Instanzen.

5.4.2 Benutzer vs. Gruppen Benutzerberechtigungen werden separat von Gruppenberechtigungen gepflegt und gespeichert. Beachten Sie, dass Benutzerberechtigungen die der Gruppen überschreiben. Beispiel: Gruppe 1 hat auf Bereich A keinen Zugriff, Benutzer mueller aus Gruppe 1 wird aber per Benutzerrecht der Zugriff gewährt, so hat der Benutzer mueller Zugriff auf Bereich A. Nutzen Sie Benutzerberechtigungen nur, wenn Sie mit Gruppenberechtigungen nicht auskommen.

5.4.3 Zugriffsarten/Stufen PostNuke kennt neun verschiedene Stufen von Zugriffen, die aufeinander aufbauen. 1. Keines (ACCESS_NONE): kein Zugriff auf Content wie z.B. Artikel oder Downloads. 2. Übersicht ACCESS_OVERVIEW): erlaubt eine Auflistung von Content, also beispielsweise die Anzeige einer Übersicht über alle Artikel. Ein Artikel selbst kann nicht aufgerufen werden. 3. Lesen (ACCESS_READ): erlaubt Übersicht + die detaillierte Ansicht von Content. Ein Artikel darf also zusätzlich komplett gelesen werden. 4. Kommentieren (ACCESS_COMMENT): Lesen + Abgabe von Kommentaren zu Content. 5. Moderieren (ACCESS_MODERATE): Kommentieren + Verwaltung der Kommentare. 6. Editieren (ACCESS_EDIT): Moderieren + komplette Bearbeitung von bereits bestehendem (!) Content möglich. Ermöglicht beispielsweise auch das Löschen von Teilen eines Artikels. Ein Artikel kann allerdings nicht komplett gelöscht werden.

5.4 Berechtigungen und Zugriffsrechte in PostNuke






57

7. Hinzufügen (ACCESS_ADD): Editieren + Erstellung (und Freigabe) von neuem Content ist möglich. Content darf immer noch nicht als Ganzes gelöscht werden, auch eigener Content nicht. 8. Löschen (ACCESS_DELETE): Hinzufügen + Content darf gelöscht werden. 9. Administrieren (ACCESS_ADMIN): ermöglicht die Administration von Modulen und Blöcken. Höchstes und uneingeschränktes Zugriffsrecht.

5.4.4 Abarbeitungsreihenfolge Berechtigungs-Regeln werden von PostNuke von oben nach unten abgearbeitet. Trifft eine Regel auf eine Komponente und deren Instanz zu, wird diese angewendet. Folgt eine Regel, die ebenfalls auf die gleiche Komponente/Instanz zutreffen würde, wird diese nicht mehr angewendet. Angenommen, ein Benutzer ist gleichzeitig Mitglied in den beiden Gruppen „Gruppe1“ und „Gruppe2“. Für beide Gruppen sei jeweils eine Regel definiert, die bei der einen den Zugriff auf das News-Modul erlaubt und bei der anderen entzieht. Je nach dem, welche Regel in der Abarbeitungs-Hierarchie zuerst angeordnet ist, hat der Benutzer Zugriff auf das News-Modul – oder auch nicht. Benutzer hat keinen Zugriff: 1. Regel Gruppe: Komponente: Instanz: Berechtigung:

Gruppe1 Stories::.* .* keines

2. Regel Gruppe: Komponente: Instanz: Berechtigung:

Gruppe2 Stories::.* .* hinzufügen

Benutzer hat Zugriff

58






5 Sicherheit

1. Regel Gruppe: Komponente: Instanz: Berechtigung:

Gruppe2 Stories::.* .* hinzufügen

2. Regel Gruppe: Gruppe1 Komponente: Stories::.* Instanz: .* Berechtigung: keines Die sequentielle Abarbeitungsreihenfolge erzwingt damit das Prinzip: soll ein Zugriff eingeschränkt werden, müssen erst Rechte entzogen, dann gewährt werden. Das System ist extrem mächtig, hat aber den Nachteil: je mehr Regeln, desto komplexer die richtige Handhabung der Reihenfolge, potenziert mit der Anzahl von Gruppen und Benutzern. Daher: 1. Ein Benutzer sollte so wenigen Gruppen wie möglich angehören. 2. Wenn ein Benutzer in mehreren Gruppen Mitglied ist, dann sollten die Berechtigungen der Gruppen keine gemeinsamen Bereiche betreffen. 3. Es bietet sich an, für Bereiche, die von allen Benutzern genutzt werden sollen, Rechte über eine gemeinsame Gruppe zu definieren. Dafür bietet sich die Gruppe „Users“ an. 4. Alle speziellen Rechte sollten über separate Gruppen realisiert werden. Damit macht es auch Sinn, wenn jeder neu angelegte Benutzer automatisch Mitglied der Gruppe „Users“ wird (siehe Einstellung unter Administration – Einstellungen – StandardGruppe für Benutzer).

Tipp: benennen Sie nie die Gruppen „Admins“ und „Users“ um. Es könnte Auswirkungen auf viele Bereiche Ihres Systems haben.

5.4.5 Anwendung Mit den Regeln sind Sie schon im vorigen Kapitel kurz in Berührung gekommen. Das Beispiel soll erweitert werden. Angenommen, Sie haben eine Artikel-Kategorie „intern“ angelegt, in der alle ge-

5.4 Berechtigungen und Zugriffsrechte in PostNuke






59

heimen Artikel des Unternehmens abgelegt werden. Praktikanten sollen daher auf diese Kategorie nicht mehr zugreifen dürfen. Sie haben Berechtigungen falsch gesetzt und Ihr System damit unbenutzbar gemacht? PSAK schafft Abhilfe (siehe Kapitel Troubleshooting, Backup und Recovery)

Auch wenn es sinnvoll wäre, so langsam eine eigene Gruppe „Praktikanten“ zu definieren, wird das Beispiel der Einfachheit halber auf die Gruppe „Users“ angewendet. Das News-Modul registriert die Komponente Stories::Story mit der Instanz Author ID:Category name:Story ID. Diese muss verwendet werden, um die Anforderung umzusetzen. Man könnte zwar auf die Idee kommen, die Komponente Stories::Category zu verwenden – sie regelt jedoch nur, ob bei der Pflege eines Artikels Kategorien angelegt, editiert oder gelöscht werden dürfen. Der Regelsatz muss daher so aussehen:

Abb. 5.1:Die Berechtigungen des Beispiels

Die Komponente ist immer fest vorgegeben, die Instanz ist variabel.

5.4.6 Die Auswertung des Regelsatzes Ist ein Praktikant eingeloggt und kennt er einen Link zu einem internen Artikel, wird Regel 2 und Regel 4 ausgeführt. Keine weitere Regel trifft auf die Situation zu. Regel 4 verweigert ihm wie gewünscht den Zugriff. Wählt er für ihn erlaubte Artikel aus, wird Regel 4 nicht abgearbeitet und Regel 5 schlägt stattdessen zu – er bekommt Leserechte. Leider gibt es noch ein Problem in der jetzigen Rechtekonfiguration. Wenn sich der Praktikant abmeldet, sieht er dennoch alle inter-

60






5 Sicherheit

nen Artikel. Daran ist Regel 7 schuld, da sie allen unregistrierten Benutzern Lesezugriff auf alle Bereiche erteilt. Sie müssen jetzt also noch der unregistrierten Gruppe alle Rechte auf die internen Artikel entziehen. Da das Prinzip gilt „erst Rechte entziehen, dann Rechte gewähren“, muss die neue Regel vor Regel 7 eingefügt werden. Sie hat das gleiche Aussehen wie die Regel 4 und unterscheidet sich nur im Gruppennamen. Abb. 5.2: Der korrekte Regelsatz

5.5 Allgemeine PostNuke Sicherheitstipps Hier gilt das, was für alle Anwendungen gilt:


Informieren Sie sich regelmäßig auf http://www.postnuke.com oder http://www.post-nuke.net über mögliche Sicherheitslecks.




Halten Sie Ihre PostNuke-Installation auf dem neuesten Stand. Machen Sie die Release-Wechsel mit.




Wechseln Sie die Passwörter der Admins und der Benutzer regelmäßig.




Pflegen Sie Ihre Benutzer und Gruppen: entfernen Sie nicht mehr benötigte Benutzer und Gruppen und löschen Sie in den Gruppen auch nicht richtig zugeordnete Benutzer.




Installieren Sie so wenig Module aus dritter Hand wie möglich. Oder informieren Sie sich auf http://www.post-nuke.net über sinnvolle und empfohlene Module Dritter. Schauen Sie auch einmal in deren Source-Code, wenn möglich: werden Eingaben abgesichert? Werden Rechte geprüft? Sehen Sie bei schlechtem Code von einem Einsatz ab.

5.5 Allgemeine PostNuke Sicherheitstipps






61




Deaktivieren Sie alle Blöcke und Module, die Sie nicht benötigen (einen Anhaltspunkt, was alles deaktiviert und deinstalliert werden darf, gibt Ihnen das Kapitel pnmini). Es macht Ihre Seite nicht nur weniger anfällig für mögliche Sicherheitslücken in den einzelnen Modulen, sondern auch noch schneller.




Überprüfen Sie anschließend das PostNuke-Rechtesystem. Stimmen alle Regeln noch? Gibt es die Blöcke, Module, Benutzer und Gruppen noch, die dort referenziert werden?




Denken Sie bei der Installation neuer Blöcke und Module auch immer sofort daran, dass Berechtigungssystem nachzuziehen.




Testen Sie den Zugriff auf Ihre Seite auch mit anderen Browsern, und schalten Sie dafür einmal deren Caching ab.




Für Modulentwickler: halten Sie sich unbedingt an die goldenen Regeln zur Absicherung Ihrer Module, die Sie in diesem Buch im Kapitel Die PostNuke-Programmierung finden. Damit sichern Sie beispielsweise Benutzer-Eingaben gegen Script- oder SQL-Injections ab oder verhindern, dass Daten an Ihrem Modul vorbei ins PostNuke-System geschleust werden können.




Das wichtigste zum Schluss: auch unabhängige Seiten wie SecurityFocus berichten über mögliche Sicherheitslöcher. Ein Besuch des Links http://www.securityfocus.org/search?category =2&query=postnuke&rank=&submit=Search sucht nach bekannten Vulnerabilities in PostNuke.

5.6 Zusammenfassung Die Absicherung eines Systems reicht von der Konfiguration des Webservers & PHP über die Einrichtung von SSL bis hin zur Erstellung von Regeln im Zugriffsrechte-Modul.

5.7 Ausblick Im folgenden werden alle mitgelieferten Blöcke eines PostNukeSystems alphabetisch sortiert erläutert.

62






5 Sicherheit

6 Blöcke

Für die Erstellung neuer Blöcke in der Block-Administration stellt Ihnen PostNuke 0.750 Gold folgende Typen zur Verfügung (alphabetisch sortiert): 1. Admin Messages/Show admin messages 2. Core/Button Link Block 3. Core/Categories Menu 4. Core/Custom Banner Display 5. Core/Display Poll 6. Core/Ephemerids 7. Core/FXP Currency Exchange 8. Core/Generic Menu 9. Core/HTML 10. Core/Languages 11. Core/Latest Web Links 12. Core/Online 13. Core/Past Articles 14. Core/PHP Script 15. Core/Plain Text 16. Core/RSS Extra 17. Core/RSS Newsfeed 18. Core/Search Box 19. Core/Simple File Include 20. Core/Story Related Links 21. Core/Story Titles 22. Core/Today’s Big Story

5.7 Ausblick






63

23. Core/Topics Menu 24. Core/User’s Custom Box 25. Core/User’s Login 26. pnRender/custom pnRender block 27. Quotes/Random Quote 28. Xanthia/Display module output in a block 29. Xanthia/Logo Block for Xanthia Themes Beachten Sie, dass die Dropdown-Listbox unter Administration – Blöcke – neuer Block unsortiert ist.

6.1 Admin Messages/Show Admin Messages Zeigt eine Admin-Nachricht an. Block zum gleichnamigen Modul. Siehe dazu die Beschreibung zum Modul „Admin Messages“.


PHP-Datei: modules/NSAdmin_Messages/pnblocks/blocks/messages.php




DB-Tabellen: message

6.2 Core/Button Link Block Dieser Block zeigt eine Reihe von verlinkten Grafiken untereinander angeordnet und zufällig sortiert an. Sinnvoll ist dieser Block beispielsweise, um auf Partner-Unternehmen zu verlinken (über deren Firmenlogos). Ohne die Angabe einer Grafik-URL, die ins Web oder lokal (dann in der Art „images/topics/linux.gif“) verweisen kann, lässt sich kein neuer Eintrag hinzufügen.

64









PHP-Datei: includes/blocks/button.php




DB-Tabellen: blocks_buttons

6 Blöcke

6.3 Core/Categories Menu Listet alle Kategorien auf, die Ihre Seite besitzt. Ein Klick auf die Kategorie führt dann zu einer Auflistung aller Artikel aus dieser Kategorie. Sind keine Kategorien angelegt (die Kategorie „Beiträge“ allein genügt nicht), wird der Block nicht angezeigt.


PHP-Datei: includes/blocks/category.php




DB-Tabellen: stories_cat

6.4 Core/Custom Banner Display Zeigt einen Werbebanner in einem Block an. Damit muss ein Werbebanner nicht ins Theme integriert, sondern kann vom Seitenbetreiber individuell platziert und ein- oder ausgeschaltet werden. Sie werden in der Blockkonfiguration nach einer Custom Banner ID gefragt, was nichts anderes als die ID der Kategorie darstellen soll, zu der der Banner gehört. Um Banner in einem Block nutzen zu können, benötigen diese eine Kategorie-ID >= 3 (Einzelheiten dazu finden Sie in der Beschreibung zum Banner-Modul). Wird in der Block-Konfiguration eine Custom Banner ID gesetzt, wird der Banner-Block bei jedem Reload der Seite zufällig einen Banner aus der dort angegebenen Banner-Kategorie auswählen. Wird keine ID gesetzt, geht der Block von der ID 3 aus.


PHP-Datei: includes/blocks/banners.php




DB-Tabellen: banner

6.5 Core/Display Poll Zeigt eine Umfrage an. Block zum Poll-Modul.


PHP-Datei: includes/blocks/poll.php




DB-Tabellen: poll_data, poll_desc, pollcomments

6.3 Core/Categories Menu






65

6.6 Core/Ephemerids Zeigt einen Ephemeriden-Eintrag an. Block zum EphemeridenModul. Die Erklärung zu Ephemeriden findet sich an entsprechender Stelle im Kapitel Module.


PHP-Datei: includes/blocks/ephem.php




DB-Tabellen: ephem

6.7 Core/FXP Currency Exchange FXP Currency Exchange ist ein Währungsumrechner. Nicht interaktiv, aber immerhin. Der Block bezieht seine Daten vollautomatisch aus der XML-Datei von http://www.ecb.int/stats/ eurofxref/eurofxref-daily.xml. In der Konfiguration gibt man an, von welcher Währung (Base) man in welche Währung (Quote) umrechnen möchte. Für Base und Quote müssen Sie den Namen der Währung angeben. Mit dem Beispiel für Quote = EUR und Base = USD erhält man am 06.12.2004, dass ein US-Dollar 0,74 EUR kostet.


PHP-Datei: includes/blocks/fxp.php




DB-Tabellen: -

6.8 Core/Generic Menu Generic Menu erstellt Menü-Blöcke. Menüs können auf bestimmte Sprachen festgelegt werden und als simple Auflistung oder in Dropdown-Form erscheinen. In den Eigenschaften dieses Blocks verlinkt die Checkbox Module automatisch auf die Benutzeroberfläche aller installierten Module. Ist zu prüfen aktiviert, verlinkt der Block bei Eintreffen neuen Contents zusätzlich auf deren Freigabe-Funktion. Das gilt für

66









Neue Stories/Artikel des News-Moduls




Neue Reviews

6 Blöcke




Neue Weblinks




Neue Downloads




Neue FAQs

Beispiel: Mit den Angaben „Titel: Startseite“, „URL: index.php“, „Beschreibung: Zur Startseite“ (optional) erstellen Sie einen Link, der auf die Startseite verweist.

Hinweis: Geben Sie Links immer relativ an.

Leider besitzt der Menu-Block keine Möglichkeit, einfach die Reihenfolge der Menülinks zu ändern. Das muss umständlich über Copy&Paste-Aktionen geschehen – oder Sie ändern die Menüstruktur direkt in der Datenbank, was wir allerdings nicht empfehlen. Jede PostNuke-Installation besitzt bereits einen Block namens „Main Menu“ vom Typ „Generic Menu“. Wenn Sie in die Eigenschaften dieses Blockes wechseln, fällt Ihnen auf, dass auf einige Module ganz einfach über „[ModulName]“ verlinkt wird. Als „ModulName“ muss der Verzeichnisname des Moduls angegeben werden. Eckige Klammern werden für die Verlinkung auf old-style Module verwendet. Geschweifte Klammern verwendet man für Module, die pnAPI-konform entwickelt wurden, beispielsweise „{Credits}“ für das Credits-Modul. Über „{Name:Funktion}” kann optional der Name der Funktion eingebaut werden, die im Modul aufgerufen werden soll, also z.B. „{Credits:display}“. Es ist nicht möglich, über die Verwendung von Klammern Admin-Funktionen der Module aufzurufen.


PHP-Datei: includes/blocks/menu.php




DB-Tabellen: blocks, downloads_newdownload, faq_answer, links_newlink, queue, reviews_add

6.9 Core/HTML Der HTML-Block ermöglicht Ihnen, HTML-Code jeglicher Art einzufügen. Das Ergebnis wird dann in einem Block angezeigt. Erstellen Sie einmal einen neuen HTML-Block namens „Taschenrechner“ und fügen Sie diesen HTML-Code in den Block ein:

In diesem Block funktioniert JavaScript auch bei aktiviertem pnAntiCracker.

<script language="JavaScript">

6.9 Core/HTML






67

Abb. 6.1: Ein Taschenrechner im HTML-Block

68

		6 Blöcke onClick="button('6')">
				/ " 1 " 2 " 3 " 0 " . " = " C "> 6.10 Core/Languages Gehört zum Sprachen-Modul und bietet eine Sprachauswahl an. Der Block liest die installierten Sprachpakete direkt aus dem Verzeichnis postnuke/html/language aus. 6.10 Core/Languages 69 PHP-Datei: includes/blocks/thelang.php DB-Tabellen: - 6.11 Core/Latest Web Links Dieser Block zeigt standardmäßig die zehn zuletzt eingefügten WebLinks an. Gehört zum WebLinks-Modul. PHP-Datei: includes/blocks/weblinks.php DB-Tabellen: links_links 6.12 Core/Online Dieser Block zeigt an, wie viele Mitglieder und Besucher das PostNuke-System gerade nutzen, mit welchem Namen Sie selbst angemeldet sind und ob Sie neue private Nachrichten erhalten haben. PHP-Datei: includes/blocks/online.php DB-Tabellen: priv_msgs, session_info 6.13 Core/Past Articles Der Block Past Articles gehört zum News-Modul und zeigt standardmäßig die zehn neuesten Artikel aus dem News-Modul an. In Version 0.750 Gold funktioniert dieser Block nicht. 70 PHP-Datei: includes/blocks/past.php DB-Tabellen: - 6 Blöcke 6.14 Core/PHP Script Der PHP-Script Block ist mit der Funktionalität des HTML-Blockes vergleichbar. Im Unterschied zum HTML-Block lässt sich hier PHPCode angeben, der über die eval()-Funktion ausgewertet wird. Natürlich haben Sie die Möglichkeit, hier auch sämtliche PostNuke API-Funktionen zu verwenden. Wir möchten das Kapitel Die PostNuke-Programmierung nicht vorwegnehmen, zeigen aber einmal ein kleines Beispiel. Kopieren Sie sich folgenden PHP-Code in den PHP-Block: Der PHP-Code darf nicht in PHP-Tags der Art eingeschlossen werden. echo "Meine User-ID: " . pnUserGetVar('uid') . " "; echo "Mein User-Name: " . pnUserGetVar('uname') . " "; echo "Heute ist der " . date("d. M. Y"); PHP-Datei: includes/blocks/php.php DB-Tabellen: - Abb. 6.2: Ausgeführter PHPCode im PHPBlock 6.15 Core/Plain Text Der einfachste Block-Typ überhaupt. Hier genügt die unformatierte Angabe von Text. Der Text erscheint dann fast so im Block, wie er eingegeben wurde – Zeilenumbrüche werden zur Drucklegung des Buches leider nicht korrekt umgesetzt. Hier müssten Sie für diese mit „ “ arbeiten. Zudem lässt sich auch hier komplett HTMLCode verwenden; der WYSISYG-Editor funktioniert auch hier. Fazit: greifen Sie lieber gleich zum HTML-Block. Der verträgt ebenfalls Plain Text. PHP-Datei: includes/blocks/text.php DB-Tabellen: - 6.14 Core/PHP Script 71 6.16 Core/RSS Newsfeed RSS bietet Ihnen die Möglichkeit, fremden Content in Ihre Seite zu integrieren, wie im folgenden am Beispiel von spiegel.de gezeigt. Der Link zu den RSS-Feeds von spiegel.de lautet http://www.spiegel.de/schlagzeilen/rss/0,5291 ,,00.xml. Wenn Sie diese URL in Ihren Browser eingeben, erhalten Sie eine XML-Datei – zum größten Teil unleserlich für das menschliche Auge, aber lesbar für alle RSS-Reader. Die in der XML-Datei enthaltenen Nachrichtenköpfe werden durch den RSSBlock umgebaut und als verlinkte Auflistung auf Ihrer Seite angezeigt. Der RSS-Block bietet folgende Einstellungsmöglichkeiten: RSS File URL: Geben Sie hier obenstehenden Link zur RSSXML-Datei an. Maximale Anzahl der angezeigten Einträge: wie viele Nachrichtenüberschriften sollen angezeigt werden? Seitenbild anzeigen: soll das Logo des Nachrichtenlieferanten angezeigt werden? Seitensuche anzeigen: ergibt einen „weiterlesen“-Link, der auf das Gesamtangebot des Nachrichtenlieferanten verweist. Beschreibung anzeigen: sollen die Nachrichtenköpfe angezeigt werden? Alternative Anzeige benutzen: ist diese Option eingeschaltet, werden die Nachrichten in einem etwas anderen Format aufgelistet. Es gibt eine Menge Nachrichten im RSS-Format – suchen Sie einfach mal in einer Suchmaschine nach deutschen RSS-Feeds. Spezialisierte RSS-Suchmaschinen sind z.B. http://www.rss-scout.de oder http://www.rss-verzeichnis.de 72 PHP-Datei: includes/blocks/rss.php DB-Tabellen: - 6 Blöcke 6.17 Core/RSS Extra Dieser Block war zur Drucklegung des Buches nicht vollständig implementiert. PHP-Datei: includes/blocks/rss2.php DB-Tabellen: - 6.18 Core/Search Box Gehört zum Suchen-Modul. Bei der Konfiguration des Blockes können Sie angeben, was standardmäßig durchsucht werden soll – was in 0.750 Gold zwar gespeichert, aber bei einer erneuten Konfiguration nicht korrekt ausgelesen wird. Der Block durchsucht nicht selbst die Datenbank, sondern überlässt diese Aufgabe der modules.php. Wir empfehlen die Aktivierung des „Show Search Buttons“, da dadurch bei Verwendung von Xanthia-Themes weniger Probleme entstehen. Andernfalls kann es sein, dass die Suche keine Ergebnisse anzeigt. PHP-Datei: includes/blocks/search.php DB-Tabellen: - 6.19 Core/Simple File Include Dieser Block gibt den Inhalt der gewählten Datei mit beliebigem Typ aus. Wird der Pfad zur Datei relativ angegeben, muss die Datei in der Document-Root von PostNuke liegen (probieren Sie es mal mit der im PostNuke-Verzeichnis enthaltenen robots.txt). Bei absoluten Pfaden funktioniert auch eine Angabe der Art „c:/test.html“. Sinn machen hier nur Dateitypen wie .txt oder .html. PHPDateien werden nicht geparst; die Ausgabe einer Binär-Datei wie .doc (Word) liefert erwartungsgemäß wirres Zeug. 6.17 Core/RSS Extra 73 PHP-Datei: includes/blocks/finclude.php DB-Tabellen: - 6.20 Core/Story Related Links Zeigt weiterführende Links zum Artikel an: mehr Artikel aus dem gleichen Topic andere Artikel vom gleichen Autor. Dieser Block wird nur nach dem Öffnen eines Artikels angezeigt. Darüber hinaus muss mindestens ein Artikel einem Topic angehören und die Option „rechte Blöcke in Artikeln anzeigen“ in den SystemEinstellungen von PostNuke aktiviert sein. PHP-Datei: includes/blocks/related.php DB-Tabellen: related, stories 6.21 Core/Story Titles Dieser Block zeigt eine Auflistung von Beiträgen an. Er lässt sich folgendermaßen konfigurieren: 74 Alle Beiträge anzeigen/nur Titelseiten-Beiträge anzeigen/nur nicht-Titelseiten-Beiträge anzeigen: welche Art von Artikeln soll angezeigt werden? Thema: soll nur ein bestimmtes oder alle Topics angezeigt werden? Kategorie: wie bei Topics Maximal anzuzeigende Beiträge: wie viele Beiträge sollen maximal angezeigt werden? PHP-Datei: includes/blocks/stories.php DB-Tabellen: stories, stories_cat, topics 6 Blöcke 6.22 Core/Today’s Big Story Zeigt alle Beiträge an, die am heutigen Tag mit dem News-Modul erstellt und mindestens einmal angeschaut wurden. PHP-Datei: includes/blocks/big.php DB-Tabellen: - 6.23 Core/Topics Menu Listet alle Topics einer Seite in einem Block auf, sofern ihnen Artikel zugeordnet sind. PHP-Datei: includes/blocks/topic.php DB-Tabellen: stories, topics 6.24 Core/User’s Login Zeigt einen Block an, über den sich PostNuke-Benutzer am System anmelden können. Wer den Block nicht verwenden möchte, kann alternativ auch die user.php direkt aufrufen. Wenn Sie nicht möchten, dass sich Benutzer über den LoginBlock oder die user.php selbständig registrieren können, wechseln Sie in die Administration – BenutzerAdministration – Konfiguration Benutzerregistrierung. Schalten Sie dort Benutzerregistrierung ermöglichen ab. PHP-Datei: includes/blocks/login.php DB-Tabellen: - 6.22 Core/Today’s Big Story 75 6.25 Core/User’s Custom Box Damit kann der Administrator jedem Benutzer einen persönlichen Block spendieren. Der Inhalt dieses Blockes darf Text oder HTML enthalten. Meist wird dieser Block dazu verwendet, sich Notizen oder ToDo’s für den Tag zu machen, seine persönliche Link-Liste zu pflegen oder ähnliches. Dieser Block wird nur sichtbar, wenn der Benutzer in seinen persönlichen Einstellungen unter „Einstellungen – Startseite einstellen“ sein persönliches Menü aktiviert hat. Hier wird dann auch der Inhalt des Blockes gepflegt – von jedem Benutzer persönlich. Text und HTML sind möglich, PHP-Code etc. nicht. Der von Ihnen vergebene Titel für diesen Blocktyp ist nur für interne Zwecke (Zugriffsrechte etc.) verwendbar. Die Benutzer sehen als Blocktitel immer nur „Menü für “. PHP-Datei: includes/blocks/user.php DB-Tabellen: users 6.26 pnRender/custom pnRender block Damit lassen sich sehr elegant Teil-Funktionalitäten eines Moduls in einem Block darstellen, beispielsweise Formulare, die bei Klick auf den Submit-Button leistungsstarke Modulfunktionen nutzen. Das ganze lässt sich am besten anhand eines Beispiels demonstrieren: Modulname: Mailer (case-sensitiv; hier muss der Verzeichnisname des Moduls angegeben werden) TemplateDatei: maileradminmodifyconfig.htm Parameter: smtpserver = Mein Mailserver; smtptimeout = 20; (die Parameter können Sie dem Inhalt der angegebenen Template-Datei entnehmen) Die hier angegebenen Module müssen nicht nur pnAPI-konform sein, sondern auch auf pnRender/Xanthia basieren (d.h. sie müssen mit Templates arbeiten, siehe Kapitel Xanthia-Themes). 76 6 Blöcke PHP-Datei: modules/pnRender/pnblocks/pnRender.php DB-Tabellen: - 6.27 Quotes/Random Quote Der Quotes-Block ist Teil des Zitat-Moduls und zeigt bei jedem Reload der Seite ein zufällig ausgewähltes Zitat aus der ZitatDatenbank an. Zitate müssen selber angelegt werden. PHP-Datei: modules/Quotes/pnblocks/quote.php DB-Tabellen: quotes 6.28 Xanthia/Logo Block for Xanthia Themes Dieser Block war zur Drucklegung des Buches nicht vollständig implementiert. PHP-Datei: modules/Xanthia/pnblocks/logo.php 6.29 Xanthia/Display module output in a block Dieser Xanthia-Block leitet die Ausgaben eines Moduls in einen Block um. Zusätzlich kann man festlegen, welche Funktion inkl. Parameter aus dem Modul verwendet werden soll, um die Ausgaben zu erzeugen. Ohne Angabe von Parametern wird die Standard UserFunktion verwendet (main-Funktion aus der user.php). Testen kann man dies einfach am Credits-Modul (hier ist eine Angabe von „Funktion“ und „Parameter“ nicht notwendig). PHP-Datei: modules/Xanthia/pnblocks/module.php DB-Tabellen: - 6.27 Quotes/Random Quote 77 6.30 Sie brauchen mehr Blöcke? Auf den im Anhang aufgeführten Seiten gibt es jede Menge mehr an Blöcken. Für fast jeden Einsatzzweck sollte sich ein passendes Stück Software finden – wenn nicht, erläutern wir im Kapitel Die PostNuke-Programmierung, wie Sie selbst eigene Blöcke entwickeln können. 6.31 Zusammenfassung Dieses Kapitel gab einen Überblick über alle in einer StandardPostNuke-Paket mitgelieferten Blöcke. Dabei wurde auf deren Funktionalitäten, Besonderheiten als auch auf technische Details wie verwendete Dateien und Datenbank-Tabellen eingegangen. 6.32 Ausblick Das nächste Kapitel stellt in der gleichen Art und Weise die Standard-Module eines PostNuke-Systems vor. 78 6 Blöcke 7 Module Ein PostNuke 0.750 Gold wird mit folgenden Modulen ausgeliefert (alphabetisch sortiert): 1. AddStory 2. Admin 3. Admin Messages 4. AutoLinks 5. AvantGo 6. Banners 7. Blocks 8. Censor 9. Comments 10. Credits 11. Downloads 12. Ephemerids 13. FAQ 14. Groups 15. Languages 16. Legal Documents 17. LostPassword 18. Mailer 19. MailUsers 20. Members List 21. Messages 22. Module 6.32 Ausblick 79 23. Multisites 24. News 25. NewUser 26. Past_Nuke 27. Permissions 28. pnRender 29. Polls 30. Quotes 31. Ratings 32. Recommend Us 33. Referers 34. Reviews 35. Search 36. Sections 37. Settings 38. Stats 39. Submit News 40. Template 41. Topics 42. Top List 43. typetool 44. Users 45. Web Links 46. Wiki 47. Xanthia 48. Xmlrpc 49. Your Account 80 7 Module 7.1 AddStory Kurzbeschreibung Mit AddStory kann ein Benutzer mit Administratoren-Rechten Artikel erstellen und freigeben. Die Module News, AddStory und Submit News bilden quasi eine Einheit. Drei Module im Verbund: AddStory, News, Submit News Funktionen & Verwendung Der Unterschied zum Modul „Submit News“ liegt in den Berechtigungen („Submit News“ ist mit Benutzerrechten aufrufbar) und dem Umfang der Eingabemaske. Bei „Submit News“ lassen sich nur Titel, Thema, Sprache, Einleitungs- und erweiterter Text eines Artikels festlegen. „AddStory“ erlaubt zusätzlich das Festlegen einer Kategorie (eine vertikale Gruppierung von Artikeln, siehe Kapitel Begriffe) die optionale Anzeige des Artikels auf der Startseite Besuchern kann erlaubt werden, den Artikel zu kommentieren das Format des Artikels kann geändert werden (Plain Text oder HTML vorformatiert) der minutengenaue Erscheinungstermin des Artikels kann programmiert werden die Freigabe des Artikels Diese erweiterten Funktionen kann der Redakteur (also die Person, die die Rechte hat, Artikel freizugeben) für jeden Artikel anwenden, also auch bei denjenigen, die über „Submit News“ erstellt wurden. Über „AddStory“ können darüber hinaus Artikel sofort nach der Erstellung freigegeben werden. Diese durchlaufen dann nicht den Workflow von der Erstellung durch einen Autor bis zur Freigabe durch einen Redakteur. Hinweis: Kategorien lassen sich nur in AddStory editieren. 7.1 AddStory 81 Technische Daten zum Modul Verzeichnisname: NS-AddStory Das Verzeichnis-Präfix „NS-„ wurde in 0.760 bei allen Modulen entfernt. Die Angaben beziehen sich also auf 0.750 und früher. pnAPI-konform: nein Link/Icon im Administrationsmenü: Beitrag hinzufügen Admin-Link zum Modul: admin.php?module=NS-AddStory &op=main Link zur Freigabe von Artikeln: admin.php?module=NSAddStory&op=submissions Benutzer-Link zum Modul: - Name für Erstellung eines Blocks: Core/menu (mit aktivierter Anzeige der zu prüfenden Beiträge), Core/Story Titles Konfigurationsmöglichkeiten der Blöcke: siehe Beschreibung im Kapitel Blöcke DB-Tabellen: stories, stories_cat, queue (für die nicht freigegebenen Stories), autonews (für die zeitgesteuerten Stories) Berechtigungsschema Stories::Category => Category name::Category ID Stories::Story => Author ID:Category name:Story ID Meinung der Autoren An diesem Modul kommt keiner vorbei – es sei denn, man setzt andere Content-Module wie beispielsweise „PageSetter“ ein. 7.2 Admin Ab PostNuke 0.760/0.8 wird dieses Modul eine kategorisierte AdministrationsAnsicht anbieten. 82 Kurzbeschreibung Das Admin-Modul im Verzeichnis NS-Admin wird von der admin.php aus dem PostNuke-Hauptverzeichnis verwendet. Die Hauptaufgabe liegt in der Darstellung des Administrations-Menüs, das z.B. mit der Systemsteuerung unter Windows vergleichbar ist. Darüber hinaus werden die zeitgesteuerten/noch nicht veröffentlichten Beiträge, die freigegebenen Artikel und die aktuelle Umfrage aufgelistet. Notwendig sind nur die Dateien des Moduls, es muss daher nicht aktiviert sein. 7 Module Technische Daten zum Modul Verzeichnisname: NS-Admin pnAPI-konform: nein Link/Icon im Administrationsmenü: gibt es nicht, aber das Admin-Modul liefert für andere Module ein Standard-Icon, wenn in deren pnimages-Verzeichnis keine Datei namens admin.gif, admin.jpg oder admin.png liegen sollte. Admin-Link zum Modul: admin.php Benutzer-Link zum Modul: - Name für Erstellung eines Blocks: - Konfigurationsmöglichkeiten des Blocks: - DB-Tabellen: autonews, poll_desc, queue, stories, stories_cat, topics Berechtigungsschema Admin:: => :: 7.3 Admin Messages Kurzbeschreibung Mittels Admin Messages kann der Administrator die Besucher seiner PostNuke-Seite über wichtige Dinge informieren. Admin Messages werden standardmäßig noch vor den News im Mittelteil einer PostNuke-Seite angezeigt (wenn der dazugehörige Block entsprechend positioniert ist). Darüber hinaus können abhängig vom Benutzerstatus unterschiedliche Nachrichten gezeigt werden. Beispiel: unregistrierte Besucher sehen eine freundliche Meldung, sich zu registrieren; Benutzer werden über Wartungsarbeiten informiert; Administratoren erhalten Infos zu neu installierten Modulen. Admin Messages sind keine Artikel und werden daher auch nicht von einer Suche in PostNuke berücksichtigt. Funktionen & Verwendung Eine Admin Message besteht aus folgenden Teilen Titel: z.B. „Wartungsarbeiten am Samstag“ Inhalt: dem eigentlichen Text (optional) Sprache: für welche Sprache soll diese Admin-Meldung angezeigt werden? 7.3 Admin Messages 83 Aktiv: Meldung aktiv (ja/nein) Wer soll die Nachricht sehen: alle Besucher, nur registrierte PostNuke-Benutzer, nur anonyme Besucher, nur die Administratoren der Seite Startdatum: wann soll die Admin-Nachricht erscheinen? (nicht funktional) Hinweis: in der vorliegenden Version 0.750 Gold finden sich im Source-Code Codestellen, um eine Admin Message nach einigen Tagen ablaufen zu lassen („expire“). Leider ist der Code durchgängig einkommentiert, die Funktion ist also ausgeschaltet. Ein schneller Hack – Aktivierung der Funktion – funktioniert nicht. Technische Daten zum Modul Verzeichnisname: NS-Admin_Messages pnAPI-konform: nein Link/Icon im Administrationsmenü: Admin Messages Admin-Link zum Modul: admin.php?module=NS-Admin_ Messages&op=main Benutzer-Link zum Modul: - Name für Erstellung eines Blocks: Admin Messages/Show admin messages Konfigurationsmöglichkeiten des Blocks: - DB-Tabellen: message Berechtigungsschema Messages:: => Message title::Message ID Meinung der Autoren Ein Admin Message Block sollte nur verwendet werden, wenn der Systemadmin auch etwas zu verkünden hat. Ansonsten wird die Admin Message zur Gewohnheit und die Benutzer bemerken keine Veränderung mehr. Zudem nimmt sie nur Platz weg, wenn nichts wirklich sinnvolles kommuniziert wird. 84 7 Module 7.4 AutoLinks Kurzbeschreibung Das Autolinks-Modul ersetzt definierte Schlüsselwörter durch einen Link. Im Beispiel der fiktiven Firma könnte der Standort immer mit dem Link auf einen Routenplaner verknüpft werden. Dies geschieht mittels Transform-Hooks aus dem AutoLinks-Modul dynamisch, bevor der bereits fertige Artikel zum Browser gesendet wird – der Artikel wird dabei also inhaltlich nicht verändert. Folgt im Artikel nach einem zu ersetzenden Wort ein harter Zeilenumbruch (\n), wird es nicht ersetzt. Funktionen & Verwendung So fügt man einen Autolink hinzu Administration – Autolinks - Autolink hinzufügen Schlüsselwort: hier angeben, welches Wort verlinkt werden soll, z.B. „Routenplaner“. Nicht case-sensitiv. Wildcards sind nicht zulässig. Titel: hier angeben, was der Browser beim Verweilen mit dem Mauscursor über dem Wort anzeigen soll, z.B. „Zum interaktiven Routenplaner“. URL: wohin soll verwiesen http://www.routenplaner.de/xyz0815.... Kommentar: dient nur zu Ihrer Information und Darstellung innerhalb des AutoLink-Moduls. werden? Z.B. AutoLinks-Konfiguration Autolink nur jeweils einmal im Text linken: taucht der Begriff mehrfach auf, wird er nur einmal verlinkt. Keine Auszeichnung für Autolinks: wenn aktiviert, wird der Link nicht unterstrichen dargestellt Hinweis: Damit dieses Modul auch aktiv wird, muss das NewsModul wissen, dass es seinen Output vorher durch ein anderes Modul schicken muss. Daher muss unter Administration – Module anzeigen – News – editieren – aktiviere AutoLinks für dieses Modul die Checkbox angehakt werden. Diesen Vorgang muss man für jedes Zielmodul, welches AutoLinks verwenden soll, wiederholen, vorausgesetzt, dass Zielmodul ruft Hooks auf. 7.4 AutoLinks 85 Technische Daten zum Modul Verzeichnisname: Autolinks pnAPI-konform: ja Link/Icon im Administrationsmenü: Autolinks Admin-Link zum &type=admin Benutzer-Link zum Modul: - Name für Erstellung eines Blocks: - Konfigurationsmöglichkeiten des Blocks: - DB-Tabellen: autolinks Modul: index.php?module=Autolinks Berechtigungsschema kein Berechtigungsschema definiert Meinung der Autoren Weitere sinnvolle Beispiele sind Benutzernamen, die mit mailtoLinks hinterlegt werden, der Begriff „Börsenbericht 2004“ verlinkt tatsächlich ohne Zutun des Autors auf das entsprechende PDFDokument, ein Fachbegriff wird mit einer Enzyklopädie verlinkt usw. 7.5 AvantGo Kurzbeschreibung AvantGo ist ein Anbieter von Software, welche Webseiten und Nachrichtenkanäle auf mobilen Geräten wie PDAs und Handys verfügbar macht. Funktionen & Verwendung Das AvantGo-Modul in PostNuke hat nichts mit der eigentlichen AvantGo-Software zu tun. Mit der Wahl dieses Namens wird nur ausgedrückt, dass mit Hilfe des Moduls eine Liste der zehn neuesten Stories so aufbereitet wird, dass sich diese auf mobilen Endgeräten ohne größere Einbußen darstellen lässt. Ein Klick auf eine Story öffnet deren druckfreundliche Ansicht. Technische Daten zum Modul Verzeichnisname: AvantGo 86 7 Module pnAPI-konform: nein Link/Icon im Administrationsmenü: - Admin-Link zum Modul: - Benutzer-Link zum Modul: modules.php?op=modload&name= AvantGo&file=index Name für Erstellung eines Blocks: - Konfigurationsmöglichkeiten des Blocks: - DB-Tabellen: stories, stories_cat, topics Berechtigungsschema AvantGo:: => :: Meinung der Autoren Dieses Modul macht aus unserer Sicht keinen wirklichen Sinn – zumal es keine AvantGo-spezifischen Features wie die Unterstützung von Channels u.ä. kennt. Den Namen hat es damit nicht verdient. Auch andere mobile Möglichkeiten wie WAP & Co. sind nicht umgesetzt. Es generiert lediglich eine druckerfreundliche Ansicht der zehn neuesten Artikel. Mehr Infos zu http://www.avantgo.com. AvantGo erhalten Sie unter 7.6 Banners Kurzbeschreibung Dieses umfangreiche Modul ermöglicht die Darstellung von Werbe-Bannern auf der eigenen PostNuke-Seite. Funktionen & Verwendung Banner-Modul konfigurieren Administration – Banner Ganz unten: Banner-Konfiguration anklicken Banner auf der Seite aktivieren: ja Eigene IP angeben: geben Sie hier die komplette IP-Adresse der Workstation an, deren Impressions nicht gezählt werden sollen, um die Banner-Statistiken nicht zu verfälschen. Leider kann 7.6 Banners 87 noch kein komplettes Subnetz angegeben werden. Die Klicks werden immer gezählt. Kunden-Login: banners.php? op=login Zunächst muss im Modul mindestens ein Kunde angelegt werden, der dann mit den noch anzulegenden Werbe-Bannern verknüpft wird. Wenn Sie dem Kunden zusätzlich einen Login-Namen inkl. Passwort geben, können die Werbe-Kunden über http://servername/postnuke/html/banners.php?op=login selber auf ihre Bannerstatistiken zugreifen. Damit wird kein echter PostNukeBenutzer angelegt. So legt man einen neuen Kunden an Administration – Banner Einfach die entsprechenden Felder ausfüllen. So legt man einen neuen Banner an: Ist mindestens ein Kunde angelegt, können Werbebanner hinzugefügt werden. Die Themes PostNukeBlue und SeaBreeze zeigen keine Banner an. 88 Administration – Banner – Banner hinzufügen Kunde auswählen Gekaufte Impressions: hier wird angegeben, wie oft die Einblendung des Banners verkauft wurde. Bei Erreichen der Grenze wird der Banner in der Statistik als „abgeschlossener Banner“ geführt. Hinweis: die Banner werden nicht deaktiviert, wenn die Impression-Grenze erreicht wird. ID-Typ: hier können Banner kategorisiert werden. Ohne Typangabe erhält jeder Banner automatisch den Typ 0. Standardmäßig wird aus allen Bannern diesen Typs zufällig einer ausgewählt und an der Stelle im Theme ausgegeben, in der die für Banner zuständige API-Funktion pnBannerDisplay() aufgerufen wird. Typ 1 sind Header-, Typ 2 sind Footer-Banner. Für Banner des Typs 1 oder 2 muss das Theme lediglich so modifiziert werden, dass der Funktionsaufruf den entsprechenden Typ enthält. Da Typen > 2 von pnBannerDisplay() nicht per echoBefehl ausgegeben, sondern als HTML-Code zurückgegeben werden, muss der Theme-Programmierer für die Ausgabe dieser Banner-Typen selber sorgen. Tipp: Wenn Sie jeden Banner jeweils mit einem anderen Typ erzeugen und im Theme entsprechend aufrufen, kann gewährleistet werden, dass mehrere Banner zeitgleich und andauernd angezeigt werden (dann machen eventuell nur unlimitierte Impressions Sinn). Wer sich ein Theme bauen möchte, welches Banner anzeigt, sollte einen Blick in 7 Module die Beschreibung der Funktion pnBannerDisplay($type) aus dem Kapitel Die PostNuke-API werfen. Bild-URL: Geben Sie hier die URL zu Ihrem Werbe-Banner in der Form http://servername/postnuke/html/images/banners/ banner1.gif ein. Dazu ist es notwendig, alle Banner im PostNuke-Verzeichnis unter postnuke/html/images/banners abzulegen. Auch http-Verweise auf externe Banner werden unterstützt. Bei Klick auf den Banner wird ein neues Fenster geöffnet. Klick-URL: URL, auf die bei Klick auf den Banner umgeleitet werden soll. Folgende Banner-Größen haben sich als Standard durchgesetzt: 468 x 60 (Full Banner) 234 x 60 (Half Banner) 120 x 90 (Button 1) 120 x 60 (Button 2) 88 x 31 (Micro Bar) 160 x 600 (Wide Skyscraper) 120 x 600 (Skyscraper) 125 x 125 (Square Button) 180 x 50 (Rectangle) 120 x 240 (Vertical Banner) 300 x 250 (Medium Rectangle) 250 x 250 (Square Pop-up) So fragt man die Banner-Statistik ab: Als Banner-Kunde: http://servername/postnuke/html/ banners.php?op=login aufrufen und einloggen. Dort hat der Kunde neben der Statistik-Ansicht auch die Möglichkeit, sich diese per E-Mail zukommen zu lassen (dazu muss der PostNuke-Server für E-Mail konfiguriert sein). Als PostNuke-Admin: direkt unter Administration – Banner Die verwendeten Begriffe: Impressions: Der Aufruf und das Laden einer PostNuke-Seite wird als ein „Impression“ gezählt. Wenn fünf Browser die PostNuke-Seite jeweils fünf mal reloaden, werden fünfundzwanzig Impressions gezählt. 7.6 Banners 89 Klicks: ein Klick wird gezählt, wenn auf den Banner geklickt wurde. % Klicks: Anzahl Klicks / Anzahl Impressions * 100 Technische Daten zum Modul Verzeichnisname: NS-Banners pnAPI-konform: nein Link/Icon im Administrationsmenü: Banner Admin-Link zum Banners&op=main Benutzer-Link zum Modul: - Name für Erstellung eines Blocks: Core/Custom Banner Display. Hinweis: im Banner-Block können nur Banner des Typs > 2 angezeigt werden. Konfigurationsmöglichkeiten des Blocks: Typ-ID des Banners (> 2) DB-Tabellen: banner (Bannerdefinition), bannerclient (Kundentabelle), bannerfinish (abgeschlossene Banner) Modul: admin.php?module=NS- Berechtigungsschema Banners::Client => Client name::Client ID Banners::Banner => Client name::Banner ID Meinung der Autoren Das Banner-Modul muss nicht zwangsweise dazu eingesetzt werden, Werbung von Partnern einzublenden. Auch Werbung in eigener Sache – z.B. für den umfangreichen eigenen Download-Bereich oder neue Bereiche im Intranet – ist damit sehr einfach umsetzbar. 7.7 Blocks Kurzbeschreibung Dieses Modul verwaltet alle Blöcke eines PostNuke-Systems. Hier können Sie festlegen, welche Blöcke wo auf Ihrer Seite angezeigt werden sollen. Zudem werden über dieses Modul die Blöcke editiert. Siehe Kapitel Blöcke. 90 7 Module Technische Daten zum Modul Verzeichnisname: Blocks pnAPI-konform: ja Link/Icon im Administrationsmenü: Blöcke Admin-Link &type=admin Benutzer-Link zum Modul: - Name für Erstellung eines Blocks: - Konfigurationsmöglichkeiten des Blocks: - DB-Tabellen: blocks zum Modul: index.php?module=Blocks Berechtigungsschema Blocks:: => Block key:Block title:Block ID Meinung der Autoren Ein systemweit wichtiges Modul, da es das funktionelle Layout einer PostNuke-Seite festlegt. Störend sind die nicht immer sauber funktionierenden Ordnungspfeile, um Blöcke in ihrer Anzeigereihenfolge zu ändern. 7.8 Censor Kurzbeschreibung Das Censor-Modul ersetzt zuvor definierte Wörter oder Phrasen durch einen Platzhalter wie z.B. „*****“. Technische Daten zum Modul Verzeichnisname: Censor pnAPI-konform: ja Link/Icon im Administrationsmenü: Censor Admin-Link &type=admin Benutzer-Link zum Modul: - Name für Erstellung eines Blocks: - Konfigurationsmöglichkeiten des Blocks: - DB-Tabellen: - zum Modul: index.php?module=Censor 7.8 Censor 91 Berechtigungsschema Censor:: => :CensorList: Censor:: => :CensorMode: Meinung der Autoren Der Einsatz des Moduls als Content-Filter für Schimpfwörter ist sicherlich sinnvoll, sobald Besucher der PostNuke-Seite eigene Inhalte hinzufügen dürfen. Eine kurze Liste von englischen Schimpfwörtern ist vordefiniert. Schlimmeres verhindert es aber nicht, auch, weil es keine Wort-Varianten erkennt. 7.9 Comments Kurzbeschreibung Das Comments-Modul erlaubt das Kommentieren von Artikeln, die mit dem News-Modul erzeugt wurden. Funktionen & Verwendung Es bietet dafür sehr umfangreiche Funktionen, ist aber kein Modul, welches per Hook anderen Modulen seine Funktionen anbieten kann. Die „Verheiratung“ mit dem News-Modul ist leider hart codiert. Technische Daten zum Modul Verzeichnisname: NS-Comments pnAPI-konform: nein Link/Icon im Administrationsmenü: Kommentare Admin-Link zum Modul: admin.php?module=NS-Comments &op=main Benutzer-Link zum Modul: user.php?op=editcomm (persönliche Einstellungen zum Kommentar-Modul) Name für Erstellung eines Blocks: - Konfigurationsmöglichkeiten des Blocks: - DB-Tabellen: comments Berechtigungsschema Verwendet das Security-Schema aus dem News-Modul. 92 7 Module Meinung der Autoren Kommentar-Module anderer Hersteller wie das Modul EZComments sind eleganter entwickelt, Hook-basiert und damit auch in Kombination mit anderen Modulen verwendbar. 7.10 Credits Kurzbeschreibung Das Modul „Credits“ dient dem PostNuke-Administrator zur Systeminformation. Das Modul erzeugt eine ausführliche Liste mit Angaben über alle installierten PostNuke-Module. Funktionen & Verwendung Es werden maximal folgende Informationen ausgegeben: Name des installierten Moduls Official: Offizieller Bestandteil von PostNuke j/n Versionsnummer des Moduls Beschreibung des Moduls, wozu dient das Modul Kontakt: Autor(en), meist verlinkt mit deren Webseite oder EMail-Adresse Credits: Informationen zu den Autoren oder zur Lizenz des Moduls. Verlinkt auf eine optional vorhandene credits.txt unterhalb von postnuke/html/modules/<modulname>/(pn)docs. Hilfe: Link zur Online-Hilfe des Moduls. Verlinkt auf eine optional vorhandene help.txt unterhalb von postnuke/html/modules/<modulname>/(pn)docs. Lizenz: Link zum Lizenztext des Moduls (unterschiedliche Module können je nach Hersteller und Herkunft durchaus unterschiedliche Lizenzen besitzen). Verlinkt auf eine optional vorhandene license.txt unterhalb von postnuke/html/modules/ <modulname>/(pn)docs. Changelog: die Versionshistorie des Moduls inkl. der Bugfixes oder Funktionen zwischen den einzelnen Versionen. Verlinkt auf eine optional vorhandene changelog.txt unterhalb von postnuke/html/modules/<modulname>/(pn)docs. 7.10 Credits Die Credits werden auf der Oberfläche durch einen Klick auf den „Credits“-Link im Footer des ExtraLiteThemes aufgerufen. pndocs bei newStyle-Modulen, docs bei oldstyle-Modulen 93 Technische Daten zum Modul Verzeichnisname: Credits pnAPI-konform: ja Link/Icon im Administrationsmenü: - Admin-Link zum Modul: - Benutzer-Link zum Modul: index.php?module=Credits Name für Erstellung eines Blocks: - Konfigurationsmöglichkeiten des Blocks: - DB-Tabellen: Das Modul bedient sich keiner SQL-Tabellen zum Auslesen seiner Informationen, sondern geht folgendermaßen vor: Ist im Verzeichnis des Moduls, dessen Informationen ausgelesen werden sollen, eine version.php vorhanden, werden die darin enthaltenen Informationen ausgelesen. Fehlt diese und ist statt dessen eine pnversion.php vorhanden, werden deren Informationen ausgewertet. Fehlt auch diese, werden nur die Informationen herangezogen, die die PostNuke API-Funktion pnModGetUserMods() zurückliefert (siehe dazu auch das Kapitel Die PostNuke-API). Hinweis: es geht hier lediglich um den Dateinamen. pnversion.php und version.php müssen den nachfolgend skizzierten identischen Aufbau haben. Beispiel für eine pnversion.php / version.php: '::'); ?> Berechtigungsschema Credits:: => :: 94 7 Module Meinung der Autoren Es hängt vom Autor eines Moduls ab, in wie weit die maximal darstellbaren Informationen auch wirklich gepflegt sind. Machen Sie sich bei einigen Modulen deshalb auf Enttäuschungen gefasst. Vorbild für Modulentwickler sollte das Credits-Modul selbst sein. 7.11 Downloads Kurzbeschreibung Realisiert eine Download-Sektion. Die Dateien müssen bereits im Dateisystem des PostNuke-Servers existieren oder per URL (http, ftp) aufrufbar sein. Anschließend kann im Downloads-Modul ein Eintrag erzeugt werden, der auf diese Datei verweist. StandardBenutzer können Vorschläge zur Verlinkung auf eine Datei einreichen. Funktionen & Verwendung Mit dem Modul können keine Dateien auf das PostNuke-System hochgeladen werden. Zunächst müssen Sie vor dem Einsatz des Downloads-Moduls mindestens eine Download-Kategorie in PostNuke anlegen, die die eingestellten Vorschläge unter einer Art Ordner gruppiert. Es erscheint der Block „wartend“, der Ihnen neben neuen Standard-Artikeln auch anzeigt, wenn neue Downloads auf Freischaltung warten. Es kennt noch weitere Funktionen wie das Melden defekter Downloads der Admin kann Downloads auf Existenz überprüfen Abstimmungen: Punktezahlen von 1 (schlecht) bis 10 (exzellent) für einen Download Kommentare auf Downloads Downloads können kategorisiert werden (max. eine Unterkategorie) 7.11 Downloads 95 Beliebteste Downloads: zählt die Häufigkeit des Downloads dieser Datei. Bestbewertete Downloads: zählt die Summe der Abstimmungs-Punkte Technische Daten zum Modul Verzeichnisname: Downloads pnAPI-konform: nein Link/Icon im Administrationsmenü: Downloads Admin-Link &op=main Benutzer-Link zum Modul: modules.php?op=modload&name= downloads&file=index Name für Erstellung eines Blocks: - Konfigurationsmöglichkeiten des Blocks: - DB-Tabellen: download_catgeories, download_downloads, download_editorials, download_modrequest, download_newdownload, download_subcategories, download_votedata zum Modul: admin.php?module=Downloads Berechtigungsschema Downloads::Category => Category name::Category ID Downloads::Item => File name::File ID Meinung der Autoren Das Modul enttäuscht ein wenig, und leider gibt es auch keine wirklich funktionierenden, gescheiten Alternativen für PostNuke 0.750. Wer eine Upload-Funktion benötigt, wird beim etwas besseren UpDownload-Modul fündig. 7.12 Ephemeriden Der Begriff „Ephemerid“ lässt sich am besten mit „Eintagsfliege“ übersetzen. Kurzbeschreibung Ein Ephemerid ist in PostNuke der Begriff für einen kalenderartigen Eintrag nach dem Motto „Was geschah heute vor x Jahren?“ oder „Es war einmal...“. Mit Hilfe dieses Moduls kann der Besucher der Webseiten an längst vergangene Ereignisse erinnert werden, z.B. den Börsengang der fiktiven Firma vor fünf Jahren. Es sind mehrere Ereignisse pro Tag erlaubt und auch Termine in der Zukunft möglich Technische Daten zum Modul Verzeichnisname: NS-Ephemerids 96 pnAPI-konform: nein 7 Module Link/Icon im Administrationsmenü: Ephemeriden Admin-Link zum Modul: admin.php?module=NS-Ephemerids &op=main Benutzer-Link zum Modul: - Name für Erstellung eines Blocks: Core/Ephemerids Konfigurationsmöglichkeiten des Blocks: - DB-Tabellen: ephem (enthält Tag/Monat/Jahr und Beschreibung des Ereignisses) Berechtigungsschema Ephemerids:: => Ephemerid::Ephemerid ID Meinung der Autoren Das Modul ist für sämtliche Webseiten brauchbar, welche themenbezogene Ereignisse aus ihrer Vergangenheit dem Besucher ins Gedächtnis zurückrufen möchten. 7.13 FAQ Kurzbeschreibung FAQ ist die Abkürzung für Frequently Asked Questions und bedeutet übersetzt „die am häufigsten gestellten Fragen“. Damit ist eine Liste von Fragen gemeint, die die Besucher einer Webseite immer wieder an deren Betreiber stellen. Der Anbieter der Seite liefert zu den gestellten Fragen für alle Besucher einsehbar die passenden Antworten. Bekannt sind die FAQs besonders von Hard- und Software-Herstellern. Funktionen & Verwendung Zunächst müssen Sie vor dem Einsatz des FAQ-Moduls mindestens eine Fragen-Kategorie in PostNuke anlegen, die die gestellten Fragen unter einem Thema gruppiert. 7.13 FAQ 97 Hinweis: Löscht man eine Fragen-Kategorie, die bereits beantwortete Fragen enthält, werden auch die darin enthaltenen Fragen gelöscht. So können Besucher die FAQs einsehen Startseite öffnen Module – FAQs Fragenkategorie auswählen und Liste der FAQ einsehen Alternativ muss dieser Link aufgerufen werden: http://servername/postnuke/html/modules.php?op=modload&na me=FAQ&file=index So können Besucher Fragen stellen Besucher gehen wie unter „So können Besucher die FAQs einsehen“ vor. Dort Link „Eine Frage stellen“ anklicken. Der Besucher kann nun – wenn er möchte – eine der vorgefertigten Frage-Kategorien auswählen. Anschließend muss er nur noch seine Frage an den Betreiber der Webseite eingeben und die Frage abschicken. So beantworten Sie die Fragen Ihrer Besucher Öffnen Sie die Startseite. Loggen Sie sich als Administrator ein Administration – FAQ – unbeantwortete Fragen zeigen Eine Liste aller noch unbeantworteten Fragen erscheint. Sie können die Frage nun kategorisieren und beantworten oder löschen. Hinweis: Sie werden von PostNuke nicht per Mail benachrichtigt, wenn ein Besucher eine neue Frage gestellt hat. Deshalb sind Sie als Administrator der Seite verpflichtet, die FAQs regelmäßig auf neue unbeantwortete Fragen zu untersuchen. Alternativ erscheint der Block „wartend“, der Ihnen neben neuen Standard-Artikeln auch anzeigt, wenn neue Fragen auf Beantwortung warten. Technische Daten zum Modul Verzeichnisname: FAQ 98 pnAPI-konform: nein Link/Icon im Administrationsmenü: FAQ Admin-Link zum Modul: admin.php?module=FAQ&op=main 7 Module Benutzer-Link zum Modul: &name=FAQ&file=index modules.php?op=modload Name für Erstellung eines Blocks: - Konfigurationsmöglichkeiten des Blocks: - DB-Tabellen: faq_answer, faq_categories Berechtigungsschema FAQ:: => Category name::Category ID Meinung der Autoren Aktivieren Sie das Modul, sobald mündlich oder per Mail die ersten Fragen an Ihr Unternehmen gestellt werden. Achten Sie allerdings auch auf regelmäßige redaktionelle Betreuung und beantworten Sie die Fragen so, wie Sie es als Besucher einer Seite auch erwarten würden. Ziehen Sie gegebenenfalls auch Ihre Kollegen zu Rate und installieren Sie im Unternehmen einen neuen Workflow zur Verteilung und Beantwortung neuer FAQs. 7.14 Groups Kurzbeschreibung Für die Sicherheit eines PostNuke-Systems eine neben dem Benutzer- und Zugriffsrechte-Modul wichtige Systemkomponente. Damit werden Benutzer zu logischen Einheiten zusammengefasst, für die dann gesammelt Rechte vergeben werden können. Die hier angelegten Gruppen werden auch nur im Zugriffsrechte-Modul (Permissions) verwendet. Einmal eingerichtet, könnte das Modul sogar deaktiviert und entfernt werden, inkl. seiner Dateien. Die Groups-Tabellen bleiben vom Deinstallationsprozess unberührt und dürfen auch manuell nicht gelöscht werden, da sonst das gesamte Portal nicht mehr funktionieren würde. Das gilt auch für das Zugriffsrechte-Modul. Technische Daten zum Modul Verzeichnisname: NS-Groups pnAPI-konform: nein Link/Icon im Administrationsmenü: Gruppen Admin-Link &op=main zum Modul: admin.php?module=NS-Groups 7.14 Groups 99 Benutzer-Link zum Modul: - Name für Erstellung eines Blocks: - Konfigurationsmöglichkeiten des Blocks: - DB-Tabellen: groups (enthält den Namen der Gruppe und eine jeweils eindeutige ID), group_membership (die zu einer Gruppe gehörenden Benutzer) Berechtigungsschema Groups:: => Group Name::Group ID Meinung der Autoren Das Modul kennt keine Untergruppen, genügt technisch aber voll und ganz und spielt seine Stärken in Kooperation mit dem Zugriffsrechte-Modul aus. Die Benutzeroberfläche ist ähnlich wie beim Users-Modul etwas umständlich. Zum Beispiel war es bis 0.750 nicht möglich, mehrere Benutzer auf einmal einer Gruppe zuzuordnen. 7.15 Languages Das LanguageModul kann nicht mit Modulen umgehen, die mit XanthiaTemplates arbeiten, weil deren Templates noch nicht geparst werden. 100 Kurzbeschreibung In erster Linie ein Modul für Übersetzer und daher bis auf zwei Konfigurationsmöglichkeiten weniger für den produktiven Betrieb benötigt. Es ist also möglich, dieses Modul problemlos zu deinstallieren. Funktionen & Verwendung Das Modul erzeugt eine Reihe von Sprachdateien, die alle Sprachkonstanten zum System enthalten. Ein Übersetzungsbüro kann anschließend diese Sprachdateien bearbeiten und damit neue Sprachpakete erzeugen. 1. Schritt: Sprache wählen. Zunächst wählt man das installierte Sprachpaket aus, welches man übersetzen oder komplettieren möchte. Im ersten Schritt passiert allerdings noch nicht viel, es werden nur alle Links im Languages-Modul auf die gewählte Sprache umgestellt. 2. Schritt: Laden der Konstanten. Es durchsucht u.a. ModulDateien wie pnadmin.php, pnadminapi.php, pnuser.php, pnuserapi.php und pninit.php sowie die zentralen Core-Dateien wie 7 Module admin.php, user.php usw. nach komplett großgeschriebenen Konstanten, die mit einem „_“ beginnen. Dies dauert natürlich eine gewisse Zeit. Die Tabellen languages_constant und languages_file werden gefüllt. Schritt 2 hat nichts mit Schritt 1 zu tun. 3. Schritt: Übersetzung laden. Jetzt wird im gesamten PostNukeDateisystem nach Sprach-Konstanten in den ModulSprachverzeichnissen wie lang und pnlang gesucht. Die Tabelle languages_translation wird für die in Schritt 1 gewählte Sprache – verglichen mit den Konstanten aus Schritt 2 – gefüllt. 4. Schritt: fehlende hinzufügen. Alle fehlenden Übersetzungen werden angezeigt. 5. Schritt: erzeugen. Die in Schritt 4 aufgelisteten fehlenden Übersetzungen werden für alle Module gesammelt in der Datei im missing.php language/<Sprachkürzel>Verzeichnis von PostNuke abgelegt. Zusätzlich wird eine Kopie aller Sprachdateien des gesamten Systems im Verzeichnis postnuke/html/language_<Sprachkürzel> abgelegt. Auf diesem Verzeichnis sollte – mit missing.php als Vergleich – gearbeitet werden. Nach Abschluss der Übersetzung ist man mit postnuke/html/language_ <Sprachkürzel> im Besitz eines kompletten Sprachpakets für seine lokale Installation, welches man wieder in seine PostNuke-Installation kopieren und weltweit verteilen kann. Technische Daten zum Modul Verzeichnisname: NS-Languages pnAPI-konform: nein Link/Icon im Administrationsmenü: Sprachen Admin-Link zum Modul: admin.php?module=NS-Languages &op=main Benutzer-Link zum Modul: - Name für Erstellung eines Blocks: Core/Languages Konfigurationsmöglichkeiten des Blocks: - DB-Tabellen: languages_constant (listet auf, welche Konstante sich in welcher Datei befindet), languages_file (Zuordnung von logischen Namen zu Dateien), languages_translation (Übersetzung der Konstanten in eine Sprache) 7.15 Languages Die Option „ML aktivieren“ bedeutet „MultiLanguage aktivieren“, also der Betrieb eines mehrsprachigen Portals 101 Berechtigungsschema Languages:: => :: 7.16 Legal Documents Kurzbeschreibung Das Legal Documents Modul stellt zentrale Dokumente wie die „Allgemeinen Nutzungsbedingungen“ und „Datenschutzhinweis / Erklärung zum Datenschutz (Privacy Policy)“ zur Verfügung – sogar auf deutsch, wenn das passende Sprachpaket installiert wurde. Funktionen & Verwendung Sie finden den Link zu diesen Dokumenten im Footer des Standard-Themes. So ändern Sie die Angaben Wechseln Sie in das Verzeichnis postnuke/html/modules/legal/lang/deu, wenn Sie die deutschen Texte anpassen müssen oder möchten. Editieren Sie die Datei global.php mit einem Texteditor. Technische Daten zum Modul Verzeichnisname: legal pnAPI-konform: nein Link/Icon im Administrationsmenü: - Admin-Link zum Modul: Benutzer-Link zum Modul: modules.php?op=modload &name=legal&file=index für die Allgemeinen Nutzungsbedingungen, modules.php?op=modload&name=legal&file=privacy für die Datenschutzhinweise Name für Erstellung eines Blocks: - Konfigurationsmöglichkeiten des Blocks: - DB-Tabellen: - Berechtigungsschema legal:: => :: 102 7 Module Meinung der Autoren Abschalten. Da eine Web-Präsenz sowieso impressumspflichtig ist, ist es viel einfacher, das „Legal Documents“ Modul zu deaktivieren, eigene, passende News-Artikel „Impressum“, „AGBs“ usw. mit allen notwendigen Angaben zu erstellen, das Theme zu modifizieren und dort auf die neuen PostNuke-Artikel zu verlinken. Weitere Vorteile dieser Vorgehensweise sind die implizite Durchsuchbarkeit durch die PostNuke-Suchmaschine sowie die Editierbarkeit der Artikel im Sinne eines CMS – auch ohne den Admin involvieren zu müssen. 7.17 LostPassword Kurzbeschreibung Ermöglicht es Benutzern, ihr Passwort zurückzusetzen, d.h. es wird durch PostNuke ein neues Passwort generiert und zugesendet. Funktionen & Verwendung Geben Sie unter user.php?op=lostpassscreen&module=NSLostPassword zunächst Ihren Benutzernamen und Ihre im System eingetragene E-Mail-Adresse an. Sie erhalten eine E-Mail mit einem Bestätigungscode (wenn Ihre Server-Umgebung für den Versand von E-Mail eingerichtet ist). Den erhaltenen Code geben Sie anschließend im gleichen Formular mit an. Damit wird Ihnen eine zweite E-Mail zugestellt, die Ihr neu zugeteiltes Passwort enthält. Technische Daten zum Modul Verzeichnisname: NS-LostPassword pnAPI-konform: nein Link/Icon im Administrationsmenü: - Admin-Link zum Modul: - Benutzer-Link zum Modul: &module=NS-LostPassword Name für Erstellung eines Blocks: - Konfigurationsmöglichkeiten des Blocks: - DB-Tabellen: - user.php?op=lostpassscreen 7.17 LostPassword 103 Berechtigungsschema kein Berechtigungsschema definiert 7.18 Mailer Kurzbeschreibung Ermöglicht die zentrale Konfiguration von SMTP-MailEinstellungen, die dann von anderen Modulen für den Mail-Versand aus dem Portal heraus genutzt werden können, auch bei Benutzerrechten/Benutzer-Ansichten (da das Mailer-Modul für den MailVersand eine Funktion sendmessages() aus pnuserapi.php zur Verfügung stellt). Auch die API-Funktion pnMail() verwendet wenn möglich die Einstellungen aus dem Mailer-Modul. Technische Daten zum Modul Verzeichnisname: Mailer pnAPI-konform: ja Link/Icon im Administrationsmenü: Mailer Admin-Link &type=admin Benutzer-Link zum Modul: - Name für Erstellung eines Blocks: - Konfigurationsmöglichkeiten des Blocks: - DB-Tabellen: - zum Modul: index.php?module=Mailer Berechtigungsschema Mailer:: => :: 7.19 MailUsers Kurzbeschreibung Mit diesem Modul kann ein Administrator bestimmten oder allen Benutzern des Systems eine SMTP-Email zukommen lassen. Verwendet die API-Funktion pnMail(), womit wenn möglich die Konfiguration des Mailer-Moduls herangezogen wird. 104 7 Module Technische Daten zum Modul Verzeichnisname: NS-MailUsers pnAPI-konform: nein Link/Icon im Administrationsmenü: Benutzer anmailen Admin-Link zum Modul: admin.php?module=NS-MailUsers &op=main Benutzer-Link zum Modul: - Name für Erstellung eines Blocks: - Konfigurationsmöglichkeiten des Blocks: - DB-Tabellen: users Berechtigungsschema MailUsers:: => User name::User ID 7.20 Members List Kurzbeschreibung Mit Hilfe dieses Moduls lassen sich alle Besucher und Benutzer inkl. ihres Status im System auflisten (also ob online oder nicht). Eine Auflistung der letzten zehn neu registrierten Benutzer fehlt ebenso wenig wie eine auf Benutzer spezialisierte Suchmaschine. Für die Suche in diesem Modul genügt die Angabe von Teilstrings. Funktionen & Verwendung So rufen Sie die Übersicht auf: Link „Mitglieder“ im Hauptmenü-Block anklicken Alternativ: http://servername/postnuke/html/modules.php?op= modload&name=Members_List&file=index Eine Suche nach leerem Benutzernamen fördert alle jemals registrierten Benutzer zu Tage, egal ob online oder offline (das gleiche schafft man aber auch über den Link „Alle“). Anschließend können Sie die gefundenen – und nur die gefundenen – Benutzer editieren oder löschen. Das Mitglieder-Modul ruft dafür die Funktionen des Benutzer-Administrations-Modul auf. 7.20 Members List 105 Technische Daten zum Modul Verzeichnisname: Members_List pnAPI-konform: nein Link/Icon im Administrationsmenü: - Admin-Link zum Modul: - Benutzer-Link zum Modul: modules.php?op=modload&name= Members_List&file=index Name für Erstellung eines Blocks: - Konfigurationsmöglichkeiten des Blocks: - DB-Tabellen: session_info, users Berechtigungsschema Members_List:: => :: 7.21 Messages Hinweis: wenn Sie eine neue Nachricht versenden, müssen Sie den PostNukeBenutzernamen des Empfängers kennen und diesen auch genau so unter „zu:“ eintragen. 106 Kurzbeschreibung Das Nachrichten-Modul versendet einfache, interne Mails zwischen registrierten PostNuke-Benutzern (und nur diesen). Neben einem Nachrichtenbetreff und der eigentlichen Nachricht kann noch ein Nachrichten-Icon vergeben werden. Attachments sind nicht möglich, dafür kann HTML oder BBCode verwendet werden. Technische Daten zum Modul Verzeichnisname: Messages pnAPI-konform: nein Link/Icon im Administrationsmenü: - Admin-Link zum Modul: - Benutzer-Link zum Modul: Mail versenden: Auf „Nachricht senden“ unter modules.php?op=modload&name=Messages &file=index klicken, Mails anschauen unter modules.php?op=modload&name=Messages&file=index oder alternativ über den Online-Block. Name für Erstellung eines Blocks: - Konfigurationsmöglichkeiten des Blocks: - 7 Module DB-Tabellen: priv_msgs (enthält alle privaten Nachrichten, unverschlüsselt) Berechtigungsschema kein Berechtigungsschema definiert 7.22 Modules Kurzbeschreibung Bietet dem Administrator eine Oberfläche zur Installation und Deinstallation sowie Upgrading von Modulen an. Ermöglicht darüber hinaus die Zusammenschaltung von Modulen per Hooks. Eines der zentralen Module in einem PostNuke-System. Funktionen & Verwendung Die Funktion sei anhand von new-style-Modulen erklärt. Wird auf erneut erzeugen geklickt, durchsucht das Modul das Dateisystem unterhalb von postnuke/html/modules. Dabei genügt dort schon ein neu angelegtes Verzeichnis, um dieses als Modul installieren und aktivieren zu können. Ein neu hinzugefügtes Modul muss zuerst initialisiert werden. Damit wird dessen Installationsroutine aufgerufen, welche zum Beispiel Datenbanktabellen oder Modulvariablen anlegt. Anschließend folgt die Aktivierung des Moduls, womit es Benutzern im Portal verfügbar wird. Unter anderem zeigt jetzt auch der Generic Menu-Block einen neuen Benutzer-Link zum Modul an. Verfügt das Modul über eine Admin-Oberfläche, taucht dessen Icon auch in der allgemeinen Administrations-Oberfläche auf. Wird ein Modul deaktiviert, wird nur dessen Funktion abgeschaltet. Die Benutzer können nicht mehr auf das Modul zugreifen und es ist nicht mehr administrierbar; dessen Daten bleiben aber erhalten. Wird ein Modul gelöscht, wird dessen Deinstallationsroutine aufgerufen, was auch meist ein Löschen seiner Datenbanktabellen zur Folge hat. Die Dateien des Moduls werden nie gelöscht. Damit erscheint es beim nächsten Neu-Erzeugen wieder in der Modulliste und kann erneut installiert werden. Anzeigen: Modulliste wird aus der Datenbank geladen (Cache, eventuell veraltet); Erneut erzeugen: Dateisystem wird nach Modulen durchsucht und damit die Modulliste in der Datenbank aktualisiert (aktuell, aber langsamer) Um festzustellen, ob Module upgedatet werden können, durchsucht das Modul Modules alle version.php oder pnversi- 7.22 Modules 107 on.php-Dateien der Module und vergleicht die darin enthaltenen Versionsnummern mit deren installierter Version. Hat sich diese geändert, wird ein Upgrade-Link angeboten. Idealerweise führen die upgedateten Module dann Routinen durch, die zum Beispiel auch bestehende Datenstrukturen updaten usw. Bei Meldung „Dateien fehlen“ ist das betroffene Modul unvollständig. Bis PostNuke 0.750 muss es dann im Verzeichnis physisch gelöscht, anschließend die Modulliste neu geladen und dort entfernt werden. Jetzt muss eventuell noch die PostNuke-Datenbank um die Tabellen des gelöschten Moduls bereinigt werden. Technische Daten zum Modul Verzeichnisname: Modules pnAPI-konform: ja Link/Icon im Administrationsmenü: Module Admin-Link zum &type=admin Benutzer-Link zum Modul: - Name für Erstellung eines Blocks: - Konfigurationsmöglichkeiten des Blocks: - DB-Tabellen: modules, hooks, module_vars Modul: index.php?module=Modules Berechtigungsschema Modules:: => :: 7.23 Multisites Kurzbeschreibung Dabei handelt es sich um kein echtes Modul im postnukeschen Sinne, sondern um eine reine Ansammlung von Dateien, die manuell an bestimmte Stellen ins PostNuke-System verschoben werden müssen, um Multisite-Features zu ermöglichen. Auf Multisites wird im Kapitel Multisites eingegangen. 108 7 Module 7.24 News Kurzbeschreibung Das Modul dient allein der Anzeige von Artikeln/Beiträgen/Stories. Die Module News, AddStory und Submit News bilden quasi eine Einheit. Drei Module im Verbund: AddStory,News, Submit News Technische Daten zum Modul Verzeichnisname: News pnAPI-konform: nein Link/Icon im Administrationsmenü: - Admin-Link zum Modul: - Benutzer-Link zum Modul: &name=News&file=index Name für Erstellung eines Blocks: Story Related Links, Past Articles, Story Titles, Todays Big Story, Categories Menu Konfigurationsmöglichkeiten des Blocks: - DB-Tabellen: stories, stories_cat, users, blocks, related, autonews modules.php?op=modload Berechtigungsschema Stories::Story => Author ID:Category name:Story ID Stories::Category => Category name::Category ID Meinung der Autoren Probieren Sie mal das Content-Modul Pagesetter aus: Es kennt frei definierbare Content-Typen und Workflows, Integration von Bilddatenbanken und vieles mehr. Pagesetter macht aus PostNuke erst ein richtiges CMS. http://www. elfisk.dk 7.25 NewUser Kurzbeschreibung Mit diesem Modul können sich Besucher selbstständig als neue PostNuke-Benutzer am System registrieren, vorausgesetzt, dass diese Einstellung in der Benutzer-Administration vom Administrator nicht deaktiviert wurde. 7.24 News 109 Technische Daten zum Modul Verzeichnisname: NS-NewUser pnAPI-konform: nein Link/Icon im Administrationsmenü: - Admin-Link zum Modul: - Benutzer-Link zum Modul: user.php?module=NS-NewUser Name für Erstellung eines Blocks: - Konfigurationsmöglichkeiten des Blocks: - DB-Tabellen: group_membership, groups, user_property, users Berechtigungsschema kein Berechtigungsschema definiert 7.26 Past_Nuke Kurzbeschreibung Das Modul stellt das Admin-Menü früherer PostNuke-Versionen dar. Es geht davon aus, dass ein Modul Unterverzeichnisse wie „admin/links“, „admin/case“ oder „admin/modules“ besaß (das gleiche gilt für „user/links“ etc.), in denen damals wichtige Dateien abgelegt waren. Wird standardmäßig im abgeschalteten Zustand ausgeliefert. Das Modul Your_Account ist solch ein Vertreter der alten Zunft, funktioniert aber auch ohne Past_Nuke. Technische Daten zum Modul Verzeichnisname: NS-Past_Nuke 110 pnAPI-konform: nein Link/Icon im Administrationsmenü: PastNuke Admin-Link zum Past_Nuke&op=main Benutzer-Link zum Modul: - Name für Erstellung eines Blocks: - Konfigurationsmöglichkeiten des Blocks: - DB-Tabellen: - 7 Module Modul: admin.php?module=NS- Berechtigungsschema kein Berechtigungsschema definiert Meinung der Autoren Kann deinstalliert werden, da es nur noch historische Bedeutung hat. 7.27 Permissions Kurzbeschreibung Mit diesem Modul werden die Zugriffsrechte des PostNukeSystems geregelt. Benutzer mit Administratorenrechten für dieses Modul können dabei Berechtigungen auf Gruppen- und/oder Benutzerebene festlegen, indem die von den Modulen bereitgestellten Berechtigungsschemata mit den im System bekannten Zugriffsarten verknüpft werden. Inhalte des Systems können so vor nicht autorisiertem Zugriff geschützt werden. Funktionen & Verwendung Verwenden Sie grundsätzlich Gruppenberechtigungen. Sie sind im Vergleich zu Benutzerberechtigungen effizienter und vereinfachen den administrativen Aufwand. Auf Benutzerrechte sollte nur dann zurückgegriffen werden, wenn Gruppenberechtigungen nicht mehr ausreichen. In diesem Fall überschreiben die jeweiligen Benutzerrechte auch die Gruppenberechtigungen. Ebenso wichtig ist die Reihenfolge der Regeln, da Berechtigungen immer von oben nach unten abgearbeitet werden. Werden mehrere äquivalente Regeln zu wahr ausgewertet, beispielsweise wenn ein Benutzer Mitglied in mehreren Gruppen ist, ist zu beachten, dass jede Regel ignoriert wird, die auf eine äquivalente, bereits abgearbeitete Regel folgt. Nähere Informationen zum Thema Berechtigungen finden Sie im Kapitel Sicherheit. Technische Daten zum Modul Verzeichnisname: Permissions pnAPI-konform: ja Link/Icon im Administrationsmenü: Zugriffsrechte Admin-Link zum &type=admin Benutzer-Link zum Modul: - Modul: index.php?module=Permissions 7.27 Permissions 111 Name für Erstellung eines Blocks: - Konfigurationsmöglichkeiten des Blocks: - DB-Tabellen: group_perms, user_perms Berechtigungsschema Permissions:: => :: Meinung der Autoren Eines der wichtigsten Module im ganzen PostNuke-System. 7.28 pnRender Kurzbeschreibung Das Layout-System Xanthia (XTE = Xanthia Template Engine) ist ab der PostNuke-Version 0.750 Bestandteil des Basis-Pakets. Es setzt sich dabei aus zwei Komponenten zusammen: 1. aus dem Modul Xanthia. Es kümmert sich hauptsächlich um die Verwaltung von Xanthia-konformen Themes und ist zuständig für das generelle Layout einer Seite. 2. aus pnRender. pnRender stellt anderen Modulen im PostNukeSystem Xanthia-Funktionen zur Verfügung und sorgt für die Übergabe von Modul- oder Block-Variablen an zuständige Templates. Technische Daten zum Modul Verzeichnisname: pnRender 112 pnAPI-konform: ja Link/Icon im Administrationsmenü: pnRender Admin-Link zum &type=admin Benutzer-Link zum Modul: - Name für Erstellung eines Blocks: pnRender / custom pnRender block Konfigurationsmöglichkeiten des Blocks: siehe dazu pnRender/custom pnRender block im Kapitel Blöcke. DB-Tabellen: - 7 Module Modul: index.php?module=pnRender Berechtigungsschema pnRender:: => :: Meinung der Autoren Darf wie das Modul Xanthia nicht deaktiviert werden, da alle Themes bzw. Module in Zukunft mit dieser Technik arbeiten werden. 7.29 Polls Kurzbeschreibung Mit diesem Modul können Sie den Besuchern Ihrer Seite Umfragen anbieten. Funktionen & Verwendung Umfragen erstellen/ändern Bei der Erstellung oder Änderung einer Umfrage unter Administration – Umfragen müssen Sie einen Titel sowie die Sprache der Umfrage angeben. Anschließend können Sie bis zu 12 Antwortmöglichkeiten vorgeben. Für die Anzeige einer Umfrage ist der „Core/Display Poll“Block notwendig. Im Block kann festgelegt werden, ob die aktuellste oder eine bestimmte Umfrage angezeigt werden soll. Konfiguration Unter Administration – Umfragen – UmfrageKonfiguration können Sie Kommentare in Umfragen erlauben (standardmäßig aktiv) und die Breite der Ergebnisbalken festlegen. Als Skalen-Werte lassen sich auch Kommazahlen eingeben (mit einem Punkt statt Komma). Die Breite des Ergebnisbalkens in Pixeln berechnet sich dann wie folgt: Umfrage-Prozentzahl * 4 * Skalen-Wert. Technische Daten zum Modul Verzeichnisname: NS-Polls pnAPI-konform: nein Link/Icon im Administrationsmenü: Umfragen Admin-Link &op=main zum Modul: admin.php?module=NS-Polls 7.29 Polls 113 Benutzer-Link zum Modul: modules.php?op=modload&name= NS-Polls&file=index Name für Erstellung eines Blocks: Core/Display Poll Konfigurationsmöglichkeiten des Blocks: anzuzeigende Umfrage kann ausgewählt werden DB-Tabellen: poll_check, poll_data, poll_desc, pollcomments Berechtigungsschema Polls:: => Poll title::Poll ID 7.30 Quotes Kurzbeschreibung Realisiert eine Zitatesammlung. Standardmässig werden in der PostNuke-Version 0.750 Gold keine Zitate mitgeliefert. Der Zitate-Block wird bei jedem Reload der Seite mit einem neuen Zitat belegt (kein Caching). Funktionen & Verwendung Neben dem Erstellen, Editieren und Löschen von Zitaten bietet dieses Modul keine weiteren Konfigurationsmöglichkeiten. Für den mitgelieferten Zitate-Block gilt: es müssen mindestens zwei Zitate eingestellt werden, damit der Block funktioniert. Technische Daten zum Modul Verzeichnisname: Quotes pnAPI-konform: ja Link/Icon im Administrationsmenü: Zitate Admin-Link &type=admin Benutzer-Link zum Modul: - Name für Erstellung eines Blocks: Quotes / Random Quote Konfigurationsmöglichkeiten des Blocks: - DB-Tabellen: quotes zum Modul: Berechtigungsschema Quotes:: => Author name::Quote ID 114 7 Module index.php?module=Quotes Meinung der Autoren Lässt sich natürlich auch für andere Gelegenheiten verwenden: bei jedem Reload gibt es dann statt Zitaten eine neue Vokabel, ein neues geschichtliches Ereignis usw. 7.31 Ratings Kurzbeschreibung Das Modul Ratings ermöglicht es Besuchern, Content wie z.B. Artikel oder Downloads nach einer Punkteskala zu bewerten. Funktionen & Verwendung Da dieses Modul hauptsächlich einen Hook darstellt, muss dieser in allen Modulen, in denen Bewertungen ermöglicht werden sollen, aktiviert sein. Technische Daten zum Modul Verzeichnisname: Ratings pnAPI-konform: ja Link/Icon im Administrationsmenü: Ratings Admin-Link &type=admin Benutzer-Link zum Modul: index.php?module=Ratings Name für Erstellung eines Blocks: - Konfigurationsmöglichkeiten des Blocks: - DB-Tabellen: ratings, ratingslog zum Modul: index.php?module=Ratings Berechtigungsschema Ratings:: => Module name:Rating type:Item ID Meinung der Autoren Das Modul Ratings ist mit manchen PostNuke-/MySQLVersionen nicht funktional, da es Datenbank-Feldtypen falsch setzt/behandelt. 7.31 Ratings 115 7.32 Recommend Us Kurzbeschreibung Realisiert für jeden Artikel des News-Moduls einen klassischen Link à la „Senden Sie diesen Artikel an einen Freund“. Über einen allgemeinen Link auf das Modul kann man seine PostNuke-Präsenz ganz allgemein weiterempfehlen lassen. Technische Daten zum Modul Verzeichnisname: Recommend_us pnAPI-konform: nein Link/Icon im Administrationsmenü: - Admin-Link zum Modul: - Benutzer-Link zum Modul: modules.php?op=modload&name= Recommend_Us&file=index (um Seite unabhängig von einem Artikel weiterempfehlen lassen zu können) Name für Erstellung eines Blocks: - Konfigurationsmöglichkeiten des Blocks: - DB-Tabellen: stories, stories_cat, topics Berechtigungsschema Recommend us:: => :: Meinung der Autoren Auch wenn das Modul klaglos seinen Dienst versieht, schalten Sie es lieber ab. Sie könnten u.U. abgemahnt werden, wenn über diese Funktion auf Ihrer Seite Dritte mit Mails belästigt werden, zu denen Sie selbst keine geschäftliche Beziehung pflegen. 7.33 Referers Kurzbeschreibung Ein Referer ist die URL der vorherigen Webseite, die zur aktuellen Seite geführt hat. Dieses Modul listet also auf, woher die Besucher Ihrer PostNuke-Seite stammen. 116 7 Module Technische Daten zum Modul Verzeichnisname: NS-Referers pnAPI-konform: nein Link/Icon im Administrationsmenü: HTTP-Referer Admin-Link zum Modul: admin.php?module=NS-Referers &op=main Benutzer-Link zum Modul: - Name für Erstellung eines Blocks: - Konfigurationsmöglichkeiten des Blocks: - DB-Tabellen: referer Berechtigungsschema Referers:: => :: Meinung der Autoren Der Einsatz von Proxies oder die Manipulation von HTTPReferern (z.B. durch Einsatz einer Norton Firewall möglich) lassen den Einsatz dieses Moduls wenig sinnvoll erscheinen. Auch wächst die Liste der Referer, die das Modul protokolliert, mit der Zeit ins Unendliche (Voreinstellung: 1000 Einträge). Für die Auswertung von Statistik-Daten dieser Art gibt es geeignetere Software, die direkt auf die Log-Dateien eines Webservers losgeht, z.B. Websuxess. 7.34 Reviews Kurzbeschreibung Ermöglicht die Erstellung von Produkt-Rezensionen. Ähnliche Funktionen kennt man von Produkt-Bewertungsseiten wie dooyoo.de. Technische Daten zum Modul Verzeichnisname: Reviews pnAPI-konform: nein Link/Icon im Administrationsmenü: Reviews Admin-Link &op=main zum Modul: admin.php?module=Reviews 7.34 Reviews 117 Benutzer-Link zum Modul: modules.php?op=modload&name= Reviews&file=index Name für Erstellung eines Blocks: - Konfigurationsmöglichkeiten des Blocks: - DB-Tabellen: reviews, reviews_add, reviews_comments, reviews_main Berechtigungsschema Reviews:: => Review name::Review ID 7.35 Search Eine Suche nach „%“ (Wildcard in SQL) oder alternativ nach nichts sucht nach jeglichem Content im Portal. AnzeigeGruppierung ändern? SearchPlugins umbenennen! 118 Kurzbeschreibung Ermöglicht den Benutzern, die Inhalte des PostNuke-Systems über ein Formular zu durchsuchen. Darüber hinaus kann der Benutzer definieren, welche Module auf welche Art durchsucht werden sollen. Funktionen & Verwendung Die Suche basiert auf Plugins, die von jedem Modul im Verzeichnis postnuke/html/includes/search abgelegt werden. Ein Plugin übernimmt – falls aktiviert – die modulspezifische Suche und liefert daraufhin seine Ergebnisse zurück; das SearchModul agiert dagegen als ein „Koordinator“ und zeigt die Ergebnisse aller Plugins gruppiert und gesammelt an. Die Gruppierung richtet sich dabei nach der Ordnung der Plugin-Dateien im Dateisystem. Technische Daten zum Modul Verzeichnisname: Search pnAPI-konform: nein Link/Icon im Administrationsmenü: - Admin-Link zum Modul: - Benutzer-Link zum Modul: &name=Search&file=index Name für Erstellung eines Blocks: Core/Search Box Konfigurationsmöglichkeiten des Blocks: Soll der „suchen“ Button angezeigt werden, welche Plugins sollen genutzt werden, 7 Module modules.php?op=modload welche Topics, Kategorien und Beiträge von welchem Autor sollen durchsucht werden DB-Tabellen: - (Jedes Plugin arbeitet mit den eigenen Modulbezogenen Tabellen) Berechtigungsschema kein Berechtigungsschema definiert (die Plugins müssen – entsprechend nach ihren Modulberechtigungen – selbst für die Umsetzung der Zugriffsregeln sorgen) 7.36 Sections Kurzbeschreibung Das Modul hilft bei der strukturierten Anzeige von sehr umfangreichem Content, z.B. von Handbüchern. Dazu verwendet es Hilfsmittel wie Seitenumbrüche, zwischen den Seiten des Dokuments kann direkt navigiert werden usw. Auch wenn das Sections-Modul letzten Endes ähnliches umsetzt wie das News-Modul, hat es nichts mit diesem zu tun. Technische Daten zum Modul Verzeichnisname: Sections pnAPI-konform: nein Link/Icon im Administrationsmenü: Sektionen Admin-Link &op=main Benutzer-Link zum Modul: &name=Sections&file=index Name für Erstellung eines Blocks: - Konfigurationsmöglichkeiten des Blocks: - DB-Tabellen: seccont, sections zum Modul: Beim allerersten Zugriff auf die Administration des SectionsModuls kann ausschließlich eine Sektion angelegt werden. admin.php?module=Sections modules.php?op=modload Berechtigungsschema Sections::Section => Section name::Section ID Sections::Article => Article name:Section name:Article ID 7.36 Sections 119 7.37 Settings Kurzbeschreibung Über dieses Modul lassen sich allgemeine systemweite Einstellungen im PostNuke-System tätigen. Neben Titel, Motto und Standard-Theme der Seite lassen sich hier interne Einstellungen wie Zeitzone und -format, Standardgruppe für neu angelegte Benutzer und Sicherheitsoptionen festlegen. Eine nähere Beschreibung der wichtigsten Einstellungsmöglichkeiten finden Sie im Unterkapitel Grundkonfiguration im Kapitel Die PostNuke-Installation. Technische Daten zum Modul Verzeichnisname: NS-Settings pnAPI-konform: nein Link/Icon im Administrationsmenü: Einstellungen Admin-Link zum Modul: admin.php?module=NS-Settings &op=main Benutzer-Link zum Modul: - Name für Erstellung eines Blocks: - Konfigurationsmöglichkeiten des Blocks: - DB-Tabellen: - Berechtigungsschema Settings:: => :: 7.38 Stats Das Installationsdatum, welches in den Statistiken referenziert wird, setzt man in den Einstellungen von PostNuke. 120 Kurzbeschreibung Erzeugt eine Kurzstatistik mit Zahlen, Daten, Fakten über die Nutzung Ihres PostNuke-CMS. Ausgegeben wird statistisches Material zu verwendeten Browsern Betriebssysteme der Clients Zeiten: wann (Stunden/Wochentage/Monate) wurden wie viele Seiten in Ihrem CMS abgerufen? der Anzahl der registrierten Benutzer Ihrer Seite etc. 7 Module Beachten Sie, dass die Werte fortlaufend kumuliert werden. Die Zahlen der Wochenstatistik betreffen also beispielsweise nicht die aktuelle Woche, sondern stellen die Summe der Zugriffszahlen über alle Wochen seit Bestehen des Systems dar. Technische Daten zum Modul Verzeichnisname: Stats pnAPI-konform: nein Link/Icon im Administrationsmenü: - Admin-Link zum Modul: Benutzer-Link zum Modul: modules.php?op=modload&name= Stats&file=index Name für Erstellung eines Blocks: - Konfigurationsmöglichkeiten des Blocks: - DB-Tabellen: comments, counter, links_categories, links_links, queue, seccont, sections, stats_date, stats_hour, stats_month, stats_week, stories, topics, users Berechtigungsschema Stats:: => :: 7.39 Submit News Kurzbeschreibung Benutzer mit dem PostNuke-Recht „kommentieren“ können mittels dieses Moduls Beiträge einreichen, die im Anschluss von einem Administrator (über das Modul Add_Story) freigegeben werden müssen. Der Administrator ist somit die letzte Instanz, die über die Erscheinung eines Beitrags entscheidet. Drei Module im Verbund: AddStory,News, Submit News Funktionen & Verwendung Im Vergleich zum Modul AddStory (das im Prinzip einen äquivalenten Beitrag erstellt) kann der Benutzer hier nur den Titel, das Topic, die Sprache sowie den Text und den erweiterten Text eingeben. Auch die Festlegung auf ein Ausgabeformat (HTML oder Text) kann hier nicht von einem normalen Benutzer durchgeführt werden. 7.39 Submit News 121 In der Administrationsoberfläche kann der Administrator festlegen, ob ein Mail über neu eingereichte Beiträge versendet werden soll. Technische Daten zum Modul Verzeichnisname: Submit_News pnAPI-konform: nein Link/Icon im Administrationsmenü: Submit_News Admin-Link zum Modul: admin.php?module=Submit_News &op=main Benutzer-Link zum Modul: modules.php?op=modload&name= Submit_News&file=index Name für Erstellung eines Blocks: - Konfigurationsmöglichkeiten des Blocks: - DB-Tabellen: queue, topics Berechtigungsschema Submit news:: => :: 7.40 Template Kurzbeschreibung Dieses pnAPI-konforme Modul soll als Vorlage für die Entwicklung eigener Module dienen (daher der Name „Template“). Wenn Sie keine eigenen Module entwickeln möchten, können Sie diese Vorlage deinstallieren und löschen. Meinung der Autoren Das Template-Modul ist gut, könnte aber besser sein. Es gibt einige Tricks, Tipps und Kniffe, um sich das Leben bei der Entwicklung von Modulen noch einfacher zu machen, auf die das TemplateModul nicht eingeht. Anfängern sei jedoch dringendst empfohlen, anhand dieser Vorlage zu entwickeln, da man hier einen guten Überblick über die notwendigen Dateien sowie den Umgang mit der PostNuke-Technik von der Parameter-Übergabe bis hin zu Sicherheitsfunktionen oder Hooking bekommt. Fortgeschrittene werden mit der Zeit eigene Vorlieben in der Art der PostNukeModulprogrammierung entwickeln. 122 7 Module 7.41 Topics Kurzbeschreibung Ermöglicht die einfache Kategorisierung von Content jeglicher Art in bestimmte Themen-Bereiche (Topics). Topics werden global im gesamten PostNuke-System verwendet (auch in Dritt-Modulen wie z.B. Pagesetter), Kategorien gibt es dagegen nur im NewsModul. Es sind keine hierarchischen Topics möglich Technische Daten zum Modul Verzeichnisname: Topics pnAPI-konform: nein Link/Icon im Administrationsmenü: Topics Admin-Link zum Modul: admin.php?module=Topics&op=main Benutzer-Link zum Modul: name=Topics&file=index Name für Erstellung eines Blocks: Core/Topics Menu Konfigurationsmöglichkeiten des Blocks: - DB-Tabellen: comments, related, stories, topics modules.php?op=modload& Berechtigungsschema Topics::Topic => Topic name::Topic ID Topics::Related => Related name:Topic name:Topic ID 7.42 Top List Kurzbeschreibung Dieses Modul listet jeweils eine festgelegte Anzahl der meistgelesenen Beiträge, meist kommentierten Beiträge, aktivsten Autoren, erfolgreichsten Umfragen, häufigsten Downloads, meistgelesenen Sektions-Beiträge sowie meistgelesenen Reviews auf. Funktionen & Verwendung Die Anzahl wird über die Administrationsoberfläche einmal für alle Ausgaben festgelegt. Die Top-Liste selbst wird über die Benutzeroberfläche ausgegeben. 7.41 Topics 123 Technische Daten zum Modul Verzeichnisname: Top_List pnAPI-konform: nein Link/Icon im Administrationsmenü: Top List Admin-Link &op=main Benutzer-Link zum Modul: modules.php?op=modload&name= Top_List&file=index Name für Erstellung eines Blocks: - Konfigurationsmöglichkeiten des Blocks: - DB-Tabellen: downloads_categories, downloads_downloads, poll_data, poll_desc, reviews, seccont, stories, stories_cat, users zum Modul: admin.php?module=Top_List Berechtigungsschema Top_List:: => :: 7.43 typetool Kurzbeschreibung Das Modul typetool bietet systemweit einen WYSIWYG-Editor an, der eine Formatierung von Texten ohne Programmier- und HTML-Kenntnisse ermöglicht. Funktionen & Verwendung Der Editor lehnt sich an die Bedienung gängiger Office-Produkte an. In der Administration von typetool kann der Editor aktiviert und die Editor-Sprache per Sprachdatei angegeben werden. Nähere Informationen zu typetool finden Sie im Unterkapitel WYSIWYG HTML-Editor „Type Tool“ im Kapitel Umgang mit PostNuke. Technische Daten zum Modul Verzeichnisname: typetool 124 pnAPI-konform: ja Link/Icon im Administrationsmenü: typetool Admin-Link &type=admin Benutzer-Link zum Modul: - 7 Module zum Modul: index.php?module=typetool Name für Erstellung eines Blocks: - Konfigurationsmöglichkeiten des Blocks: - DB-Tabellen: - Berechtigungsschema typetool:: => Modul name:: Meinung der Autoren typetool ist eine komfortable Alternative zur manuellen Eingabe von HTML und Text. 7.44 Users Kurzbeschreibung Bietet dem Administrator die Möglichkeit, Benutzer anzulegen, zu editieren und zu löschen. Benutzer verwalten über dieses Modul ihren Account und damit z.B. persönliche Einstellungen oder ihren eigenen Benutzer-Block. Darüber hinaus realisiert das Modul allgemeine Systemfunktionen wie den Login-Screen, kümmert sich um die Session-Cookies oder erzeugt auf Anfrage neue Passwörter. Technische Daten zum Modul Verzeichnisname: NS-User pnAPI-konform: nein Link/Icon im Administrationsmenü: Benutzer-Administration Admin-Link &op=main Benutzer-Link zum Modul: user.php Name für Erstellung eines Blocks: Core/User’s Custom Box, Core/User’s Login Konfigurationsmöglichkeiten des Blocks: der Benutzer-Block kann beliebigen Text- oder HTML-Content enthalten DB-Tabellen: group_membership, user_perms, user_property, users zum Modul: Die Datei user.php aus dem StammVerzeichnis von PostNuke bindet zwei SourceDateien des User-Moduls ein. admin.php?module=NS-User groups, user_data, Berechtigungsschema Users:: => Uname::User ID 7.44 Users 125 7.45 Web Links Kurzbeschreibung Das Web Links Modul stellt eine Liste von Links zu Webseiten zur Verfügung. Die Liste ist kategorisier- und durchsuchbar und entspricht in ihrem Verhalten etwa einem Web-Verzeichnis wie unter Yahoo. Funktionen & Verwendung Für die Bedienung des Web Links Moduls gelten die gleichen Aussagen wie für das Downloads-Modul, da beide aufeinander basieren und vom gleichen Autor stammen. Technische Daten zum Modul Verzeichnisname: Web_Links pnAPI-konform: nein Link/Icon im Administrationsmenü: Web Links Admin-Link &op=main Benutzer-Link zum Modul: modules.php?op=modload&name= Web_Links&file=index Name für Erstellung eines Blocks: Core/Latest Web Links Konfigurationsmöglichkeiten des Blocks: Modulname sowie Anzahl der aufzulistenden Links. Die Konfiguration des Modulnamens ist aber eher unglücklich, da sie Auswirkung auf die Verlinkung im Block hat. Der konfigurierte Name wird dazu verwendet, im Link den Parameter „name“ festzulegen. Im schlechtesten Fall wird hier dann auf ein falsches Modul umgeleitet. Sie sollten die Standardeinstellung „Web_Links“ beibehalten. DB-Tabellen: links_categories, links_editorials, links_links, links_modrequest, links_newlink, links_votedata zum Modul: admin.php?module=Web_Links Berechtigungsschema Web Links::Category => Category name::Category ID 126 Web Links::Link => Category name:Link name:Link ID 7 Module 7.46 Wiki Kurzbeschreibung Das Modul Wiki bietet die Möglichkeit, Texte über Steuercodes (sogenannter Wiki-Code) zu formatieren. Funktionen & Verwendung Wiki ist Hook-basiert, stellt sich also anderen Modulen zur Verfügung, wenn diese den Hook "Wiki" für sich aktiviert haben. Wiki selbst bietet keinerlei Konfigurationsmöglichkeiten, es hat weder eine Administrations- noch eine Benutzeroberfläche. Mehr zum Modul Wiki können Sie im gleichnamigen Unterkapitel in Umgang mit PostNuke nachlesen. Technische Daten zum Modul Verzeichnisname: Wiki pnAPI-konform: ja Link/Icon im Administrationsmenü: - Admin-Link zum Modul: Benutzer-Link zum Modul: - Name für Erstellung eines Blocks: - Konfigurationsmöglichkeiten des Blocks: - DB-Tabellen: - Berechtigungsschema kein Berechtigungsschema definiert Meinung der Autoren Wiki braucht nicht aktiviert werden, die Verwendung von TypeTool ist ausreichend und sogar komfortabler. 7.47 Xanthia Kurzbeschreibung Das Layout-System Xanthia (XTE = Xanthia Template Engine) ist ab der PostNuke-Version 0.750 Bestandteil des Basis-Pakets. Es setzt sich dabei aus zwei Komponenten zusammen: 7.46 Wiki 127 1. aus dem Modul Xanthia. Es kümmert sich hauptsächlich um die Verwaltung von Xanthia-konformen Themes und ist zuständig für das generelle Layout einer Seite. 2. aus pnRender. pnRender stellt anderen Modulen im PostNukeSystem Xanthia-Funktionen zur Verfügung und sorgt für die Übergabe von Modul- oder Block-Variablen an zuständige Templates. Funktionen & Verwendung Themes können hinzugefügt, editiert und gelöscht werden. Beachten Sie, dass nur hinzugefügte Themes als aktiv gelten und in den allgemeinen System-Einstellungen als Standard-Theme ausgewählt werden können. Das Editieren umfasst Block-Zonen, Theme-Zonen, ThemeTemplates, Theme-Farben, Theme-Einstellungen sowie die BlockKontrolle. Näheres zu diesem Modul und seinen Konfigurationseinstellungen finden Sie im Kapitel Xanthia. Technische Daten zum Modul Verzeichnisname: Xanthia pnAPI-konform: ja Link/Icon im Administrationsmenü: Xanthia Admin-Link &type=admin Benutzer-Link zum Modul: - Name für Erstellung eines Blocks: Xanthia/Logo block for Xanthia Themes und Xanthia/Display module output in a block Konfigurationsmöglichkeiten des Blocks: Keine für den erstgenannten Block. Der zweite Block verlangt die Angabe des Moduls, der zu ladenden Funktion sowie alle benötigten Parameter in der Art wie sie in einer URL definiert sind (Bsp.: cid=1&sid=5) DB-Tabellen: theme_addons, theme_blcontrol, theme_cache, theme_config, theme_layout, theme_palette, theme_skins, theme_tplfile, theme_tplsource, theme_zones zum Modul: index.php?module=Xanthia Berechtigungsschema Xanthia::item => Xanthia item name::Xanthia item ID 128 7 Module Meinung der Autoren Darf wie das Modul pnRender nicht deaktiviert werden, da alle Themes bzw. Module in Zukunft mit dieser Technik arbeiten werden. 7.48 Xmlrpc Kurzbeschreibung XMLRPC ermöglicht die Anbindung externer Text-Editoren wie z.B. w.bloggar von http://www.wbloggar.com. Mit Editoren dieser Art lassen sich nicht nur Texte erstellen und formatieren, sondern anschließend auch direkt in PostNuke veröffentlichen. So lässt sich Content auch ohne Verwendung eines Browsers pflegen. Darüber hinaus bietet das Modul eine pnuserapi.php, mit deren Hilfe Entwickler ihre eigenen Module um XMLRPC-Funktionen erweitern oder weitere Editoren an PostNuke anbinden können. Das NewsModul ist momentan die einzige Anwendung für XMLRPC Funktionen & Verwendung 1. xmlrpc-Modul aktivieren 2. w.bloggar herunterladen, installieren und starten 3. w.bloggar verlangt nach einem Benutzernamen und Passwort. Hier muss ein gültiger PostNuke-Account mit Rechten zur Erstellung einer Story angegeben werden. 4. w.bloggar konfigurieren: Blog System: PostNuke Bezeichnung: XMLRPC-Test Host: Hostname des PostNuke-Systems (z.B. localhost, wenn Editor und PostNuke auf dem gleichen System ausgeführt werden) Seite: passender Pfad zur xmlrpc.php, /postnuke/html/xmlrpc.php also z.B. 5. Artikel erstellen und auf Eintragen & Publizieren klicken. Während Topics auch in w.bloggar vergeben werden können, unterstützt es PostNuke-Zusatzfunktionen wie die Unterteilung in Einleitungs- und erweiterter Text nicht. Mit einem kleinen Hack kann aber das xmlrpc-Modul so geändert werden, dass auch diese Eintei- 7.48 Xmlrpc 129 lung über die Verwendung von z.B. HTML-Kommentaren simuliert werden kann. Eine Beschreibung dazu findet sich auf post-nuke.net (Suche nach XMLRPC). Abb. 7.1: Der bloggar-Client Wer andere Editoren anbinden möchte, muss eine API für das XMLRPC-Modul entwerfen. Die Datei modules\xmlrpc\api\blogger.php zeigt praktisch, wie so etwas funktioniert. Ist eine neue API erstellt, muss die pnuserapi.php des XMLRPC-Moduls um ein weitere include-Statement für diese Datei ergänzt werden. Technische Daten zum Modul Verzeichnisname: xmlrpc 130 pnAPI-konform: ja Link/Icon im Administrationsmenü: - Admin-Link zum Modul: - Benutzer-Link zum Modul: - Name für Erstellung eines Blocks: - Konfigurationsmöglichkeiten des Blocks: - DB-Tabellen: stories, topics, users 7 Module Berechtigungsschema kein Berechtigungsschema definiert 7.49 Your_Account Kurzbeschreibung Das Modul tritt in Aktion, wenn man auf seine „persönliche Seite“ über den Hauptmenü-Block gelangt. Es ermöglicht die Erstellung persönlicher Blöcke („User Blocks“, „Startseite einstellen“), die Selektion eines persönlichen Themes und die Pflege persönlicher Angaben. Darüber hinaus kann es eine Reihe von Icons/Links anbieten, die zu benutzerspezifischen Funktionen in Modulen verweisen. Schauen Sie sich einmal die besondere Verzeichnisstruktur direkt im NSYour_AccountVerzeichnis an. Funktionen & Verwendung Die Funktionen dieses Moduls erreicht man im HauptmenüBlock über den Link Einstellungen (nicht verwechseln mit Administration – Einstellungen) oder direkt über den Aufruf der user.php. Wer als Modulentwickler ebenfalls Funktionen über die persönliche Einstellungsseite anbieten möchte, muss in seinem Modulverzeichnis im Ordner pnimages möglichst ein Icon für seine Benutzer-Funktion ablegen, in seinem Modulverzeichnis ein Unterverzeichnis namens user anlegen, welches die Unterverzeichnisse case, links und modules enthält, und darin jeweils eine neue PHP-Datei namens links.MeineFunktion.php legen. Wie diese jeweils zu implementieren sind, zeigt das Your_Account-Modul. Wer es ganz einfach haben möchte, versucht mal einen BenutzerLink auf das News-Modul hinzuzufügen. Legen Sie eine Datei im Verzeichnis links.News.php modules/NSYour_Account/user/links an und füllen Sie diese mit folgendem Code: 7.49 Your_Account Der Dateiname ist egal – er bestimmt nur die Sortierreihenfolge der Icons auf der persönlichen Seite. 131 "News – Alle auf einen Blick", "images/topics/AllTopics.gif"); ?> Unter Einstellungen wird jetzt das Icon und die Beschreibung „News – Alle auf einen Blick“ angezeigt. Technische Daten zum Modul Verzeichnisname: NS-Your_Account pnAPI-konform: nein Link/Icon im Administrationsmenü: - Admin-Link zum Modul: - Benutzer-Link zum Modul: user.php Name für Erstellung eines Blocks: - Konfigurationsmöglichkeiten des Blocks: - DB-Tabellen: - Berechtigungsschema kein Berechtigungsschema definiert 7.50 Sie brauchen mehr Module? Auf den im Anhang aufgeführten Seiten gibt es jede Menge weitere Module. Für fast jeden Einsatzzweck sollte sich ein passendes Stück Software finden – wenn nicht, erläutern wir im Kapitel Die PostNuke-Programmierung, wie Sie selbst eigene Module entwickeln können. 7.51 Zusammenfassung Das Kapitel gab Ihnen detaillierte technische Informationen und Hinweise zur Bedienung, Funktionalität und Einsatzspektrum zu allen mitgelieferten Modulen. Die in 0.760 hinzugekommenen Module konnten zur Drucklegung des Buches nicht mehr berücksichtigt werden. 132 7 Module 7.52 Ausblick Im nächsten Kapitel werden Sie im Umgang mit Xanthia-basierten Themes vertraut gemacht. Auch die Erstellung eines eigenen Themes wird beschrieben. 7.52 Ausblick 133 8 Xanthia-Themes Ab der PostNuke-Version 0.750 wird das Layout des gesamten Auftritts über eine eigene Template-Engine namens XTE (Xanthia Templating Engine) gesteuert. Aufgabe einer Template-Engine ist die Trennung der Anwendungs-Logik von der Ausgabe – das Aussehen einer PostNuke-Seite kann damit beliebig ausgetauscht werden, die Logik und die Daten sind davon nicht betroffen. Das XTE-Paket besteht aus: Xanthia, welches für das Theme-Management zuständig ist.. pnRender basiert intern auf Smarty, einer Open Source Template-Engine für PHP (und Python). pnRender stellt die Schnittstelle für PostNuke-Module zu Smarty-Templates dar. Kernel Browser Zugriffsrechte pnRender mit SmartyTags in Templates Modul 1 Modul 2 Modul n Xanthia Abb. 8.1: Der Weg von der Anfrage bis zur Auslieferung von Seiten DB Suche 8.1 Einführung Bis PostNuke Version 0.726 wurden Modul-Ausgaben mit der pnHTML-Klasse erzeugt. Dabei wurden die Ausgabebefehle direkt 8.1 Einführung 135 in die Modul-PHP-Dateien (pnuser, pnadmin) programmiert. Ein Beispiel: function modulname_user_funktionsname(){ // Erzeugen eines neuen Objekts // $output des Typs pnHTML $output = new pnHTML(); // Erzeugen einer Tabelle mit einer // Spalte und einer Zeile $output->TableStart(); $output->TableRowStart(); $output->TableColStart(); $output->Text($my_result); $output->TableColEnd(); $output->TableRowEnd(); $output->TableEnd(); // Generierten Code an den // Browser übergeben return $output->GetOutput(); } Diese Vorgehensweise hat viele Nachteile: 136 Man muss im Beispiel sehr viel Code für die Definition einer kleinen Tabelle entwickeln und pflegen. Der Source-Code für die Ausgabe unterscheidet sich nicht von reinem Anwendungscode. Man ist an die Umsetzung der einzelnen Ausgabebefehle gebunden, was optimierten HTML Source-Code mitunter verhindern kann. Designer und Programmierer können nicht parallel arbeiten, da das Sammeln und Aufbereiten von Daten in derselben Datei stattfindet. Die Dateien sind nicht mit Design-Tools wie Frontpage o.a. editierbar. Ein einheitliches Corporate Identity ist fast nicht umsetzbar. 8 Xanthia-Themes Noch bedienen sich viele Module der alten pnHTML-Techniken, die wir hier jedoch nicht weiter vertiefen wollen. Xanthia beschreitet einen völlig anderen Weg. Ein XanthiaTemplate ist zunächst einmal nichts anderes als eine reine HTMLDatei. Zusätzlich kann dieser HTML-Code Variablen und Funktionen in einem bestimmten Format (die Tags der Smarty Templating Engine) enthalten, die von PostNuke-Modulen gefüllt und von der Layout-Engine an den Browser ausgeliefert werden. PostNukeModule müssen also im Gegensatz zu obigem Beispiel keinerlei HTML-Code mehr enthalten. Damit fallen alle genannten Nachteile weg. Xanthia ist für das Management der Themes zuständig Das obige Beispiel als Xanthia-Template: Eine Sammlung bestimmter globaler Xanthia-Templates wird Xanthia-Theme genannt. Ein Theme legt modulübergreifend das Layout und in Teilen auch das Verhalten einer PostNuke-Seite fest. PostNuke wird mit folgenden Xanthia-Themes ausgeliefert, die nach der Installation noch deaktiviert sind: Piterpan V2 pnDefault PostNuke PostNukeBlue PostNukeSilver SeaBreeze 8.1 Einführung 137 Achten Sie bei der Suche nach Themes im Internet auf Xanthia-konforme Themes bzw. Themes für PostNuke ab Version 0.750. Das nach der Installation standardmäßig aktive Theme „ExtraLite“ ist nicht Xanthia-konform. 8.2 Themes administrieren Um eine Übersicht sämtlicher im System vorhandener XanthiaThemes zu erhalten, klicken Sie in der Administration des XanthiaModuls auf den Link Themes anzeigen. Sie bekommen daraufhin eine tabellarische Auflistung, in der Sie jeweils den Namen des Themes sowie dessen gegenwärtigen Status (aktiv/inaktiv) und weitere vom Status abhängige Aktionen sehen. 8.2.1 Themes hinzufügen Bevor Sie Themes aktivieren oder editieren, sollten Sie sicherstellen, dass neben dem Xanthia-Modul auch das pnRender-Modul aktiviert ist. 138 Mit Klick auf den Link Administration – Xanthia Theme hinzufügen werden die Templates des Themes in die System-Datenbank geschrieben. Bei erfolgreicher Durchführung wird das Theme dann „aktiv“. Um es als Standard-Theme Ihrer Seite einzurichten, wechseln Sie in die Administration – Einstellungen und wählen unter Standard-Theme der Seite eines der aktivierten Themes aus. Angenommen, Sie laden ein Xanthia-Theme aus dem Internet, z.B. von http://news.postnuke.com/Downloads.html, aktivieren es und richten es als Standard-Theme Ihrer Seite ein. Dann stellen Sie fest, dass das Theme fehlerhaft ist – Ihre Seite wird damit leider unbenutzbar. Ist das passiert, schafft folgender Tipp Abhilfe: Starten Sie das Tool PostNuke Swiss Army Knife (PSAK) und wählen Sie dort über den Befehl Theme Reset eines der Standard-Themes von PostNuke aus, am besten das „ExtraLite“-Theme (siehe auch Kapitel Troubleshooting, Backup und Recovery). Es geht aber auch einfacher: Wenn Sie ein neu hinzugefügtes bzw. modifiziertes Theme vor der Einrichtung als Default-Theme auf Funktionsfähigkeit überprüfen möchten, klicken Sie nach dessen Aktivierung auf den Link Administration – Xanthia Theme anzeigen. 8 Xanthia-Themes 8.2.2 Einfache Theme-Anpassungen vornehmen Werfen Sie einfach mal einen Blick in das Verzeichnis postnuke/html/themes/. Wenn Sie nur ein paar Bilder Ihres gewählten Themes austauschen möchten, werden Sie im Unterverzeichnis images fündig. Tiefergehende Anpassungen sollten erst nach Lektüre dieses Kapitels erfolgen. 8.2.3 Theme-Eigenschaften editieren Aktive Themes sind editierbar, je nach Ausprägung des Themes aber in unterschiedlichem Maße. Es können Einstellungen bezüglich Block-Zonen, Theme-Zonen, Theme-Templates, Theme Farben, Theme-Einstellungen und der Block-Kontrolle vorgenommen werden. Block-Zonen: definiert Smarty-Tags für Elemente eines Themes, z.B. Tags für Banner, Spalten, linke Blöcke usw. Aufgerufen wird eine Zone, indem im entsprechenden Theme das Smarty-Tag für die Block-Zone eingefügt wird. Theme-Zonen: Theme-Zonen ordnen den verschiedenen Anzeigebereichen eines Themes (beispielsweise den linken Blöcken) genau eine Template-Datei zu, die das Aussehen des Bereichs bestimmt (und dort die zuvor definierten Block-Zonen verwendet). Einige Zonen können nicht entfernt, Addon-Zonen dagegen jederzeit deaktiviert oder gelöscht werden. Neue Theme-Zonen können beliebig hinzugefügt werden. Theme-Templates: Hier können die verschiedenen in der Datenbank gespeicherten Templates des Themes eingesehen, editiert und neu geladen werden. Theme-Farben: Hier können Sie die im Theme verwendeten Farben bequem über einen Farbdialog bestimmen. Es ist sogar möglich, mehrere Farbpaletten gleichzeitig zu verwenden. Im Standard-Lieferumfang von PostNuke unterstützt dies aber nur das pnDefault-Theme. Hierfür müssen dynamic stylesheets aktiviert sein, was durch eine neue Zeile in der master.htm vor dem schließenden HEAD-Tag ausgedrückt wird: Theme-Einstellungen: Hier können Sie verschiedene Themegebundene Einstellungen ändern. Die bekanntesten sind righton 8.2 Themes administrieren Aktivieren Sie zur weiteren Lektüre am besten das PiterPan-Theme. Es bietet die meisten Konfigurationsmöglichkeiten. 139 [Anzeige rechter Blöcke ja/nein], indexcol [Anzahl der Spalten], rcolwidth [Breite der rechten Spalte], lcolwidth [Breite der linken Spalte] und pagewidth [Breite der gesamten Seite]. Einschalten einer Einstellung mit „1“, Ausschalten mit „0“. Block-Kontrolle: Hier können Sie die Blockanzeige individuell für jedes Modul konfigurieren. Sie können dabei festlegen, welcher Block im jeweiligen Modul in welcher Spalte des Themes und in welcher horizontalen Anordnung angezeigt werden soll. Wird hier für ein Modul keine Angabe gemacht, werden die Einstellungen aus der PostNuke-Block-Verwaltung verwendet. Beachten Sie, dass für diese Funktionalität unbedingt der Block ==Block Control angelegt sein muss. Ohne diesen Block findet keine Überschreibung der Standard-Blockansicht statt. Tipp: Sie sollten nie ein aktiviertes Theme editieren, welches gleichzeitig das Default-Theme ist. Wählen Sie ein anderes Default-Theme und greifen Sie dann auf die Funktion Theme anzeigen zurück, um Ihre Einstellungen zu testen. 8.2.4 Templates ändern und neu laden Wurden Änderungen direkt an Theme-Dateien (*.htm) vorgenommen, müssen diese anschließend erneut in die Datenbank eingelesen werden, um die Änderungen auch sichtbar zu machen – da sich Xanthia aus Performancegründen nur direkt aus der Datenbank bedient. Klicken Sie dazu auf den Link Administration – Xanthia – Templates editieren – Theme Templates – Template neu laden der jeweiligen Datei. 8.2.5 Config-Cache aufbauen Wenn Sie die Geschwindigkeit Ihrer Seite erhöhen möchten, erzeugen Sie für jedes Modul im System eigene Cache-Dateien. Klicken Sie auf den Link Administration – Xanthia – Theme editieren – Config-Cache generieren. Falls dieser Vorgang fehlschlägt und Sie im Anschluss ParseErrors von PHP-Dateien im pntemp/Xanthia_ConfigVerzeichnis erhalten, können Sie einfach sämtliche PHP-Dateien darin löschen. 140 8 Xanthia-Themes 8.3 Xanthia konfigurieren In den allgemeinen Einstellungen des Xanthia-Moduls können Sie über die Verwendung eines Visual Block Editors und der Einrichtung von Short URLs entscheiden, sowie Einfluss auf die Handhabung von Templates – inklusive Caching – nehmen. Um diese Maske zu öffnen klicken Sie auf den Link Administration – Xanthia - Xanthia konfigurieren. Visual Block Editor benutzen: Damit können Sie einen BlockEditor aktivieren, mit dessen Hilfe der Administrator des Systems die Block-Anzeige komfortabler konfigurieren kann. Ist diese Option aktiviert, kann dieser Block-Editor über ein Icon in der rechten oberen Ecke jedes Blocks aufgerufen werden. Sie können hier die Position und Anordnung sowie die Konfiguration des Blocks verändern. Beachten Sie, dass die Änderungen nur Auswirkungen auf Blöcke haben, die im Punkt BlockKontrolle der Theme-Konfiguration angelegt wurden und in der Standardblockverwaltung eingeschaltet sind. Short URLs aktivieren: auf ShortURLs und die dazu passenden Optionen wird im nächsten Unterkapitel gesondert eingegangen. Caching nutzen: Mit dieser Checkbox können Sie das Caching von Xanthia-Themes aktivieren, womit Cache-Dateien aus dem Dateisystem genutzt werden. Module die vom Caching ausgenommen sind: Geben Sie hier komma-separiert alle PostNuke-Module an, die vom Caching ausgenommen werden sollen. Diese Einstellung macht z.B. dann Sinn, wenn ein Modul sehr viele kurzfristig veränderliche Inhalte anzeigt, die kürzere Lebenszyklen besitzen als die Dauer des Caching lang ist. Beispiel: „Reviews, FAQ“. Auf aktualisierte Templates prüfen: Wenn Sie diese Option aktivieren, werden Änderungen an einem Template auch dann übernommen, wenn das Caching aktiviert ist. Beachten Sie dass durch die Aktivierung Performance verloren geht. Wir empfehlen diese Option daher nur, wenn Sie Änderungen am Theme vornehmen möchten. Im Standardbetrieb kann bzw. sollte darauf verzichtet werden. Erneutes Kompilieren der Templates erzwingen: Auch hier empfehlen wir den Einsatz nur, wenn Sie kurzfristig Änderungen am Theme vornehmen möchten. 8.3 Xanthia konfigurieren Ein Theme hat die Seite zerstört und Ihr System damit unbenutzbar gemacht? PSAK schafft Abhilfe (siehe Kapitel Das PostNuke Swiss Army Knife (PSAK)) 141 Dauer für das Caching: Hier spezifizieren Sie den Zeitraum in Sekunden, in dem die Seiten im Cache vorgehalten werden sollen. Templates in die Datenbank schreiben: Durch diese Option werden die Templates immer in die Datenbank geschrieben, nachdem sie online editiert wurden. Beachten Sie jedoch, dass Online-Änderungen ausschließlich in der Datenbank berücksichtigt werden. Im Falle des Neuladens der Templates aus dem Dateisystem gehen diese Änderungen verloren. Diese Funktion soll in zukünftigen Xanthia-Versionen um den entgegengesetzten Weg erweitert werden, so dass Online-Änderungen auch im Dateisystem gespeichert werden. Solange sollten Sie die Templates im Dateisystem editieren und mittels Neuladen in der Datenbank aktualisieren. trimwhitespace Ausgabefilter: Mit dieser Option können Sie einstellen, dass alle unnötigen Zeichen aus dem HTML-Source entfernt werden, bevor die Ausgabe an den Browser geschickt wird. Damit verringert sich zwar die Performance, dafür müssen insgesamt aber weniger Daten an den Browser geliefert werden. Im besten Fall neutralisieren sich beide Aspekte, im Zweifelsfall müssen Sie abwägen, ob die Leistungsfähigkeit Ihres Servers oder die zur Verfügung stehende Bandbreite wichtiger ist. 8.3.1 Short URLs ShortURLs funktionieren nur bei Xanthia-Themes Dynamische URLs der Art modules.php?op=modload &name=News&file=article&sid=58&mode=thread&or der=0&thold=0 verhindern bei den meisten Suchmaschinen die Aufnahme und Indizierung Ihrer PostNuke-Seite. Mit Einführung von XTE hat der Mechanismus der Short URLs nun Einzug in den PostNuke-Core gehalten. Damit erreichen Sie, dass aus dem oben angegebenen Link einfach article58.html wird – was wiederum von Suchmaschinen problemlos indiziert werden kann. Stellen Sie vor der Einrichtung bitte sicher, dass der Web-Server das Rewrite-Engine Modul geladen hat. In der ApacheKonfigurationsdatei beispielsweise können Sie das daran erkennen, dass der Zeile LoadModule rewrite_module modules/ mod_rewrite.so 142 8 Xanthia-Themes kein #-Zeichen vorangestellt ist. Zeilen mit vorangestelltem #Zeichen werden in der Apache-Konfigurationsdatei als Kommentar interpretiert. Im Initialzustand von PostNuke ist zunächst unter dem Punkt Short-URLs aktivieren eine rot unterlegte Warnmeldung zu sehen, die besagt, dass keine .htaccess-Datei in der Document Root zu finden ist. Diese Datei ist für das „Umbiegen“ der ShortURLs zurück in dynamische PostNuke-URLs zuständig. Sie finden drei mögliche Versionen dieser Datei im Verzeichnis modules/Xanthia/pndocs/short_urls/ und dort jeweils im Unterverzeichnis „htm“, „html“ und „phtml“. Welche davon zu verwenden ist, richtet sich in erster Linie nach der Konfiguration des Webservers. Sollte der Server neben PHP wirklich nur HTMLDateien parsen, so sollte man die .htaccess-Datei aus dem htmlVerzeichnis verwenden. 1. Kopieren Sie die passende .htaccess-Datei in die Document Root von PostNuke. Die .htaccessDatei funktioniert im Original nur, wenn PostNuke direkt in der Document Root (also nicht unter /html) installiert ist. Ansonsten muss die .htaccessDatei modifiziert werden (in jeder Regel das ^Zeichen entfernen). 2. Starten Sie u.U. Ihren Webserver neu. 3. Wechseln Sie anschließend in die allgemeine Xanthia-Konfiguration. Dort dürfte jetzt keine Warnmeldung mehr zu sehen sein. Statt dessen erscheint eine Checkbox, mit deren Hilfe Sie die Short URLs aktivieren können. 4. Erweiterung für Short URLs: Hier spezifizieren Sie, welche Endung die Short URLs benutzen sollen. Der Wert richtet sich nach der verwendeten .htaccess-Datei. Möglich sind daher ‚htm’, ‚html’ und ‚phtml’. Beachten Sie, dass Sie die Endung ohne führenden Punkt eingeben. Anschließend empfehlen wir einen ersten Test. Klicken Sie dazu auf ‚übertragen’ und schauen Sie sich im URL-Fenster an, ob die dynamischen Links jetzt wie erwartet durch kurze Links ersetzt werden. 8.3 Xanthia konfigurieren 143 8.4 Theme erstellen Aus den PostNukeThemes empfehlen wir PostNukeBlue als Basis für eigene Entwicklungen. Für die Erstellung eines Themes gibt es grundsätzlich zwei Möglichkeiten. Entweder Sie beginnen bei Null, was wir aber nur fortgeschrittenen Anwendern empfehlen, oder Sie setzen auf einem bereits vorhandenen Theme auf. Wir werden in diesem Abschnitt den zweiten Weg beschreiben. Wichtig ist dabei nur, dass auf ein qualitativ gutes Theme zurückgegriffen wird. Der erste Schritt betrifft das Kopieren des PostNukeBlueVerzeichnisses. Kopieren Sie das postnuke/html/themes/PostNukeBlue-Verzeichnis an Ort und Stelle und benennen Sie das neue Verzeichnis entsprechend um, zum Beispiel nach PNKompendium. 8.4.1 Die Dateien eines Themes Das Verzeichnis postnuke/html/themes/PNKompendium besitzt folgende Verzeichnisstruktur: PNKompendium |- images |- lang |- style |- templates |- blocks |- modules style.css => IE, styleNN.css => alle anderen Browser 144 images: Hier können Sie Theme-bezogene Bilder ablegen, die beispielsweise im Header des Themes angezeigt werden sollen. lang: Darin befinden sich sprachabhängige Definitionen für die Ausgabe, beispielsweise für die Theme-bezogene Konfiguration im Xanthia-Modul. style: Hier befinden sich CSS-Dateien, die beim Laden einer Seite eingebunden werden und deren Layout bestimmen, z.B. bezüglich der Text- oder Tabellenformatierung. Für jedes Standard-Theme müssen die Style-Sheet-Dateien style.css und styleNN.css angelegt werden. styleNN.css enthält CSSKlassen, die von allen Browsern außer Internet Explorer interpretiert werden können, style.css dagegen nur diejenigen für den 8 Xanthia-Themes Internet Explorer. CSS-Angaben wie pn-title (definiert Überschriften), pn-sub (definiert kleingeschriebenen Text) und pnnormal (definiert normalen Text) sollten bis 0.750 Gold immer definiert werden, da diese von vielen offiziellen PostNukeModulen verwendet werden. templates: Hier werden die Template-Dateien zu einem Theme abgelegt. Die wichtigsten Template-Dateien im templates-Verzeichnis sind: master.htm: Definiert das Grobgerüst der Seite (meist dreispaltig: linker Blockbereich, zentrale Content-Spalte und rechter Blockbereich). News-article.htm: Layoutet die Darstellung eines Artikels in der Content-Spalte. News-index2.htm: Alternative Darstellung einer ArtikelAuflistung (siehe nachfolgenden Punkt). News-index.htm: Darstellung einer Artikel-Auflistung (meist Kurzdarstellung mit einem Link zur kompletten Artikelansicht). table1.htm: Definiert das Erscheinungsbild einer Tabelle, die im Theme-Kontext mit “table1” referenziert wird. table2.htm: Definiert das Erscheinungsbild einer zweiten Tabelle, die im Theme-Kontext mit “table2” referenziert wird. Die wichtigsten Template-Dateien im templates/blocks-Verzeichnis sind: ccblock.htm: Definiert die Darstellung eines zentralen Blocks (oberhalb des Inhaltsbereichs). lsblock.htm: Definiert die Darstellung eines linken Blocks. mainmenu.htm: Definiert allein die Darstellung des Hauptmenü-Blocks, unabhängig davon, ob er als linker oder rechter Block dargestellt wird. rsblock.htm: Definiert die Darstellung eines rechten Blocks. Im templates/modules-Verzeichnis können (alternative) Templates für einzelne Module hinterlegt werden, die Xanthia unterstützen. Diese Templates würden dann anstelle jener verwendet, die sich im entsprechenden Modul-Verzeichnis unter „pntemplates“ befinden. So können auch Module je nach gewähltem Template unter- 8.4 Theme erstellen 145 schiedliche Layouts/Funktionen erhalten. Wenn Sie diesen Mechanismus nutzen möchten, kopieren Sie alle Templates eines Moduls in themes/PNKompendium/modules/<modulname>, wenn das Modul <modulname> heißt. Das PostNukeBlue-Theme definiert z.B. für das News-Modul eigene Templates (wir aber nachher auch). Nachdem Sie nun einen Einblick in die Verzeichnisstruktur eines Themes und in die Templates erhalten haben, beschäftigen wir uns noch kurz mit den PHP-Dateien, die sich in unserem „PNKompendium“-Verzeichnis befinden. Tipp: Wenn Sie ein vorhandenes Theme kopieren, sollten Sie mindestens den Namen anpassen. theme.php: Hier finden sich die Xanthia-typischen Initialisierungen und Funktionsaufrufe. xaninfo.php: Hier definieren Sie allgemeine Informationen zu Ihrem Theme wie den Namen, die Autor(en), die zu verwendende Xanthia-API oder den XHTML-Support. In unserem Beispiel sollte der Inhalt wie folgt aussehen xaninit.php: Enthält initiale Konfigurationswerte eines jeden Themes. Als Anfänger werden Sie hier in der Regel keine größeren Änderungen vornehmen, allenfalls zusätzliche ThemeVariablen hinzufügen bzw. vorhandene Werte modifizieren. Dies können Sie an folgender Stelle vornehmen: // Create theme configuration variables // CreateThemeVar($skinID, , // , , ''); CreateThemeVar($skinID, 'lcolwidth',_ TM_LCOLWIDTH, '150px', ''); CreateThemeVar($skinID, 'rcolwidth',_ TM_RCOLWIDTH, '150px', ''); CreateThemeVar($skinID, 'pagewidth',_ 146 8 Xanthia-Themes TM_PAGEWIDTH, '100%', ''); CreateThemeVar($skinID, 'indexcol',_ TM_INDEXCOL, '1', ''); CreateThemeVar($skinID, 'righton',_ TM_RIGHTON, '0', ''); Diese Variablen sind später unter dem Link Administration – Xanthia Theme editieren ThemeEinstellungen editierbar. Je nach Anforderungen können hier weitere Variablen definiert werden. 8.4.2 Eigenes Theme als Beispiel An diesem Punkt erstellen Sie Ihr erstes eigenes – und zugegebenermaßen recht einfaches und schlichtes – Theme mit folgendem Aussehen: Abb. 8.2: So soll das Theme einmal aussehen 8.4 Theme erstellen 147 8.4.2.1 Xaninit.php Passen Sie die Datei xaninit.php an (meist den Theme-Namen in der CreatePalette-Anweisung). Löschen Sie zusätzlich alle Zeilen, die sich auf die PostNukeBlue-Datei home.htm beziehen. Löschen Sie auch die dazugehörige PostNukeBlue-home.htm aus dem themes/PNKompendium/templates/modulesVerzeichnis. 8.4.2.2 Master.htm Starten Sie anschließend mit der master.htm und definieren Sie ein Layout mit einer einzeiligen Tabelle, die drei Spalten besitzt. <meta http-equiv="Content-Type" content="text/html; charset="> <meta name="generator" content="PostNuke - http://postnuke.com"> <style type="text/css"> @import url(" /style/style.css"); 148 8 Xanthia-Themes 8.4 Theme erstellen 149 Damit haben Sie ihr Basis-Layout festgelegt und Sie können mit dem Layout der Artikel-Auflistung fortfahren (Newsindex.htm). 8.4.2.3 News-index.htm Wir verwenden dazu für jeden Artikel ein zweizeiliges Tabellenlayout, in dem die erste Zeile allgemeine Informationen und die zweite Zeile den Einleitungstext des Artikels enthält. Beachten Sie, dass dieses Template nicht einmal für den gesamten Artikel-Index, sondern pro Artikel jeweils einmal aufgerufen wird. <span> : <span> 150 8 Xanthia-Themes 8.4.2.4 News-article.htm Der nächste logische Schritt ist die Bearbeitung der Darstellung eines Artikels, der nach einem Klick auf den weiterlesen-Link komplett angezeigt werden soll. Dazu bearbeiten wir das Template News-article.htm. <span><strong> <span> : 8.4 Theme erstellen 151 cellspacing="0" width="100%">   Das Template zeigt Links für die druckerfreundliche Version und die Versandmöglichkeit des Artikels an; zusätzlich erhält der Admin weitere Links wie Editieren/Löschen. 8.4.2.5 Block-Templates Jetzt müssen noch die (maximal vier) Block-Templates aus postnuke/html/themes/PNKompendium/templates /blocks gestaltet werden. Der Einfachheit halber bekommt jeder Block in unserem Theme das gleiche Layout: Beachten Sie, dass Sie den Mainmenu-Block nur anpassen müssen, wenn Sie auf Ihrer Seite auch wirklich einen Block namens Main Menu verwenden. Dies scheint ein fest verdrahteter Mechanismus in PostNuke zu sein. 8.4.2.6 styleNN.css Lassen Sie uns abschließend noch die Datei styleNN.css anpassen: 152 8 Xanthia-Themes BODY, FONT, SPAN, TD, P, INPUT, SELECT { font: normal 11px/120% Arial, Helvetica, sans-serif; } TEXTAREA, BODY { background: white; margin: 0px; } LI { margin: 0px; } IMG { border: 0px; } A:link, A:visited { color: #000000; } A:hover, A:active { color: #000000; font-variant: normal; } /* Main column styles */ .LeftCol, .RightCol { vertical-align: top; text-align: left; padding-top: 10px; padding-left: 4px; padding-right: 4px; border: 1px solid #000000; } .CenterCol { vertical-align: top; text-align: left; padding-top: 10px; padding-left: 4px; padding-right: 4px; border-top: 1px solid #000000; border-bottom: 1px solid #000000; } .footer { border: 0px; text-align: center; padding: 15px; 8.4 Theme erstellen 153 margin: auto; } /* PN styles */ .pn-normal { } .pn-title { } .pn-sub { } Ihr erstes eigenes Theme ist damit erstellt und wartet auf weitere Verbesserungen, z.B. in Design und Verwendung von Grafiken. 8.4.3 Im Beispiel verwendete Variablen Die bis hier verwendeten Smarty-Variablen sind tweilweise in der xaninit.php definiert oder bezeichnen interne PostNuke- sowie Modul-Eigenschaften. $pagewidth steht beispielsweise für eine Modulvariable (hier von Xanthia), pnml name=_PN_VERSION_NUM für eine PostNuke-Konstante. 154 Allgemein: charset, keywords, lang, sitename, slogan, title Benutzer: $info.informant Breiten: $pagewidth, $lcolwidth, $rcolwidth Funktionen: count_words, articleadminlinks sid=$info.sid Informationen: footmsg, pagerendertime, typetoolv80 Inhalte: $content, $leftblocks, $maincontent, $rightblocks, $title News: $info.counter, $info.fulltext, $info.hometext, $info.sid, $preformat.catandtitle, $preformat.print, $preformat.notes, $preformat.searchtopic, $preformat.send Pfade: $imagepath , $themepath Konstanten: _ON, _PN_VERSION_NUM, _POSTEDBY, _READS, _WORDSMORE Sonstige: additional_header, modulestylesheet 8 Xanthia-Themes Zeit: $info.longdatetime 8.4.4 Valider HTML-Code Sie können über die Homepage des W3C überprüfen, ob Ihr Theme HTML-valide ist. Leider wird dies auch bei sorgfältigsten ThemeEntwürfen kaum ohne Änderungen am PostNuke-Sourcecode gelingen, da einige Module oder API-Funktionen einfach keinen gültigen HTML-Code erzeugen. Das Einschalten der Funktion Eingebettete HTML-Entitäten in normale Zeichen wandeln unter Administration – Einstellungen schafft nur partielle Abhilfe. http://validator. w3.org 8.5 pnRender Es soll an dieser Stelle auf die wichtigsten Optionen in der pnRender-Administration eingegangen werden: Kompilieren erzwingen: Aktivieren Sie diese Checkbox, falls immer kompiliert werden soll. Damit erhöht sich die Anzahl der Datenbankzugriffe drastisch. Aus diesem Grund ist diese Einstellung standardmäßig deaktiviert. Kompilierte Templates löschen: Durch Klick auf diesen Link werden alle bis zu diesem Zeitpunkt angelegten TemplateDateien aus dem Cache gelöscht. Beachten Sie, dass hier das Caching für pnRender und nicht von Xanthia gemeint ist. Caching einschalten: Aktivieren Sie diese Checkbox, um die Performance des Systems zu erhöhen. Beachten Sie, dass auch hier das Caching für pnRender gemeint ist. 8.6 Zusammenfassung Das Kapitel gab eine Einführung in Xanthia. Die Administration wurde ebenso erläutert wie die Anpassung vorhandener und die Erstellung eines neuen eigenen Themes. 8.5 pnRender 155 8.7 Ausblick Es folgt die Beschreibung der PostNuke-Verzeichnisstruktur. 156 8 Xanthia-Themes 9 Die PostNukeVerzeichnisstruktur 9.1 Das PostNuke-Verzeichnis +---(Root) admin.php: dient der Administration des Systems (falls AdminRechte vorhanden). config.php: Konfigurations-Daten zur Datenbankanbindung. error.php: Funktionen zur Fehlerbehandlung. header.php: erzeugt den Headers der jeweils aufgerufenen Seite. index.php: ist der generelle Einstiegspunkt einer PostNukeSeite. install.php: wird für die Installation eines PostNuke-Systems benötigt und aufgerufen. Muss nach der Installation gelöscht werden. modules.php: dient der Administration von Modulen. pntables.php: zuständig für die systeminterne Veröffentlichung von Modul-Tabellen. print.php: zur Anzeige von Seiten des Stories-Moduls in druckfreundlichem Format. user.php: bietet Funktionen zur Verwaltung der persönlichen Benutzerprofile. +---docs Hier befinden sich Dokumente mit allgemeinen Informationen zum PostNuke-System. 9.1 Das PostNuke-Verzeichnis 157 changelog.txt gibt Aufschluss auf Änderungen seit dem letzten Release credits.txt beinhaltet die Namen der PostNuke-Entwickler auf der ganzen Welt und deren Engagement bei PostNuke manual.txt liefert Informationen über die Installation und Upgrade-Möglichkeiten. +---images Ordner mit globalen Bildern des PostNuke-Systems | | | | | | | | | +---avatar Die hier befindlichen Bilder können Benutzer in ihrem Profil auswählen. +---banners Werbe-Banner für das Banners-Modul +---flags Im flags-Ordner sind Länderflaggen unterschiedlicher Nationen abgelegt. +---menu Im menu-Ordner sind Bilder für die Ansicht „My Accounts“ eines jeden Benutzers abgelegt. +---powered Logos von Dritt-Software, die im PostNuke-Umfeld genutzt wird. +---reviews Bilder zum Review-Modul +---sections Hier abgelegte Bilder kennzeichnen verschiedene Sektionen (Sections-Modul) +---smilies Smilies-Grafiken, verschiedentlich im System genutzt. +---topics Logos für jedes im Topic-Modul definierte Thema +---includes Enthält u.a. pnapi.php (API zum System), pnMod.php (alle API-Funktionen bezüglich der Modulbehandlung), pnSession.php (alle API-Funktionen zum Session-Handling), pnUser.php (alle API-Funktionen zur Benutzerbehandlung). | 158 +---blocks Alle Blöcke, die nicht zu einem Modul gehören (so genannte Core-Blöcke) 9 Die PostNuke-Verzeichnisstruktur | | | | +---classes PHP-Klassen, z.B. für Smarty zur Nutzung der TemplatingFunktionalität mit XTE +---language Sprachdateien zu den verschiedenen Blöcken. +---search Pro Modul wird hier ein Search-Plugin gespeichert, welches die modulspezifische Suche und die Ausgabe der ErgebnisListe implementiert. +---install Ordner mit allen Dateien, die nur während einer Installation benötigt werden. Muss nach der Installation unbedingt gelöscht werden. +---javascript Alle JavaScript-Ressourcen inklusive zugehöriger PHPund HTML-Dateien. +---language Beinhaltet alle Core-Sprachdateien, aufgeteilt nach Sprache (für verwendete Verzeichniskürzel siehe Kapitel Sprachpakete und Sprachentabelle). +---modules Beinhaltet alle PostNuke-Module. Für jedes Modul existiert ein Unterordner mit dem Namen des Moduls. Siehe auch Modulbeschreibung im Kapitel Module. +---pnadodb Alle Dateien der ADODB-Bibliothek, welche der Kommunikation mit Datenbank-Servern dient. +---pnTemp Ablage für temporäre Dateien. Hier finden sich auch Dateien wie .htaccess (zur Zugriffssteuerung des pnTemp-Verzeichnisses), pntemp.xml (enthält Informationen zur Anwendung des pnTemp-Verzeichnis im XML-Format, vorwiegend für Modulentwickler interessant). | +---adodb Temporäre Dateien für ADODB. +---pnRender_cache Temporär gecachte Dateien des pnRender-Moduls. | 9.1 Das PostNuke-Verzeichnis 159 | | | | +---pnRender_compiled Bereits compilierte Dateien des pnRender-Moduls. +---Xanthia_cache Temporär gecachte Dateien des Xanthia-Moduls. +---Xanthia_compiled Bereits compilierte Dateien des Xanthia-Moduls. +---Xanthia_Config Temporär gespeicherte Xanthia-Konfigurationen. +---themes Alle Dateien zu den jeweiligen Themes. Neben StandardThemes werden hier auch selbst definierte Themes abgelegt. Pro Theme gibt es ein Unterverzeichnis mit dem Namen des jeweiligen Themes. 9.2 Beispiel: language, modules und themes 9.2.1 Verzeichnis language/eng Dieses Verzeichnis ist für die englische Sprache zuständig. admin.php: alle Sprachdefinitionen für /admin.php banners.php: alle Sprachdefinitionen für banners.php error.php: alle Sprachdefinitionen für error.php global.php: alle Sprachdefinitionen, genutzt im globalen Kontext des Systems (globale Ausgaben). user.php: alle Sprachdefinitionen für user.php 9.2.2 Verzeichnis modules/Template Enthält ein Modul, welches als Basis zur Entwicklung eigener Module verwendet werden kann. 160 9 Die PostNuke-Verzeichnisstruktur pnblocks: beinhaltet eine Datei für den zum Modul gehörigen Block (first.php). Hier werden sämtliche Modul-Blöcke abgelegt. pnimages: Bilder, die im Modul genutzt werden. pnlang: beinhaltet Sprachdefinitionen (im Unterverzeichnis 'eng'): admin.php, first.php, init.php, pnblocks.php, user.php, userapi.php, jeweils für die entsprechenden Dateien. pntemplates: Ablageort für Schablonen der Xanthia-Engine. Hier befindet sich auch der Unterordner plugins, dessen Dateien mittels eines Tags als neue Funktionen in die htm-Templates eingebunden werden können. pnadmin.php: enthält alle Funktionen zur Erzeugung des Outputs in der Administrationsoberfläche des jeweiligen Moduls. pnadminapi.php: liefert allgemeine Funktionen für pnadmin.php. pninit.php: enthält Funktionen zur Erzeugung bzw. Entfernung der Tabellen und Modulvariablen. pntables.php: enthält Tabellendefinitionen für ein PostNukeModul. pnuser.php: enthält alle Funktionen zur Erzeugung des Outputs der Benutzeroberfläche eines PostNuke-Moduls. pnuserapi.php: liefert allgemeine Funktionen für pnuser.php. pnversion.php: beinhaltet allgemeine Angaben zum PostNukeModul 9.2.3 Verzeichnis themes/ExtraLite Dieses Verzeichnis enthält das einfachste, nicht Xanthia-konforme Standard-Theme des PostNuke-Systems. images: enthält alle für das Theme relevanten Bilder. style: enthält alle für das Theme relevanten CSS Definitionen (unterschieden nach Netscape-Styles und IE-Styles). theme.php: enthält Funktionen, die die einzelnen AusgabeKomponenten des Systems im HTML-Code erzeugen, Header, Footer, News-Index, Stories-Article, Blöcke sowie Tabellendefinitionen 9.2 Beispiel: language, modules und themes 161 9.2.4 Verzeichnis themes/Postnuke In diesem Xanthia-basierten Theme wird die HTML-Ausgabe, welche zuvor noch direkt in der theme.php definiert war, in ein Template verlagert. Das Template wird dabei von pnRender mit Inhalt gefüllt. Damit enthält die theme.php keinen einzigen HTML-Befehl mehr. Folgende Unterordner und Dateien sind hier zu finden: lang: Sprachkonstanten zur Nutzung innerhalb des XanthiaThemes. Wie überall in PostNuke sind diese in sprachspezifischen Ordnern abgelegt. templates: enthält die Smarty-Templates für die StandardAusgabe (master.htm, News-article.htm, News-index.htm, table1.htm, table2.htm). xaninfo.php: enthält Informationen zum Autor und zur Version des Themes xaninit.php: enthält allgemeine Informationen, die bei der Aktivierung des Themes benötigt werden 9.3 Zusammenfassung Sie haben nun einen Überblick über die Verzeichnisstruktur und die wichtigsten Dateien eines PostNuke-Systems erhalten. 9.4 Ausblick Von der Logik her folgt jetzt ein Überblick über alle SQL-Tabellen einer Standard-PostNuke-Installation. 162 9 Die PostNuke-Verzeichnisstruktur 10 Datenbank-Tabellen einer PostNuke-Installation Dieses Kapitel listet die Datenbank-Tabellen einer PostNuke 0.750 Gold Standard-Installation auf und gibt an, welche Module auf die einzelnen Tabellen zugreifen. So können Sie nach einer Deinstallation eines Moduls oder zur Optimierung einer PostNuke-Installation abschätzen, welche Tabellen gelöscht werden können und welche nicht. Tabelle Verwendet von Modul autolinks autonews banner bannerclient bannerfinish blocks blocks_buttons comments AutoLinks (NS-)AddStory, (NS-)Admin, News (NS-)Banners (NS-)Banners (NS-)Banners Blocks, News, Xanthia Kernel (NS-)Comments, (NS-)User, Reviews, Stats, Topics, XMLRPC Kernel, (NS-)AddStory, (NS-)NewUser, Sections, Stats, Topics, Top_List Downloads, TopList Downloads, TopList Downloads Downloads Downloads Downloads Downloads (NS-)Ephemerids FAQ counter downloads_categories downloads_downloads downloads_editorials downloads_modrequest downloads_newdownload downloads_subcategories downloads_votedata ephem faqanswer 9.4 Ausblick 163 faqcategories groups group_membership group_perms groups headlines hooks languages_constant languages_file languages_translation links_categories links_editorials links_links links_modrequest links_newlink links_votedata message module_vars modules poll_check poll_data poll_desc pollcomments priv_msgs queue quotes ratings ratingslog realms referer related reviews reviews_add reviews_comments reviews_main seccont sections 164 FAQ (NS-)Groups, (NS-)NewUser, (NS-)User (NS-)Groups, (NS-)NewUser, (NS-)User (NS-)Groups, Permissions (NS-)Groups, Permissions - (nur RSS2-Block) Modules (NS-)Languages (NS-)Languages (NS-)Languages Stats, Web_Links Web_Links Stats, Web_Links Web_Links Web_Links Web_Links (NS-)Admin_Messages Modules Autolinks, Modules, Xanthia (NS-)Polls (NS-)Polls, TopList (NS-)Polls, TopList (NS-)Polls Messages (NS-)AddStory, (NS-)Admin, Stats, Submit_News (, Menu-Block) Quotes Ratings Ratings Permissions (NS-)Referers News, Topics Reviews, TopList Reviews Reviews Reviews Sections, Stats, TopList Sections, Stats 10 Datenbank-Tabellen einer PostNuke-Installation session_info stats_date stats_hour stats_month stats_week stories stories_cat theme_addons theme_blcontrol theme_cache theme_config theme_layout theme_palette theme_skins theme_tplfile theme_tplsource theme_zones topics user_data user_perms user_property userblocks users Members_List, (NS-)User Stats Stats Stats Stats AvantGo, News, (NS-)AddStory, (NS)Admin, (NS-)User, Recommend_us, Stats, Topics, TopList, xmlrpc AvantGo, News, (NS-)AddStory, (NS)Admin, Recommend_us, TopList Xanthia Xanthia Xanthia Xanthia Xanthia Xanthia Xanthia Xanthia Xanthia Xanthia AvantGo, (NS-)Admin, Recommend_us, Stats, Submit_News, Topics, xmlrpc (NS-)User (NS-)User, Permissions (NS-)NewUser, (NS-)User, (NS)Your_Account Blocks Members_List, News, (NS-)MailUsers, (NS-)NewUser, (NS-)User, Stats, TopList, xmlrpc 9.4 Ausblick 165 11 Multisites In diesem Kapitel erfahren Sie, wie mit genau einem PostNukeSystem mehrere Web-Präsenzen gleichzeitig betrieben werden können, die jeweils für sich unter einer eigenen Domain zu erreichen sind – sinnvoll, sobald Sie in Ihrer eigenen Internetpräsenz mehrere, gestalterisch unterschiedliche Bereiche einrichten oder kunden- bzw. partnerspezifische Extranets anbieten möchten. So können Sie leicht Internetpräsenzen im Corporate Identity Ihres Kunden oder Partners anbieten, ohne für jeden ein eigenes PostNuke-System pflegen zu müssen. Bevor Sie mit der Einrichtung eines Multisite-Systems beginnen, sollten Sie sich über die Struktur Ihrer Site Gedanken machen. Neben der Frage, wie der Content dargestellt werden soll, sind weitere Punkte: die Beachtung einer möglichen Erweiterbarkeit sowie eine transparente – nicht zu komplexe – Gesamtorganisation des Systems, um mögliche Probleme bei einer Erweiterung zu vermeiden. Insbesondere sollten Sie sich Gedanken über eine Ordnung der Inhalte machen – welche Artikel, Downloads, Links etc. sollen auf allen Sites vorhanden sein, welche nur auf einigen, welche nur auf einer bestimmten Site? Durch eine dazu passende Wahl von Topics und Kategorien machen Sie sich später die Zuordnung zu einzelnen Sites und die Rechtevergabe leichter. 9.4 Ausblick 167 11.1 Einrichtung des Webservers Für die Implementierung von Multisites muss PostNuke lediglich bekannt sein, auf welchen Server (auch „Host“ genannt) ein Besucher zugreifen möchte. Dies kann prinzipiell nach jedem Kriterium entschieden werden, das verfügbar ist - Hostname, Sprache, eingesetzter Browser, angeforderter URL und viele weitere sind denkbar. Im folgenden konzentrieren wir uns aber auf die wohl am häufigsten auftretende und im Lieferumfang des Multisites-Moduls implementierte Anforderung, bei der über den Hostnamen die Site ausgewählt wird. Der Apache Webserver und viele weitere Webserver bieten die Möglichkeit, sogenannte „virtuelle Hosts“ einzurichten. Jeder virtuelle Host erhält einen eigenen Hostnamen, bei Apache der „ServerName“. Sie müssen sicherstellen, dass diese Hostnamen auch aufgelöst werden können. Das zu überprüfen ist recht einfach – Apache verweigert den Start, wenn ein Servername nicht aufgelöst werden kann. Wenn außer dem Hostnamen keine signifikanten Konfigurationsunterschiede zwischen den Sites bestehen – was in der Regel zutrifft und in diesem Beispiel angenommen werden soll – so genügt es sogar ausschließlich mit einem Server-Alias zu arbeiten. Damit reduziert sich der Konfigurationsaufwand drastisch. Ein Beispiel für diesen Weg sehen Sie in der nachfolgenden Abbildung. ServerName www.yoursite.de ServerAlias domain1.yoursite.de www.domain2.de ServerAdmin [email protected] DocumentRoot C:/htdocs/yoursite DirectoryIndex index.php 168 11 Multisites Eingerichtet sind hier ein virtueller Host namens eine Sub-Domain www.yoursite.de, domain1.yoursite.de und eine zusätzliche Hauptdomain www.domain2.de. Auf Seiten des PostNuke-Systems sind deutlich mehr Punkte zu konfigurieren. Als Basis dient hier das Modul (NS)Multisites. Entgegen der Erwartung und auch anderslautender Dokumentationen zu diesem Thema müssen Sie dieses Modul jedoch nicht aktivieren. Es dient lediglich als Lieferant von einigen Dateien, die manuell in bestimmte Verzeichnisse kopiert werden müssen. Es wird angenommen, dass sämtliche genannten Domains für Sie registriert und die DNSEinträge von Ihrem Provider entsprechend eingerichtet sind (gilt für InternetZonen). Zur Einrichtung der gewünschten Funktionalität sind nachfolgende Schritte durchzuführen: 1. Erzeugen Sie im PostNuke-Hauptverzeichnis ein Verzeichnis namens parameters. 2. Erzeugen Sie darin jeweils ein Unterverzeichnis für jede Site, die Sie einrichten möchten (wir empfehlen immer den Hauptteil einer Domain als Namen des Verzeichnisses zu vergeben). In unserem Beispiel erstellen wir die drei Unterverzeichnisse yoursite, domain1.yoursite und domain2. 3. In jedem Site-Verzeichnis erzeugen Sie die beiden Unterverzeichnisse images und themes, in denen jeweils die Sitespezifischen Bilder und PostNuke-Themes abgelegt werden. (Wir empfehlen, in jedes images-Verzeichnis eine Bild-Datei logo.gif abzulegen, da nahezu jedes Standard-Theme darauf verweist) 4. Kopieren Sie die Datei whoisit.inc.php aus dem Verzeichnis modules/NS-Multisites/installation in das parameters-Verzeichnis und passen es gemäß Ihren Anforderungen an (die Methodik erläutern wir im Anschluss an diese Auflistung). 5. Kopieren Sie die Datei config.php aus dem Hauptverzeichnis in jedes Site-Unterverzeichnis im parametersVerzeichnis. 6. Ersetzen Sie die originale Datei config.php im Hauptverzeichnis (nachdem Sie diese gesichert haben) mit der Konfigurations-Datei aus dem Verzeichnis modules/NSMultisites/installation. 11.1 Einrichtung des Webservers 169 7. Löschen Sie gegebenenfalls das allgemeine themesVerzeichnis, wenn Sie verhindern möchten, dass in den unterschiedlichen Sites auch die allgemeinen Themes selektiert werden können. Damit haben Sie die Grundvoraussetzungen für ein funktionierendes Multisite-PostNuke-System geschaffen. Die neue allgemeine config.php bindet die Datei whoisit.inc.php ein, welche anhand des Servernamens entscheidet, in welches der Unterverzeichnisse aus dem parameters-Verzeichnis verzweigt wird. Sie ist also eine Art Steuerdatei, die natürlich gemäß den zuvor überlegten Strukturen einzurichten ist und sich zwangsläufig von System zu System unterscheidet. 11.2 Einrichtung unterschiedlicher Themes Achtung: Bis zur Drucklegung dieses Buchs befand sich ein Bug im Xanthia-Modul, welcher dafür verantwortlich ist, dass XanthiaThemes in einem parameters-Unterverzeichnis nicht erkannt werden. Nach Analyse der Autoren beruht dieser Effekt auf hart verdrahteten Verzeichnisangaben, die nicht mehr gelten, wenn Multisites eingerichtet sind. Zwar könnte man diesen Effekt vermeiden, indem man die Xanthia-Themes im Standardverzeichnis belässt, womit es aber keine getrennte Optik der Sites geben würde. Möglicher Workaround: Bugfixing oder Verwendung von nicht Xanthia-konformen Themes. Beschäftigen wir uns jetzt mit den Feinheiten der Einrichtung, im Besonderen mit der Konfiguration der Datei whoisit.inc.php. 170 11 Multisites "", $serverName); $serverName = str_replace(".net", "", $serverName); $serverName = str_replace(".com", "", $serverName); ?> Wie Sie sehen können, wird mit der globalen Variablen $SERVER_NAME gearbeitet, die jeweils den in der URL angegebenen Servernamen enthält. Anhand von Zeichenkettenersetzungen wird die Variable $serverName so gesetzt, dass der entsprechende Verzeichnisname entsteht und damit in das Unterverzeichnis unterhalb von parameters umgelenkt wird. Dies geschieht durch das Setzen der Konstante WHERE_IS_PERSO in der Datei config.php. Beachten Sie, dass in PHP der Schalter register_globals auf On steht, da auf globale Servervariablen ($SERVER_NAME) zugegriffen wird. Dies ist nicht die Standardeinstellung aktueller PHPVersionen, so dass Sie insbesondere bei Providern, die die Konfiguration nicht ändern, auf Probleme stoßen werden. Eine korrigierte und bessere Alternative dieser Datei zeigen wir im weiteren Verlauf. Nachfolgend zeigen wir noch die neue config.php aus dem Hauptverzeichnis. In unserem Beispiel werden wir für die Verzeichnisse yoursite, domain1.yoursite und domain2 die Präfixe und Suffixe www. und .de entfernen. Eine von uns angepasste whoisit.inc.php sieht dann – reduziert auf das Nötigste – wie folgt aus. 11.2 Einrichtung unterschiedlicher Themes 171 In der originalen whoisit.inc.php steht fälschlicherweise nur www ohne abschließenden Punkt Der Source-Code zeigt es: benennen Sie Ihre parametersUnterverzeichnisse nach den zu verwendenden Domain-Namen, aber trotzdem so kurz und aussagekräftig wie möglich. Wenn Sie zwei Domains www.domain1.de und www.domain2.de betreiben wollen, genügt domain1 und domain2 als Verzeichnisname. Bei Domains der Art www.mydomain.de und www.mydomain.com muss die Toplevel-Domain ebenfalls im Verzeichnisnamen auftauchen (dann muss aber die whoisit.inc.php angepasst werden). Bei der Eingabe der Adresse www.yoursite.com würde die Konstante den Wert WHERE_IS_PERSO parameters/yoursite/ besitzen. Wir verwenden statt der Variable $SERVER_NAME nun $_SERVER['HTTP_HOST'], da uns dies ein register_globals=On in der PHP-Konfiguration spart und auch bei virtuellen Servern mit Server-Aliasen den richtigen Hostnamen enthält. $_SERVER enthält alle Werte, die vom Webserver gesetzt wurden. Wenn Sie auf andere Werte zur Auswahl der Site zurückgreifen möchten, dann sollten Sie diese auch nur aus diesem Array beziehen. 11.3 Einrichtung unterschiedlichen Contents Da sich in jedem Theme-Verzeichnis auch eine config.php befindet, die die Aufgabe der ehemaligen originalen Datei aus dem Hauptverzeichnis übernimmt, haben Sie bei der Konfiguration völlig freie Hand. 172 11 Multisites Die einfachste Content-Trennung erreicht man über die Einrichtung von je einer Datenbank pro Site. Anschließend wird jede config.php entsprechend angepasst. Damit handelt man sich jedoch auch einen nicht unerheblichen Administrations-Overhead ein: im Prinzip entstehen so lauter „Singlesites“, in denen Benutzer, Gruppen, Berechtigungen, usw. immer separat eingerichtet und verwaltet werden müssen. Der einzige Vorteil einer solchen Umgebung läge in der gemeinsamen Datei-Basis für alle Installationen Wir schlagen vor, mindestens die Benutzer sowie die Gruppen gemeinsam zu konfigurieren, um sie dann über unterschiedliche Berechtigungen innerhalb der jeweiligen Sites voneinander abzugrenzen. Wie bewerkstelligt man, dass man zwar dieselbe Datenbank verwendet, dann aber bestimmte Inhalte nur spezifischen Sites zuweist? Ein wichtiger Aspekt für die Beantwortung dieser Frage ist die Datenbankstruktur des PostNuke-Systems. Fast jedes Modul besitzt mindestens eine eigene Tabelle. Die Namen dieser Tabellen sind im Kapitel Datenbank-Tabellen einer PostNuke-Installation oder in der Datei postnuke/html/pntables.php definiert. In Analogie zur Datei config.php sorgt man dafür, dass jede Site ebenfalls eine angepasste pntables.php im entsprechenden Site Verzeichnis erhält (etwa in parameters/yoursite). Wenn nun beispielsweise in einer Site komplett andere Stories angeboten werden sollen, so erstellt man in der MySQL-Datenbank zuerst eine zur Stories-Tabelle strukturgleiche Tabelle mit neuem aussagekräftigen Namen. Hier könnte beispielsweise der Verzeichnisname der Site als zusätzliches Suffix herangezogen werden. Im Anschluss daran trägt man in der jeweiligen Datei pntables.php den veränderten Namen ein. Würden Sie also die Tabelle nuke_stories_yoursite erzeugen, so müssten Sie in der Datei pntables.php im Verzeichnis parameters/yoursite die Zeile $stories = $prefix . '_stories'; in $stories = $prefix . '_stories_yoursite'; ändern. Sie sollten diese Art der Konfiguration grundsätzlich für die Benutzer, Gruppen und Berechtigungen umsetzen. So kann jede Site einzelne Berechtigungsstufen besitzen, und Sie können das System gleichzeitig so konfigurieren, dass beispielsweise nicht grundsätzlich alle Inhalte unterschiedlich sein müssen, sondern nur ein paar wenige. Die Freigaben könnten dann pro Site über Zugriffsrechte auf ein spezielles übergeordnetes Kriterium ermöglicht werden. Im Falle der 11.3 Einrichtung unterschiedlichen Contents 173 Artikel wären dies die Topics oder Kategorien. Dies gilt analog natürlich auch für Downloads, Weblinks, usw. Auch Module und Blöcke lassen sich auf unterschiedlichen Multisites unterschiedlich präsentieren. Geht es lediglich darum, dass ein Block oder Modul auf einer bestimmten Site verfügbar ist, so kann dies über das Berechtigungssystem konfiguriert werden. Schwieriger, aber nicht unmöglich ist es, ein Modul mit jeweils abweichender Konfiguration auf mehreren Sites zu betreiben. Ein Beispiel ist das Wetter-Modul. Sie könnten als kleines Gimmick auf den Extranet-Sites das Wetter am Standort Ihres Kunden oder Partners anzeigen. Auch dazu sollten Sie wieder einzelne Tabellen anlegen, die dann die site-spezifischen Modul- oder Blockkonfiguration beinhalten. Eine Kopie des Moduls unter einem anderen Namen abzulegen ist dagegen keine saubere Lösung – dazu ist der Name eines Moduls bei dessen Programmierung zu wichtig und findet sich so an vielen Stellen im Quelltext. Auch das Update eines abgeleiteten Moduls ist extrem aufwendig. Darüber hinaus macht Ihnen hier PHP aufgrund doppelter Deklarationen einen Strich durch die Rechnung. Die Erfahrungen im Umgang mit Multisites kommen bei der praktischen Anwendung dieser Funktion. Das Konzept hat viele Vorteile: es ermöglicht die zentrale Administration vieler Sites, die Datei-Basis ist für alle Installationen die gleiche und ermöglicht zentrale Updates usw. Die Nachteile: es erfordert eine hohe Sorgfalt im Umgang mit der Konfiguration und der Datenbank, die Content-Strukturen wollen wohlüberlegt sein etc. Letztlich müssen Sie anhand der zu erwartenden Kosten entscheiden: ist es günstiger, mehrere Sites auf verschiedenen PostNuke-Installationen zu pflegen oder verschiedene Sites auf einer Installation – meist bewährt sich eine gesunde Mischung aus beidem. 11.4 Zusammenfassung Mit Multisites können mehrere Präsenzen mit unterschiedlichem Layout und Content mit nur einer PostNuke-Installation realisiert werden. Der Teufel steckt jedoch im Detail; eine sorgfältige Planung des Auftritts ist hier unerlässlich. 174 11 Multisites 11.5 Ausblick Die Sicherung und Wiederherstellung von PostNuke sowie das Rücksetzen misslungener Konfigurationen wird im Anschluss beschrieben. 11.5 Ausblick 175 12 Troubleshooting, Backup und Recovery 12.1 Das PostNuke Swiss Army Knife (PSAK) Das PostNuke Swiss Army Knife (PSAK) macht das, was sein Name ausdrückt: es ist ein kleines Universalwerkzeug zur Lösung der elementarsten Probleme, die nach Fehl-Konfigurationen in PostNuke auftreten können. psak.php von http://news. postnuke.com/ Downloads.html Beachten Sie: PSAK hilft Ihnen bis zur Version 1.01 nicht weiter, wenn Sie Ihr Administrator-Passwort vergessen haben. In diesem Fall werfen Sie bitte einen Blick in das Kapitel Tipps & Tricks zu PostNuke. Die Installation von PSAK besteht aus dem Herunterladen der psak.php und der Ablage der Datei im Stammverzeichnis Ihrer PostNuke-Installation. Rufen Sie das Tool anschließend im Browser über postnuke/html/psak.php auf. Es erscheint das nachfolgende Menü. Kodierung DB Benutzername/-Passwort: Verwenden Sie diese Option, wenn sich Ihre Datenbank-Zugangsdaten geändert haben, Sie daher Ihre config.php anpassen müssen, aber die Zugangsdaten nur codiert ablegen wollen. Verwechseln Sie diese Option nicht mit einer „Admin-Passwort-vergessen-undwiederherstellen“-Funktion. 'Intranet'-Konfiguration ein-/ausschalten: Sie haben die Intranet-Konfiguration versehentlich falsch gesetzt und können sich nun nicht mehr einloggen? Mit dieser Funktion können Sie die Intranet-Konfiguration im Wechsel ein- oder ausschalten. 12.1 Das PostNuke Swiss Army Knife (PSAK) 177 Theme Reset: Diese Funktion wird verwendet, wenn Sie ein fehlerhaftes Theme aufgespielt, aktiviert und als StandardTheme eingerichtet haben und nun feststellen, dass Sie damit Ihr PostNuke-System nicht mehr verwenden können. Über das Setzen des Themes „ExtraLite“ (oder eines anderen unmodifizierten und damit funktionierenden Standard-Themes in PostNuke) erhalten Sie dann wieder Zugriff auf Ihre Seite. Anschließend können Sie die Theme-Fehler korrigieren. Permissions Reset: Nützlich, wenn Sie die Zugriffsrechte Ihrer Site modifiziert und sich selbst durch einen Fehler für immer und ewig aus Ihrem eigenen System ausgesperrt haben. Die Funktion erlaubt das wahlweise Zurücksetzen von Benutzerund Gruppenrechten auf Standard-Einstellungen, je nach dem, was Sie geändert haben. PHPInfo anzeigen: zeigt detaillierte technische Informationen über Ihre Serverumgebung an. Vergessen Sie nach getaner Rettungsarbeit niemals, PSAK wieder aus dem Verzeichnis zu entfernen, um Zugriff durch Dritte zu verhindern. PostNuke wird Sie sicherheitshalber zusätzlich dezent darauf hinweisen. 12.2 Backup Das Backup einer PostNuke-Installation gliedert sich in die Bereiche Backup der Dateien Sicherung der Datenbank-Tabellen, die im Betrieb einer PostNuke-Seite ständigen Änderungen unterworfen sind. Wir empfehlen vor der Durchführung der nachfolgend beschriebenen Schritte kurzfristig den Web- und den Datenbank-Server zu stoppen, um Inkonsistenzen in den Daten entgegenzuwirken. 12.2.1 Dateien sichern Kopieren Sie alle Dateien aus dem PostNuke-Installationsverzeichnis in einen Backup-Ordner Ihrer Wahl. Idealerweise kompri- 178 12 Troubleshooting, Backup und Recovery mieren Sie die Dateien und vergeben einen geeigneten Namen, etwa durch Hinzufügen des aktuellen Datums (z.B. postnuke20050310.zip, wenn das Backup am 10. März 2005 erzeugt wurde). 12.2.2 Datenbank sichern Die Verwendung von phpMyAdmin ist eine Möglichkeit, um die MySQL-Datenbank zu sichern. Sie können dessen Export-Funktion nutzen, um ein komplettes Abbild der Datenbank zu erzeugen. Öffnen Sie dazu ein Browser-Fenster und geben Sie den Pfad zu Ihrer phpMyAdmin-Installation ein (beispielsweise http://datenbankserver/phpmyadmin). 1. Wählen Sie im linken Frame in der Übersicht der vorhandenen Datenbanken die Datenbank aus, die die PostNuke-Tabellen enthält. 2. Der rechte Frame wird neu geladen. 3. Klicken Sie im rechten Frame den Reiter Exportieren an. 4. Klicken Sie in den nun erscheinenden Optionen unter Exportieren den Link Alle auswählen an. 5. Aktivieren Sie die Checkbox Senden, um den Dump aller PostNuke-Tabellen zum Download angeboten zu bekommen. Wir empfehlen als Dateinamenskonvention den Eintrag __DB__-%Y%m%d. Damit wird die Dump-Datei automatisch nach dem Datenbanknamen, gefolgt vom aktuellen Datum im Format JJJJMMTT benannt. Klicken Sie im Anschluss auf die Schaltfläche OK, um den Export herunterzuladen. Je nach Datenaufkommen kann ein Export relativ groß werden, was beim Import zu Problemen führen kann, da dann die maximale Laufzeit eines Skripts überschritten wird (Meldung: Maximum execution time exceeded; erscheint bei einer StandardInstallation von PHP nach 300 s). Die einzige Möglichkeit dies zu umgehen besteht in der Aufteilung des SQL-Dumps in mehrere kleine Dateien, um diese dann eine nach der anderen zu importieren. Statt beispielsweise phpMyAdmin zur Sicherung zu verwenden, genügt es auch, alle Dateien unterhalb von mysql/data/nameder-postnuke-datenbank zu sichern. 12.2 Backup 179 12.3 Recovery Die Wiederherstellung ist einfach: alle Dateien aus dem Backup in die Document Root des Webservers kopieren, die Datenbank in MySQL neu aufsetzen und die SQL-Daten aus dem Backup importieren (in phpMyAdmin nach der Selektion einer Datenbank auf den Link SQL klicken und nach Klick auf die DurchsuchenSchaltfläche die SQL-Dumpdatei auswählen). Sollte sich der Name der MySQL-Datenbank geändert haben, muss jetzt noch die PostNuke-Konfigurationsdatei config.php angepasst werden. 12.4 Zusammenfassung Die Sicherung und Wiederherstellung einer PostNuke-Installation ist wichtig und glücklicherweise sehr unkompliziert. Für die Rücksetzung der gröbsten Konfigurationsfehler ist PSAK zuständig. 12.5 Ausblick Mit pnmini gehen wir in die Tiefe und erstellen unseren ersten kleinen Fork – ein hochoptimiertes Mini-CMS mit den wichtigsten Funktionen. 180 12 Troubleshooting, Backup und Recovery 13 pnmini Dieses Kapitel beschäftigt sich mit der Frage, wie klein ein PostNuke-System zusammengeschnürt werden kann, dass es nur die wirklich wichtigen CMS-Funktionen bietet wie einfache Artikelverwaltung (nur durch den Admin) Benutzer, Gruppen und Rechte-Verwaltung Session-Verwaltung Erweiterbarkeit über Blöcke und Module Darstellung von Xanthia-Themes Mehrsprachigkeit + Lokalisierungsfunktionen Umwandlung von Content, z.B. in eine Druckvorschau eine Suchmaschine eine API Zunächst einmal: es ist wesentlich einfacher, als man denkt. Installieren Sie sich ein frisches PostNuke-System und gehen Sie nachfolgende Anleitung durch, um ein solches „pnmini“ zu erzeugen. 13.1 Vorbereitung 1. Loggen Sie sich als Administrator im System ein. 2. Stellen Sie das Standard-Theme auf „ExtraLite“. 3. Deaktivieren Sie rechte Blöcke in Artikeln anzeigen. 4. Löschen Sie die Fuß-Nachricht. 13.1 Vorbereitung 181 13.2 Notwendige Module Das CensorModul besitzt in 0.750 Gold eine fehlerhafte DeinstallationsRoutine. Viele der mitgelieferten Module sind optional. Wer sich auf das Wesentliche konzentrieren will oder muss, kann fast alle Module deinstallieren und anschließend im Dateisystem löschen. Folgende Module sollten allerdings erhalten bleiben: 1. AddStory 2. Admin 3. Blocks 4. Groups 5. Languages 6. Modules 7. News 8. Permissions 9. pnRender 10. Search 11. Settings 12. Topics 13. User 14. Xanthia 13.3 Verzeichnisse löschen Sie können folgende Verzeichnisse unterhalb der PostNuke-Root gefahrlos löschen: 182 docs images/avatar images/banners images/powered images/reviews images/sections 13 pnmini images/smilies install javascript aus dem themes-Verzeichnis all die Themes-Unterverzeichnisse, die Sie nicht verwenden wollen (maximal alle bis auf das ExtraLite Theme, welches wir hier weiterverwenden) 13.4 Notwendige Blöcke Lassen Sie sich alle (auch die inaktiven) Blöcke anzeigen und deaktivieren und entfernen Sie alle Blöcke aus PostNuke bis auf: Hauptemenü/Main Menu Sprachen Anmeldung Machen Sie die übrig gebliebenen rechten Blöcke zu linken Blöcken. Editieren Sie den Block Hauptmenü und schalten Sie die Anzeige von „Modulen“ und „zu prüfen“ ein. löschen Sie aus dem Inhalts-Bereich die Zeile „Einstellungen“. löschen Sie aus dem Inhalts-Bereich alle Zeilen nach „Abmeldung“. Damit wird der Menü-Block hochdynamisch und passt sich dem Umfang der Installation automatisch an. 13.5 Blöcke löschen Löschen Sie nun die überflüssigen Blöcke aus dem Dateisystem. Lassen Sie folgende Blöcke in includes/blocks/ bestehen: 13.4 Notwendige Blöcke 183 login.php menu.php thelang.php Wir sind fast fertig. Was jetzt noch kommt, ist das Entfernen übriggebliebener Dateien und Tabellen, die nach der Schlankheitskur nicht mehr notwendig sind. 13.6 Dateien löschen Löschen Sie aus images/flags alle Sprach-Flaggen, die Sie nicht benötigen Löschen Sie aus images/global alles, was nicht von Ihren Themes benötigt wird. Erhalten bleiben müssen meist die folgenden Bilder: print.gif up.gif Löschen Sie das images/menu-Verzeichnis Bereinigen Sie das images/Topics-Verzeichnis Löschen Sie das includes/classes/lensdebug-Verzeichnis includes/languages/blocks: Löschen Sie jeweils für die einzelnen Sprachen alle Dateien bis auf down.gif 184 login.php menu.php thelang.php Löschen Sie aus dem includes/legacy-Verzeichnis folgende Dateien counter.php debug.php textsanitizer.php xhtml.php Löschen Sie aus dem language-Verzeichnis die jeweils sprachabhängige banners.php 13 pnmini Suchen Sie zum Schluss noch nach „readme*“, „doc*“ und „*.txt“ und löschen Sie die gefundenen Dateien bis auf die robots.txt. 13.7 Notwendige Datenbank-Tabellen Es sind noch einige Tabellen in der Datenbank übrig, die nun auch gefahrlos gelöscht werden können. Behalten Sie aber unbedingt folgende Tabellen: 1. blocks 2. group_membership 3. group_perms 4. groups 5. hooks 6. languages_constant 7. languages_file 8. languages_translation 9. module_vars 10. modules 11. queue 12. realms 13. referer 14. session_info 15. stories 16. stories_cat 17. theme_addons 18. theme_blcontrol 19. theme_cache 20. theme_config 21. theme_layout 22. theme_palette 23. theme_skins 13.7 Notwendige Datenbank-Tabellen 185 24. theme_tplfile 25. theme_tplsource 26. theme_zones 27. topics 28. user_data 29. user_perms 30. user_property 31. userblocks 32. users 13.8 Ergebnis Das Ergebnis dieser schnellen Optimierung kann sich sehen lassen. Betrug die Größe einer PostNuke-Installation vorher noch über 14 MB und bestand aus über 2.300 Dateien, ist sie jetzt auf ca. 9 MB mit etwas über 700 Dateien geschrumpft – und wir könnten noch weiter optimieren, z.B. im ADODB-Verzeichnis. Auch die Anzahl der DB-Tabellen hat sich von vorher über 80 auf etwas über 30 reduziert. 13.9 Zusammenfassung Schnell, übersichtlich, optimiert – mit pnmini beschränkt man sich auf das Notwendigste in einem CMS. 13.10 Ausblick Auch das Standard-PostNuke-System lässt sich optimieren, wie im nächsten Kapitel beschrieben wird. 186 13 pnmini 14 Performance & Tuning In diesem Kapitel werden die nützlichsten Tipps zur PerformanceSteigerung eines PostNuke-basierten Web-Portals andiskutiert. Eine vollständige Abhandlung würde den Rahmen dieses Buches sprengen. Daher wird insbesondere auf die mannigfaltig vorhandene Online-Dokumentation zu diesem Thema verwiesen. Genaue Empfehlungen können leider keine gegeben werden. Es gilt die Devise: Testen – Vergleichen – Optimieren – Testen – Vergleichen – Optimieren ... Gehen Sie bitte sorgfältig vor – falsche Einstellungen können dazu führen, dass sich Ihr Server nicht mehr konfigurieren lässt oder sogar langsamer als vorher läuft. Führen Sie die hier vorgestellten Möglichkeiten sequentiell durch und prüfen Sie den Effekt jeweils separat. An dieser Stelle ist es sinnvoll, ein Backup der MySQLDatenbank sowie der Webserver-Konfiguration und der PostNukeInstallation anzufertigen. 14.1 Tools zur Performance-Messung Viele der hier vorgestellten Tools ermöglichen sogar die Aufzeichnung einer typischen Klickreihenfolge, die dann vom Programm wiederholt wird (Scripts/Makros). Wenn gewünscht simulieren die Tools damit die Zugriffe mehrerer 100 virtueller Benutzer. Apache Bench (ab) Apache Jmeter Dieseltest Microsoft ACT 14.1 Tools zur Performance-Messung 187 Siege Webserver Stress Tool Abb. 14.1: Das Stress-Tool Dieseltest Egal welches Tool Sie präferieren: verwenden Sie für alle Tests das gleiche Tool, legen Sie dort vorher soweit wie möglich ein TestSkript an und nehmen Sie dieses als Grundlage für sämtliche weitere Tests, um festzustellen, ob die Optimierungsversuche fruchten. 14.2 Anzahl Seitenabrufe in Abhängigkeit von Bandbreite Die theoretisch mögliche Anzahl der Seitenabrufe pro Sekunde in Abhängigkeit von der verfügbaren Bandbreite errechnet sich über die Formel Bandbreite in bit/s * 0,125 / Seitengröße in Bytes (inkl. Bilder) Eine 60 kByte große PostNuke-Startseite ließe sich über eine DSLBandbreite von 2 Mbit/sec also rein theoretisch 2.000.000 * 0,125 / (60 * 1024) = 4 mal pro Sekunde abrufen. Über ISDN sind bei der Größe nur 0,13 Seitenabrufe/sec möglich – egal wie stark Sie optimieren. 188 14 Performance & Tuning In einem lokalen 100 Mbit-Netzwerk können bei 60 kByte Seitengröße von einem lokalen PostNuke-Intranet-Server bis zu 203 Seitenabrufe erwartet werden. Ein absolut utopischer Wert – schließlich darf man nicht vergessen, dass es sich hier nicht um statische HTML-Seiten handelt, sondern eine ganze Reihe an PHP-Skripten vom Datenbank-Zugriff über Prüfung von Benutzerberechtigungen bis hin zum Einfügen der Ergebnisse in Templates beschäftigt sind, bevor die Seite überhaupt ausgeliefert werden kann. Anbei ein Beispiel-Test mit Ergebnis. Beachten Sie die zahlreichen Komponenten und Umstände, die jede für sich Einfluss auf das Testergebnis nehmen: frisch installiertes PostNuke-System mit ExtraLite-Theme ohne eingestellte Artikel im ausgeloggten Zustand Skript: nur Abfrage ke/html/index.php 1.5 GHz Pentium M Festplatte mit 5.400 U/min 1 GB RAM Abyss Webserver 1.2.3.0 (Standard-CGI) PHP 4.3.8 MySQL 4.0.20 Windows XP Professional SP2 lokaler Test (Stress-Tool läuft also direkt auf dem Server, keine dazwischenliegende Netzwerkverbindung) alle Komponenten nicht optimiert Rechner frisch gebootet, keine weiteren Programme außer Server-Umgebung, Task-Manager, Virenscanner und Stress-Tool aktiv der Startseite postnu- Mit “ab“ als Stress-Tool und dem Aufruf ab -c 1 -t 10 http://localhost/postnuke/html/index.php waren maximal 4 Seitenabrufe pro Sekunde möglich, die Prozessorauslastung lag bei maximal 100%. Erst ab ca. 40 parallelen Zugriffen brechen die Seitenabrufe ein. 14.2 Anzahl Seitenabrufe in Abhängigkeit von Bandbreite Entscheiden Sie sich für ein Stress-Tool und bleiben Sie dann dabei. 189 Das Tool Dieseltest testet „anders“: hier waren 8 Abrufe bei maximal 50% Prozessorauslastung möglich. Zwei parallele User treiben die Prozessorlast auf über 80% hoch; gleichzeitig sind über 16 Seitenabrufe pro Sekunde möglich. Solange der Prozessor nicht vollausgelastet ist, sind etwas mehr als 8 Seitenabrufe/sec pro Benutzer möglich (bei 3 parallelen Benutzern liegen wir bei 26 Abrufen/sec und max. 95% CPU-Auslastung). Erst ab 100% CPUAuslastung bricht das Ergebnis mehr als deutlich ein. 14.3 Hardware Für den Einsatz eines Webservers in Verbund mit einer relationalen Datenbank spielen ganz allgemein folgende Faktoren eine wesentliche Rolle: 1. die Größe des Hauptspeichers: je mehr, desto besser 2. die Leistungsfähigkeit der CPU: Funktionen wie eine OnlineKompression oder die Generierung dynamischer Inhalte verlangen Rechenzeit. Für den Betrieb im Intranet unserer fiktiven Firma empfiehlt sich eine Dual-Prozessor-Maschine, da jeder parallele Benutzerzugriff einen eigenen CPUkonsumierenden Webserver-Thread erzeugt (wie man am Dieseltest-Ergebnis schön sehen kann). 3. Festplatte: Hier zählt die Geschwindigkeit und nicht die Größe der Festplatte. Platten ab 7.200 Umdrehungen/min sind gut, 15.000 Umdrehungen/min stellen derzeit das Optimum dar. 4. Die Bandbreite der Internetanbindung des Servers: Sie wird besonders bei stark frequentierten Seiten und/oder umfangreichen Downloads schnell zum Flaschenhals. Im Intranet allerdings kein Thema. 190 14 Performance & Tuning 14.4 Software 14.4.1 PHP Die grundlegendsten Optimierungsmöglichkeiten sind: Nicht benötigte Extensions deaktivieren Register Globals auf off setzen Minimales Logging im Wirkbetrieb php.ini-recommended als Basis verwenden 14.4.2 Encoder Encoder sind in der Lage aus PHP-Dateien Byte-Code zu generieren, der wesentlich schneller auszuführen ist als Source-Code. Hierzu wird eine zur PHP-Version passende Extension benötigt, die in der Konfigurationsdatei von PHP (php.ini) mit eingebunden werden muss. Diese ist im Regelfall vom Hersteller zu beziehen. Es existiert eine Reihe von Encodern, die in der Regel kostenpflichtig sind. Den teuersten Encoder liefert Zend mit einem Preis ab 960 Dollar, der daher auch für die Wenigsten in Frage kommen wird. Encoder im Preissegment bis 200 Dollar finden sich relativ viele; der jeweils stark verminderte Funktionsumfang in den Testversionen erlaubt jedoch keine exakten Aussagen zu deren Verwendbarkeit. Wir empfehlen vom Preis-/Leistungsverhältnis den ionCube Encoder, den wir auch für eigene Projekte einsetzen und damit durchweg gute Erfahrungen gesammelt haben. 14.4.3 HTTP-Kompression Sollten Sie über einen dedizierten Webserver verfügen, der seitens der Prozessorzeit wenig ausgelastet ist, dann schalten Sie die HTTPKompression im Apache oder IIS ein. 14.4 Software HTTPKompression wird beim Apache deflate genannt. 191 Im IIS geschieht dies über Eigenschaften der Webseite – Dienst. Hinweis: standardmäßig komprimiert der IIS dann nur HTM* und TXT-Dateien. Konfigurieren Sie ihn über den Befehl cscript so, dass er CSS, JS, XML und beliebige weitere Dateitypen ebenfalls komprimiert. Für den Apache empfehlen wir das Studium der Dokumentation unter http://httpd.apache.org/docs-2.0/mod/mod_deflate.html Durch das geringere Übertragungsvolumen werden die angeforderten Daten schneller ausgeliefert. Allerdings steigt damit die Prozessorlast und die Latenzzeit des Servers an. 14.4.4 CGI Verwenden Sie über das Modul mod_fastcgi die FastCGIMethode bei Apache; für den IIS existiert FastCGI als ISAPIModul auf www.caraveo.com/fastcgi. Wir bevorzugen beim IIS generell die Verwendung von ISAPI anstelle von klassischem CGI. 14.4.5 Betriebssystem Hierzu gibt es Tonnen an Dokumentation. Wenn man sich mit der Materie auseinandersetzt, erhält man schnell den Eindruck einer Wissenschaft für sich, gespickt mit Emotionen und gegenteiligen Aussagen. Allgemein können Sie hier beliebige Optimierungs-Tipps umsetzen. Bei Linux-Systemen wird die Kernel-Optimierung empfohlen, unter Windows bringt neben der Umsetzung allgemeiner TuningTipps eine Deaktivierung nicht benötigter Dienste mehr Rechenzeit und Hauptspeicher. Gehen Sie in jedem Fall besonnen vor: eine Aktion nach der anderen, und keine Optimierung ohne Backups. 14.4.6 Datenbank Die wichtigsten Änderungsmöglichkeiten bei MySQL können in der Datei my.cnf vorgenommen werden. Hier sind die Einträge 192 set-variable = key_buffer set-variable = table_cache 14 Performance & Tuning im Abschnitt [mysqld] von besonderem Interesse. key buffer legt den maximalen Speicherbedarf fest, den MySQL für Schlüssel nutzen darf, table_cache definiert die Größe des Zwischenspeichers für Tabellen. Achten Sie darauf, dass die Werte niemals größer sind als das, was Ihnen an Hauptspeicher zur Verfügung steht. Darüber hinaus sind die Indexfelder einer Standard-PostNukeInstallation noch nicht optimal gesetzt. Durch Hinzufügen folgender Indizes kann die Performance eines PostNuke-Systems gesteigert werden: alter add alter add alter add alter add alter add alter add alter add alter add alter add alter add alter add alter add alter add alter add alter add table index table index table index table index table index table index table index table index table index table index table index table index table index table index table index nuke_comments idx_pid (pn_pid); nuke_comments idx_sid (pn_sid); nuke_group_membership idx_ug (pn_uid,pn_gid); nuke_message idx_exp (pn_active,pn_expire); nuke_modules idx_name (pn_name); nuke_poll_data idx_pollid (pn_pollid); nuke_pollcomments idx_pollid (pn_pollid); nuke_referer idx_url (pn_url); nuke_stats_date idx_date (pn_date); nuke_session_info idx_last (pn_lastused); nuke_stories idx_catid (pn_catid); nuke_stories idx_topic (pn_topic); nuke_user_data idx_uid (pn_uda_uid); nuke_userblocks idx_ub (pn_uid,pn_bid); nuke_users idx_uname (pn_uname); 14.4 Software 193 Neben diesen Indizes kann ein regelmäßiges Optimieren der umfangreicheren Tabellen zusätzlich helfen, die Query-Zeiten zu verbessern. 14.5 PostNuke-Bordmittel nutzen Kommen wir zur Optimierung des PostNuke-Systems selbst. Hier helfen die diversen Caching-Einstellungen in Xanthia und pnRender, PostNuke noch einmal zu beschleunigen. Für Einzelheiten sei dazu auf das Kapitel Xanthia verwiesen. Darüber hinaus erreicht man mit der Abschaltung unnötiger Blöcke und Module weitere Performance-Zuwächse, was sich an unserem pnmini aus dem vorigen Kapitel deutlich zeigen lässt: im Vergleich zu einem nicht-optimierten Standard-PostNuke-System ist pnmini schon ohne Optimierungen um 25% schneller; nach allen Software-Optimierungen sind Geschwindigkeits-Zuwächse um 50% möglich. 14.6 Zusammenfassung Tuning-Tipps setzen schon an der Basis – dem Betriebssystem, Webserver und der Datenbank – an. Auch PostNuke bietet besonders im Xanthia-Umfeld einige Möglichkeiten, die Geschwindigkeit zu steigern. 14.7 Ausblick Die neuesten, auch unstabilen PostNuke-Versionen bezieht man direkt aus dem CVS. Wie das funktioniert, wird im nächsten Kapitel dargestellt. 194 14 Performance & Tuning 15 Das PostNuke-CVS Die Entwickler von PostNuke verwenden das Concurrent Version System (CVS) zur simultanen Bearbeitung, Verwaltung und Versionierung ihres Source Codes. Für die Allgemeinheit wird ein CVSServer zur Verfügung gestellt, über den man sich immer die aktuellsten Sourcen des CMS herunterladen kann. Natürlich sollte man bedenken, dass es sich dabei immer um die neuesten – und damit nicht releasten – Teile der PostNuke-Software handelt. Mit einer rein CVS-basierten Version von PostNuke wird man daher wenig Freude haben. Es kommt auch vor, dass nach einem CVS-Update und dem Auffrischen der Testseite mit den neu erhaltenen Dateien gar nichts mehr funktioniert. Sinnvoller ist dagegen das Ausprobieren einzelner konkreter Module aus dem CVS in einer releasten Umgebung von PostNuke. Wir beschreiben kurz, wie Sie aus dem CVS an die neuesten PostNuke-Versionen herankommen und so einen Einblick in den Fortschritt der Entwicklung nehmen können. Die Verwendung von Dateien aus dem CVS wird nicht für den Einsatz in einer Produktivumgebung empfohlen. 15.1 CVS-Module Im CVS gibt es eine ganze Reihe an Modulen, z.B. „Core“, „Languages“, „Modules“ usw. Sie können sich die Arbeit erleichtern, in dem Sie das Modul „PostNuke“ herunterladen – dieses enthält alle anderen CVS-Module. Während die Standard-Installation einer releasten PostNuke-Version um die 2.300 Dateien umfasst, gelangen über das CVS ca. 5.300 Dateien mit einem Umfang von ca. 17 MB auf die heimische Festplatte – die CVS-Version von PostNuke ist in Teilen also schon erheblich weiter als das offizielle Release. 15.1 CVS-Module 195 15.2 Die Zugangsdaten Jeder darf lesend auf das CVS-System der PostNuke-Entwickler zugreifen. Wer als PostNuke-Entwickler Schreibrechte besitzt, braucht nur den untenstehenden Usernamen und das Passwort zu ändern. 15.2.1 CVS über HTTP Der PostNuke CVS-Server ist durchaus ab und an nicht erreichbar. Probieren Sie es in diesem Fall einfach später erneut. Das CVS kann über http://cvs.postnuke.com besichtigt werden. Diese Art des Zugriffs ist geeignet, um sich einen schnellen Überblick über die CVS-Strukturen zu verschaffen und sich einige wenige Dateien herunterzuladen. 15.2.2 CVS auf der Kommandozeile Wer CVS tiefer kennt, kann über die Kommandozeile ein CVSCheckout durchführen: 1. cvs -d:pserver:[email protected]:/repository (Password: anon) login 2. cvs -d:pserver:[email protected]:/repository co PostNuke 15.2.3 Zugriff mit TortoiseCVS Mit dem Windows-basierten CVS-Client Tortoise gelingt ein CVS-Checkout mit folgenden Einstellungen: 196 Server: cvs.postnuke.com Protokoll: pserver, Repository-Ordner: /repository Benutzername: anon, Passwort: anon Modul: PostNuke 15 Das PostNuke-CVS 15.3 Das Bauen einer lauffähigen PostNukeUmgebung aus dem CVS 1. Holen Sie sich die aktuellen Sourcen aus dem CVS in einen beliebigen Ordner. Tipp: Wählen Sie in Tortoise-CVS im Tab Optionen unter Absicht des Auscheckens einfach den Punkt Export statt Checkout. Dies verhindert das Anlegen der CVS-Unterverzeichnisse. Alternativ können Sie auch sämtliche CVS-Unterverzeichnisse aus Ihrem PostNukeOrdner löschen. 2. Erstellen Sie in Ihrer Document-Root ein Verzeichnis namens brand-new. 3. Kopieren Sie alles unterhalb des CVS-Ordners Core ins Verzeichnis brand-new. Bestätigen Sie alle folgenden Abfragen, ob Zieldateien überschrieben werden sollen, immer mit Ja. 4. Kopieren Sie alles unterhalb des CVS-Ordners Docs ins Verzeichnis brand-new. Wundern Sie sich nicht: die deutschen Sprachpakete sind nicht im CVS enthalten, sondern über http://sourceforg e.net/projects/ pnlanguages oder http://www.postnuke.net erhältlich. Siehe auch das Kapitel Sprachpakete und Sprachentabelle. 5. Nun geht es um die Sprachdateien. Wechseln Sie in den CVSOrdner Languages. Wechseln Sie nun in den Ordner der Sprache, die Sie verwenden wollen, z.B. fra. Kopieren Sie alle darin enthaltenen Dateien direkt ins Verzeichnis brandnew. Wiederholen Sie den Vorgang für jede weitere gewünschte Sprache. 6. Die Module kopieren Sie, in dem Sie aus dem CVS-Ordner Modules alles unterhalb der Unterverzeichnisse Content, Miscellaneous, ResourcePack und Utility direkt ins Verzeichnis brand-new/modules kopieren. 7. Kopieren Sie alles unterhalb des CVS-Ordners Themes ins Verzeichnis brand-new/themes. 8. Wir sind fertig und können die neue Version installieren. Starten Sie ihren Browser und rufen Sie /brandnew/install.php auf. 15.3 Das Bauen einer lauffähigen PostNuke-Umgebung aus dem CVS 197 Eine einfache Batch-Datei für Windows, die Ihnen die KopierArbeit nach einem CVS-Update abnimmt, hat folgendes Aussehen (wobei hier c:\mycvs\pn0800 das CVS-Verzeichnis und c:\apache\htdocs die Document Root darstellt): @echo off set set set set PATH_CVS="c:\mycvs\pn0800" PATH_CVS2="\mycvs\pn0800" PATH_BNEW="c:\apache\htdocs\brand-new" CVSROOT=:pserver:[email protected]: /repository c: cd %PATH_CVS2% echo Updating pn0800 from cvs.postnuke.com... C:\Programme\TortoiseCVS\cvs.exe -q update -d -P echo Removing old installation... rmdir /s /q %PATH_BNEW% mkdir %PATH_BNEW% echo Copying core stuff... xcopy /f /i /q /s /y %PATH_CVS%\Core\* %PATH_BNEW% xcopy /f /i /q /s /y %PATH_CVS%\Docs\* %PATH_BNEW% echo Copying languages... xcopy /f /i /q /s /y %PATH_CVS%\Languages\cro\* %PATH_BNEW% xcopy /f /i /q /s /y %PATH_CVS%\Languages\fra\* %PATH_BNEW% 198 15 Das PostNuke-CVS xcopy /f /i /q /s /y %PATH_CVS%\Languages\hrv\* %PATH_BNEW% xcopy /f /i /q /s /y %PATH_CVS%\Languages\ita\* %PATH_BNEW% xcopy /f /i /q /s /y %PATH_CVS%\Languages\spa\* %PATH_BNEW% xcopy /f /i /q /s /y %PATH_CVS%\Languages\zho\* %PATH_BNEW% echo Copying modules... xcopy /f /i /q /s /y %PATH_CVS%\Modules\Content\* %PATH_BNEW%\modules xcopy /f /i /q /s /y %PATH_CVS%\Modules\Miscellaneous\* %PATH_BNEW%\modules xcopy /f /i /q /s /y %PATH_CVS%\Modules\ResourcePack\* %PATH_BNEW%\modules xcopy /f /i /q /s /y %PATH_CVS%\Modules\Utility\* %PATH_BNEW%\modules echo Copying 3rd party modules... xcopy /f /i /q /s /y %PATH_CVS%\3rdParty\Content\* %PATH_BNEW%\modules echo Removing CVS dirs, if existent... rmdir /s /q CVS echo Finished. pause 15.3 Das Bauen einer lauffähigen PostNuke-Umgebung aus dem CVS 199 15.4 Zusammenfassung Mit den Dateien aus dem CVS kann man einen Blick auf zukünftige PostNuke-Versionen werfen. Eine Batch-Datei hilft beim Zusammenbau eines evtl. lauffähigen Systems. 15.5 Ausblick Woher bekommt man Sprachpakete für seine Installation? Die Quellen werden im folgenden aufgezeigt. 200 15 Das PostNuke-CVS 16 Sprachpakete und Sprachentabelle 16.1 Sprachpakete beziehen Sprachpakete zu PostNuke finden sich entweder auf der Homepage des PostNuke Language Projects unter http://sourceforge.net/projects/pnlanguages, im PostNuke-CVS oder auf http://www.post-nuke.net In der Regel empfiehlt es sich, in allen drei Quellen nach Sprachdateien zu suchen und auf einem Wirksystem so zusammenzuführen, dass ältere Versionen vorhandener Sprachdateien überschrieben werden. Die Installation eines Sprachpaketes ist einfach: Sprachdateien herunterladen, ins PostNuke-Dateisystem kopieren – fertig. Um Probleme mit Cookies und dort voreingestellten Sprachen zu umgehen, müssen Sie jetzt eventuell noch die Cookies löschen oder die URL http://servername/postnuke/html/index.php?newlang= aufrufen. 16.1 Sprachpakete beziehen 201 16.2 Sprachen, ihre Kürzel und Fundort Die folgende Tabelle dokumentiert, welche Sprache welches Kürzel in PostNuke besitzt und woher man – mit etwas Glück vollständige – Sprachpakete für sein PostNuke-System beziehen kann. Alle PostNuke-Sprachkürzel sind nach ISO 639-2/T spezifiziert. Die Sprachkürzel, die nicht ISO-konform sind, beginnen mit „x_“. Wer selber als Übersetzer tätig werden möchte, sollte einen Blick auf die Beschreibung des Languages-Moduls werfen. Sprachkürzel 202 Sprache Verfügbar* ara Arabisch Sf bul Bulgarisch - cat Katalanisch Sf ces Tschechisch - cro Kroatisch Sf, CVS dan Dänisch - deu Deutsch Sf, PNN ell Griechisch modern (1453) Sf eng Englisch Sf esp Esperanto - est Estonisch - far Persisch (Farsi) Sf fin Finnisch - fra Französisch Sf, CVS heb Hebräisch - hrv Kroatisch Sf, CVS hun Ungarisch Sf ind Indonesisch - isl Isländisch Sf ita Italienisch Sf, CVS jpn Japanisch Sf kor Koreanisch - lav Lettisch - lit Litauisch - 16 Sprachpakete und Sprachentabelle mas Malaisch - mkd Mazedonisch - nld Holländisch Sf nor Norwegisch Sf pol Polnisch Sf por Portugiesisch Sf ron Rumänisch - rus Russisch Sf slv Slowenisch Sf spa Spanisch Sf, CVS svk Slowakisch Sf swe Schwedisch Sf tha Thailändisch Sf tur Türkisch - ukr Ukrainisch - vid Jüdisch - x_all Alle Sprachen - x_brazilian_portuguese Brasilianisches Portugiesisch Sf x_klingon Klingonisch - x_rus_koi8r Russisch KOI8-R - zho vereinfachtes/traditionelles Chinesisch Sf, CVS * Quellen für Sprachpakete Sf: sourceforge.net PNN:post-nuke.net CVS: CVS 16.2 Sprachen, ihre Kürzel und Fundort 203 17 Tipps & Tricks zu PostNuke 17.1 Allgemein Anbei die wichtigsten URLs in einem PostNuke-System Startseite: index.php Administration: admin.php persönliche Account-Seite / Login / Registrierung : user.php Benutzer ausloggen: user.php?module=NS-User&op=logout Beitrag verfassen : modules.php?op=modload&name=Submit_News&file=index Module anzeigen: index.php?module=Modules&type=admin&func=list Blöcke anzeigen: index.php?module=Blocks&type=admin&func=view Einstellungen: admin.php?module=NS-Settings&op=main PostNuke lädt lange? News-Modul lädt gar nicht mehr? Wahrscheinlich ist ein Block mit extern eingebundenem Content, ein Frame o.ä. nicht verfügbar ist und erzeugt einen entsprechenden Timeout (meist 30 Sekunden). Dies kommt öfters beim Einsatz von Shoutcast- oder Amazon-Blöcken vor. Ich möchte meine PostNuke-URL von http://.../postnuke/html auf http://.../pn0750/html ändern. 17.1 Allgemein 205 Ändern Sie einfach den Verzeichnisnamen postnuke auf pn0750. Ich möchte in der config.php von PostNuke neue verschlüsselte Datenbank-Zugangsdaten ablegen. Siehe Kapitel Troubleshooting, Backup und Recovery. Ich habe mich selbst durch fehlerhafte Zugriffsrechte für immer und ewig aus meinem eigenen System ausgesperrt. Siehe Kapitel Troubleshooting, Backup und Recovery. Multisites funktionieren nicht? Siehe Kapitel Multisites. Fehlermeldung „ADONewConnection: Unable to load database driver '' Fatal error: Call to a member function on a nonobject in…” erscheint. Diese Meldung erscheint vorzugsweise, wenn Multisites eingerichtet wurden und somit manuell eine config.php angelegt werden musste. Leitet man die PHP-Datei nur mit „ Sie erhalten von Ihrem System eine Mail mit Betreff “Attempted hack on your site? (type: pnSecurity Alert)”? Hier wurde z.B. JavaScript-Code in eine Admin-Message oder einen Artikel eingefügt. pnAntiCracker informiert Sie über solche Vorkommnisse. Sie können dieses Verhalten über die allgemeinen Einstellungen von PostNuke konfigurieren. 206 17 Tipps & Tricks zu PostNuke Umlaute in Artikeln funktionieren nicht? In Artikeln wird nach dem Umlaut alles abgeschnitten? Probleme mit Umlauten in Blöcken und Modulen? Installation verhält sich merkwürdig? Zeichensatz-Problem. Es kann sein, dass neuere MySQLVersionen ab 4.1 so konfiguriert sind, dass der "default-characterset" jetzt "utf8" ist. Damit funktionieren keinerlei Sonderzeichen mehr. Man hat nun zwei Möglichkeiten: 1. In der my.cnf von MySQL den Eintrag "set-variable = defaultcharacter-set=utf8" auskommentieren, MySQL restarten - und schon funktioniert wieder alles wie gewohnt. 2. In der global.php von PostNuke die Zeile auf ne('_CHARSET','ISO-8859-1'); ne('_CHARSET','utf-8); ändern. defidefi- 17.2 Benutzer / Sessions Wie kann man sich ausloggen, wenn kein Logout-Link zur Verfügung steht? Einfach folgende URL aufrufen: http://servername/postnuke/ html/user.php?module=NS-User&op=logout Die Uhrzeit wird für bestimmte Benutzer nicht korrekt angezeigt. Was tun? Dies liegt meist an einer falschen Zeitzone in den persönlichen Einstellungen. Die Zeitzone, die in den eigenen Einstellungen ausgewählt wird, überschreibt die globale Zeitzone des gesamten PostNuke-Systems. In einigen Fällen ist dafür auch die Einstellung der Systemzeit auf dem Server verantwortlich: Wenn sich Ihr Server im europäischen Raum befindet und Sommer- bzw. Winterzeit automatisch berücksichtigt werden soll, stellen Sie sicher, dass die Systemzeit mit dem Format CEST (Central European Summer Time) arbeitet und nicht mit GMT (Greenwich Mean Time). Letzteres verhindert nämlich die Erkennung der jeweiligen Zeit. Darüber hinaus sollten Sie die Regi- 17.2 Benutzer / Sessions 207 onaleinstellung entsprechend setzen, um den Versatz zur GMT-Zeit dennoch berücksichtigen zu können. Ab und an kann es beim Ändern des Zeitformats vorkommen, dass zwar die Systemzeit gesetzt wurde, die Zeit auf der Web-Seite aber immer noch den alten/falschen Wert anzeigt. In diesem Fall müssen Sie den Web-Server stoppen und neu starten, damit auch er das neue Format übernimmt. Wie kann ich das Passwort eines beliebigen PostNukeBenutzers, z.B. des PostNuke-Administrators zurücksetzen? 1. Rufen Sie im Browser die URL zu Ihrer phpMyAdminInstallation auf, z.B. http://localhost/phpmyadmin. 2. Wählen Sie die PostNuke-Datenbank aus. 3. Editieren Sie aus der Benutzertabelle (meist „nuke_users“) den Benutzer, dessen Passwort Sie zurücksetzen möchten. 4. Wählen Sie aus der Dropdown-Listbox „Funktion“ vor dem Eingabefeld „pn_pass“ die Funktion „MD5“ aus. 5. Tragen Sie im Feld „pn_pass“ das neue Passwort im Klartext ein. 6. Speichern Sie die Eingabe. Das Passwort wird nun verschlüsselt in der Datenbank abgelegt. Alternativ kann PSAK > Version 1.01 verwendet werden. Wie kann ich die Sprache meines Systems ändern, auch wenn ich keinen Sprach-Block installiert habe? Vorausgesetzt, es sind die passenden Sprachpakete installiert, genügt der Aufruf der URL index.php?newlang=<Sprachkürzel>, also z.B. index.php?newlang=deu 208 17 Tipps & Tricks zu PostNuke 17.3 Blöcke und Module Ein Modul lässt sich nicht mehr entfernen Löschen Sie alle Dateien im Verzeichnis des Moduls. Das zum Modul gehörende Verzeichnis nicht löschen. In PostNuke die Modulliste neu erzeugen lassen. Dort kann dann das Modul entfernt werden. Anschließend kann auch das Verzeichnis gelöscht werden. Eventuell müssen jetzt noch zum Modul gehörende Tabellen aus der MySQL-Datenbank gelöscht werden. Wie kann ich steuern, dass typetool nur im News-Modul aktiv ist? typetool wird nur dann aktiv, wenn für das Zugriffsrecht typetool:: | MODNAME:: mindestens die Berechtigung kommentieren vorliegt. Daher muss für unseren Fall allen Gruppen die Berechtigung für das News-Modul zugewiesen werden. Anschließend entzieht man für alle restlichen Module diese Berechtigung mit alle Gruppen | typetool:: | .* | read. Copy & Paste aus z.B. Word in typetool macht Probleme; HTML-Tags erscheinen als Text In den allgemeinen PostNuke-Einstellungen sind nicht alle HTML-Tags freigeschaltet. AutoLinks werden in den News nicht gesetzt, obwohl das AutoLinks-Modul aktiv ist Im News-Modul sind die Hooks für AutoLinks nicht aktiviert. Back-Taste führt zu „keine Berechtigung“ Die Seite, zu der man mittels Back-Taste zurückkehren möchte, wurde ursprünglich durch einen Key geschützt, der nach der Verwendung der Seite (= Sie haben dort auf einen Link geklickt oder eine andere Aktion ausgelöst) abgelaufen ist. Dies ist ein Sicherheitsfeature im System. Wenn Sie die Seite dennoch sehen möchten, 17.3 Blöcke und Module 209 laden Sie sie neu. Damit wird auch ein neuer Sicherheits-Key generiert und in die Seite eingebettet. Upload von Bildern in Photoshare dauert unendlich lange Prüfen Sie, ob der SQL-Benutzer das Recht auf „LOCK TABLES“ besitzt. 17.4 Themes Fatal error: Call to undefined function: themeheader() Hier schlägt das Laden des Themes fehl. Installieren Sie sich das PostNuke Swiss Army Knife (d.h. legen Sie es unterhalb der Document-Root ab) und setzen Sie damit das Theme zurück, am besten auf das einfache „ExtraLite“-Theme. Wie bekommt man in einem Xanthia-Theme die Rahmen um die Blöcke weg? Im StyleSheet zum Xanthia-Template müssen die entsprechenden CSS-Klassen angepasst werden (meist „boxtitle“ und „boxcontent“). Wie kann man ein eingestelltes Xanthia-Theme dynamisch überschreiben? Dies ist meist notwendig, wenn beispielsweise ein Modul ein komplett anderes Aussehen haben soll, also auch StylesheetDefinitionen anders sein sollen. Vorbedingungen: Zweites Xanthia-Theme im System vorhanden und aktiviert. Etwa zu Beginn der pnuser.php müssen dann nachfolgende Zeilen eingefügt und entsprechend den Anforderungen hin angepasst werden: $GLOBALS['engine']->DTS->template_dir = "themes/PostNukeBlue/templates"; $GLOBALS['engine']->DTS->config_dir = 210 17 Tipps & Tricks zu PostNuke "themes/PostNukeBlue"; $GLOBALS['engine']->DTS->plugins_dir[5] = "themes/PostNukeBlue/plugins"; $GLOBALS['engine']->DTS-> _tpl_vars['themepath'] = "themes/PostNukeBlue"; $GLOBALS['engine']->DTS-> _tpl_vars['imagepath'] = "themes/PostNukeBlue/images"; $GLOBALS['engine']->DTS->thename = "PostNukeBlue"; $GLOBALS['engine']->DTS->themepath = "themes/PostNukeBlue"; $GLOBALS['engine']->DTS->skinspath = "themes/PostNukeBlue"; $GLOBALS['engine']->DTS->imagepath = "themes/PostNukeBlue/images"; $GLOBALS['engine']->DTS->skins = "PostNukeBlue"; $GLOBALS['engine']->DTS->tplresourcepath = "userdb:PostNukeBlue/"; $GLOBALS['engine']->DTS-> blocktplresourcepath = "userdb:PostNukeBlue/"; $GLOBALS['engine']->DTS-> moduletplresourcepath = "userdb:PostNukeBlue/"; Alternativ kann man im Template-Verzeichnis des Themes im Unterverzeichnis „modules“ auch unter dem Modul-Namen veränderte Templates hinterlegen. Diese werden dann gegenüber den Standard-Templates des Moduls bevorzugt. Dies verhindert jedoch, dass andere Styles geladen werden und funktioniert darüber hinaus nur bei Xanthia-konformen Modulen. Ich habe ein fehlerhaftes Theme aufgespielt und aktiviert, und muss nun feststellen, dass ich dieses nicht mehr rückgängig machen kann. Siehe Kapitel Troubleshooting, Backup und Recovery. 17.4 Themes 211 17.5 Ausblick Im nächsten Kapitel wird auf die Grundlagen der Block- und Modulprogrammierung eingegangen. Anhand der vermittelten Grundlagen programmieren Sie Ihr erstes eigenes Modul, welches das Buchen und Stornieren von Konferenzräumen in einem PostNukebasierten Intranet ermöglichen kann. 212 17 Tipps & Tricks zu PostNuke 18 Die PostNukeProgrammierung Das Kapitel richtet sich an alle, die eigene Blöcke oder Module für PostNuke entwickeln möchten. Kenntnisse in PHP und MySQL werden vorausgesetzt. Ein Blick in die Smarty-Dokumentation unter http://smarty.php.net ist genauso hilfreich wie ein Blick in die Dokumentation von ADODB (findet sich in der PostNukeInstallation unter postnuke/html/adodb/docs). 18.1 Programmierung von autarken Blöcken Blöcke sind die kleinste Einheit einer PostNuke-Oberfläche. Man unterscheidet folgende Block-Typen: autarke Blöcke Modul-Blöcke Autarke Blöcke kommen ohne Module aus. Vorstellbar ist beispielsweise eine einfache Abfrage von Wetterdaten oder die Anzeige von Systemstati eines Servers. Details zu den einzelnen Funktionen, ihrem Aufruf oder der Bedeutung ihrer Parameter entnehmen Sie bitte dem Kapitel Die PostNukeAPI. Autarke Blöcke entwickelt man, wenn man die Fragen Benötige ich eine umfangreiche interaktive Benutzer- oder Admin-Oberfläche? Ist die angebotene Funktion umfangreich? mit „nein“ beantworten kann. Wird eine der Fragen mit „ja“ beantwortet, sollte ein Modul entwickelt werden, welches dann zur kom- 18.1 Programmierung von autarken Blöcken 213 pakten und spezialisierten Informationsdarstellung Blöcke anbieten kann. Wir zeigen den typischen Aufbau einer Block-Datei an einem Beispiel. Unsere fiktive Firma verlangt, dass in einem Block ständig der freie Festplattenplatz des Webservers angezeigt wird (abgesehen davon, dass man das auch mit einem einfachen PHP-Block bewerkstelligen kann). Bitte studieren Sie den SourceCode und die Kommentare Legen Sie eine neue Datei namens sysinfo.php im Verzeichnis html/includes/blocks mit folgendem Inhalt an. // block header definition (always the same) $blocks_modules['sysinfo'] = array( 'func_add' 'func_display' 'func_edit' 'func_update' => => => => '', 'blocks_sysinfo_display', '', '', 'text_type' => 'System Info', 'text_type_long' => 'System Info (shows free diskspace about your webserver)', 'allow_create' 'allow_delete' 'allow_multiple' 'form_content' 214 => => => => true, true, false, false, 18 Die PostNuke-Programmierung 'form_refresh' 'show_preview' => true, => true ); function blocks_sysinfo_display($row) { // show block only if user has // overview access level if (!pnSecAuthAction(0, 'Sysinfoblock::', "$row[title]::", ACCESS_OVERVIEW)) { return; } // access granted // no block title set? if so, set // one default if (!$row['title']) { $row['title'] = 'System Information'; } $row['content'] = ""; $fs = disk_free_space("/"); if ($fs > 1073741824) { $row['content'] .= round($fs / 1073741824, 2) . " GB "; } elseif ($fs > 1048576) { $row['content'] .= round($fs / 1048576, 2) . " MB "; } elseif ($fs > 1024) { $row['content'] .= round($fs / 1024, 2) . " KB "; } else { $row['content'] .= $fs . " Bytes "; } // use language independent constant $row['content'] .= _FREEDISKSPACE; 18.1 Programmierung von autarken Blöcken 215 // return block content to postnuke return themesideblock($row); } ?> Einige der Header-Definitionen wie allow_delete haben noch keine Auswirkungen in PostNuke. In den ersten Zeilen wird der direkte Aufruf der Datei sysinfo.php verhindert. Anschließend wird dem Zugriffsrechte-Modul das Berechtigungs-Schema dieses Blocks mitgeteilt. Erst dann beginnt der eigentliche Block-Code. Im Block-Header wird PostNuke u.a. bekannt gegeben, dass die Funktion, die bei Anzeige des Blocks aufgerufen werden soll, blocks_sysinfo_display lautet. Halten Sie sich an die erkennbaren Namenskonventionen für Dateien und Funktionsnamen, um Fehlfunktionen Ihres Portals zu vermeiden. Nach dem Block-Header wird die Display-Funktion implementiert. Nach der Abfrage der Zugriffsrechte (darf der aktuelle Benutzer diesen Block sehen), werden einige simple Berechnungen vorgenommen und dem Content-Part des Blocks zugewiesen. Ist der Block-Content (und optional dessen Titel) erstellt, wird über themsideblock() der Block an das PostNuke-System übergeben. Beachten Sie: es wurde eine sprachenunabhängige Konstante für diesen Block verwendet. Diese müssen Sie noch für jede Sprache separat definieren. Legen Sie daher für eine deutsche Übersetzung eine gleichnamige Datei namens sysinfo.php im Verzeichnis includes/language/blocks/deu an (für jede andere Sprache analog). Die Datei muss folgenden Inhalt haben: Fertig. Versuchen Sie doch jetzt einmal im Zugriffsrechte-Modul, allen Benutzern außer den Admins das Recht zu nehmen, Ihren neuen Block einsehen zu dürfen. Nicht vergessen: Berechtigungen sind case-sensitiv. Abb. 18.1: Der programmierte autarke Block 216 Modul-Blöcke gehören dagegen immer zu einem Modul und werden von diesem auch geliefert. Beispiel dafür wäre der Warenkorb-Block eines Shop-Moduls. Im Kapitel Die PostNukeProgrammierung wird auf deren Implementierung eingegangen. 18 Die PostNuke-Programmierung 18.2 Sicherheit oder: die 12 goldenen Regeln der Modulentwicklung Um alle sicherheitsrelevanten Aspekte in PostNuke korrekt zu implementieren, müssen Sie sich an folgende Richtlinien halten: Ganz allgemein 1. Verwenden Sie keine globalen Variablen, da dies schlechtes Modul-Design bedeutet und in den neueren PHP-Versionen in der Regel durch die Konfigurationsvariable register_globals=Off nicht funktionieren wird. 2. Redeklarieren Sie keine von PostNuke verwendete Funktionsnamen etc. 3. Verwenden Sie in Formularen immer einen Autorisierungsschlüssel (mittels pnSecGenAuthKey()) Bevor Sie mit der eigentlichen Aufgabe innerhalb Ihrer Funktion beginnen, ... 4. ...prüfen Sie, ob ein Benutzer die Rechte hat, eine bestimmte Operation durchzuführen (mittels pnSecAuthAction()) 5. ...prüfen Sie in Formularen übergebene Autorisierungsschlüssel auf Gültigkeit (mit pnSecConfirmAuthKey()) 6. ...lesen Sie erst danach alle Formular-Felder aus, und dies nur mittels pnVarCleanFromInput(). 7. ...prüfen Sie, dass übergebene IDs und andere Parameter wirklich numerisch oder nicht leer sind (mit is_numeric() oder isset() bzw. empty()) Während Ihre Funktion die eigentliche Arbeit verrichtet, stellen Sie immer sicher, dass... 8. ...sämtliche in SQL-Ausdrücken verwendete Variablen gequotet werden (mit pnVarPrepForStore()). Alternativ dazu kann auch die ADODB-Methode $dbconn->qstr() verwendet werden. Diese besitzt den Vorteil der DatenbankUnabhängigkeit (siehe Code-Beispiel). 18.2 Sicherheit oder: die 12 goldenen Regeln der Modulentwicklung 217 9. ...sämtliche in Dateioperationen eingebaute Ausdrücke betriebssystemunabhängig werden (mit pnVarPrepForOS()) Vor der Rückgabe Ihres Modul-Contents an das System/den Browser... 10. ...lassen Sie alle nicht erlaubten HTML-Tags entfernen (mit pnVarPrepHTMLDisplay()) 11. ...lassen Sie alle nicht erlaubten Wörter zensieren (mit pnVarCensor(), optional und nur, wenn notwendig) 12. ...rufen Sie die passenden Hooks auf (mit pnModCallHooks()) Dies mag auf den ersten Blick etwas umständlich erscheinen, verhindert aber SQL-Injections und unberechtigte Zugriffe, weist unbefugt eingeschleuste Daten zurück, ermöglicht Plattformunabhängigkeit, integriert das Modul sauber ins gesamte PostNuke-System usw. 18.3 Grundlagen zur Modulentwicklung 18.3.1 Absicherung von Formularen Die von einem Formular erzeugten Daten sollten in jedem Fall auf ihre Echtheit überprüft werden. In PostNuke geschieht dies mit einem im Formular versteckt hinterlegten eindeutigen Sicherheitsschlüssel, der nur beim Laden des Formulars mittels pnSecGenAuthKey() erzeugt und in den SessionVariablen abgelegt wird. Beim Abschicken des Formulars sollte in der Ziel-Funktion der erhaltene Schlüssel mit der Funktion pnSecConfirmAuthKey() auf Echtheit überprüft werden. Diese vergleicht den Schlüssel mit der Session-Variable und löscht diese anschließend. So wird das Einschleusen von fremden oder doppelten Daten (auch über modifizierte Formulare) verhindert. 218 18 Die PostNuke-Programmierung Beachten Sie: Die Zurück-Taste des Browsers führt zu einem ungültigen Formular. Das daher notwendige Aktualisieren erzwingt eine erneute Eingabe der Formulardaten. 18.3.2 Modul- vs. Session-Variablen Modulvariablen gehören zu einem Modul. Im gesamten PostNukeSystem sind diese global verfügbar und besitzen für alle Benutzer denselben Inhalt. Modulvariablen werden beispielsweise für einfache Konfigurationseinstellungen eines Moduls genutzt. Modulvariablen werden durch pnModSetVar() in der Tabelle module_vars abgelegt. Im Gegensatz dazu werden Session-Variablen immer im Kontext der jeweiligen Sitzung eines Benutzers verwendet und unterscheiden sich daher von Benutzer zu Benutzer. Session-Variablen können beispielsweise genutzt werden, um die zuvor beschriebene FormularProblematik zu lösen (siehe auch wieder nachfolgenden SourceCode). Session-Variablen werden durch pnSessionSetVar() erzeugt und in der Tabelle session_info abgelegt. 18.3.3 Exception-Handling In PostNuke existiert kein standardisiertes Exception-Handling, auch wenn dieses Thema auf verschiedenen Internet-Seiten diskutiert wird. Dort sind Funktionen wie pnExceptionFree() o.ä. dokumentiert – leider fehlt in der aktuellen PostNuke-Version deren Implementierung. Da PHP 5 inzwischen ein eigenes Exception-Handling anbietet, wird dieses wohl über kurz oder lang in PostNuke Einzug halten. 18.3.4 PHP-Dateien und Smarty-Templates Wie bereits im Kapitel Xanthia dokumentiert, muss in pnuser.php oder pnadmin.php für die Ausgabe ein Objekt vom Typ pnRender erzeugt werden. Beispiel aus einer pnuser.php: // create a new pnRender object $pnRender =& new pnRender('rooms'); 18.3 Grundlagen zur Modulentwicklung 219 Diesem Objekt können nun Variablen für die Ausgabe übergeben werden. // assign some infos to pnRender object $pnRender->assign('roomid', 4711); Nun muss lediglich das passende Template aufgerufen werden, um die übergebenen Informationen auch auszugeben. Das geschieht mit der Funktion fetch: // call the template return $pnRender->fetch('user_output.htm'); Vom Prinzip her ist dies alles, was in einer pnuser.php/pnadmin.php an Oberflächenentwicklung zu leisten ist. Im Template findet sich neben und zwischen all dem HTMLCode ein passendes Smarty-Tag der Art: pnRender füllt die Information ein und hat seine Aufgabe damit erledigt. Das Zusammenbauen des Layouts (Themes) wird nun durch Xanthia erledigt. 18.3.5 JavaScript-Routinen valide einbinden // javascript stuff $javascript = '<script type="text/javascript"> '; // add javascript to page global $additional_header; $additional_header[] = $javascript; Bei Xanthia-Themes muss im master-Template dann noch das Plugin eingebunden werden, um die zusätzlichen Header zu laden. Dies erfolgt bei den alten nicht-Xanthia-konformen Themes noch automatisch. 220 18 Die PostNuke-Programmierung 18.3.6 Hooks Hooks (= englisch für „Haken“) sind Funktionen eines Moduls, die auf Ereignisse (Events) in anderen Modulen reagieren. Der Administrator legt fest, welche Module untereinander „verhookt“ werden. 18.3.6.1 Fremde Hooks aufrufen Am Ende einer Funktion sollten Sie sich überlegen, ob es Sinn macht, ein pnModCallHooks() auszuführen. Nehmen wir an, Sie sind der Autor des News-Moduls. Die Funktion zur Erzeugung eines Artikels ist fertig und steht vor der Rückgabe des Ergebnisses. Jetzt macht es Sinn, alle Hooks im System aufzurufen, die dem Artikel noch etwas vor dessen Ausgabe hinzufügen sollen (z.B. ein Kommentar-Modul, das ein Input-Fenster an den Artikel anhängt). Hooks können auf einzelne Objekte (so genannte Items wie z.B. News-Artikel), aber auch auf Übersichtsseiten (so genannte Categories) angewendet werden. Hooks unterteilen sich in API-Hooks und GUI-Hooks. 18.3.6.2 API-Hooks API-Hooks werden in der pnuserapi.php oder pnadminapi.php implementiert und arbeiten deshalb immer im Hintergrund, machen also keinerlei Bildschirmausgaben. Man verwendet sie, um bei gewissen Events im System z.B. Mails zu versenden, Text zu verändern, Daten anzulegen o.ä. API-Hooks können nur für folgende drei Aktionen definiert werden: Create: Sollten bei der Speicherung eines Datensatzes aufgerufen werden. Delete: Sollten aufgerufen werden, sobald ein Datensatz aus der Datenbank gelöscht wird. Transform: Sollten aufgerufen werden, bevor ein Datensatz wie z.B. ein News-Artikel ausgegeben wird. Das AutoLinksModul hat Transform-Hooks implementiert. Es verändert Content vor dessen Ausgabe (da es Text in Links transformiert). 18.3 Grundlagen zur Modulentwicklung 221 18.3.6.3 GUI-Hooks GUI-Hooks werden in der pnuser.php oder pnadmin.api implementiert und geben direkt etwas aus. Daher gibt es für diese nur folgende Aktion: Display: Display-Hooks sollten aufgerufen werden, nachdem Datensätze zur Anzeige vorbereitet wurden. Das KommentarModul hat Display-Hooks implementiert. Es hängt an den Original-Content noch seinen eigenen Content an (evtl. bestehende Kommentar-Listen und ein Kommentar-Eingabeformular). 18.3.6.4 Hook-Call Beispiel Wir zeigen solch einen Aufruf in unserem nachfolgenden Programmier-Beispiel nach dem Erstellen eines Raums (siehe pnadminapi.php). pnModCallHooks('item', 'create', $dbconn->PO_Insert_ID(), 'room_id'); Der PostNuke-Kernel wird bei solch einem Aufruf alle für das Rooms-Modul konfigurierten Create-Hooks aufrufen, den fremden Hooks mitteilen, dass es sich um ein komplettes Objekt (einen Raum, Item) und nicht um eine Übersichtsliste handelt, übergibt die Tupel-ID des zuletzt erzeugten Objekts, z.B. 4711 zusammen mit dem Namen der Spalte, in der die ID steht Damit werden alle anderen Hook-fähigen Module über das Erzeugen unseres Datensatzes informiert und können ihre Aktionen einleiten. Die Parameter unterscheiden sich je nach Art des Hooks. Die API-Dokumentation gibt hier noch ein wenig Hilfestellung. 18.3.6.5 Eigene Hooks implementieren Wenn Ihr Modul Hooks anbieten soll, müssen diese zunächst im System registriert werden. Dies geschieht über pnModRegisterHook(), die man sinnvollerweise bei der Installation des 222 18 Die PostNuke-Programmierung Moduls aufruft (also in der pninit.php). pnModUnregisterHook() sollte analog bei der Deinstallation des Moduls aufgerufen werden. Unser Beispiel hat aus Platzgründen keinen eigenen Hook implementiert. 18.3.7 Debugging von PostNuke-Modulen Mit php –l kann ein Syntaxcheck auf die PHP-Dateien durchgeführt werden. In der Modul-Entwicklung unter PostNuke arbeitet man in unklaren Situationen immer noch am schnellsten und effektivsten mit dem klassischen Gespann aus print_r($variable); die;. Die häufigsten Fehler treten durch inkorrekte SQL-Statements auf. Lassen Sie sich in diesem Fall das SQL-Statement ausgeben und testen Sie es direkt in der Datenbank, z.B. mit phpMyAdmin. Denken Sie alternativ über die Verwendung von Unit Tests nach, die aus der Welt des Extreme Programming (XP) stammen. Eine Suche im Internet nach postnuke unit tests führt Sie zum Beispiel zu pnUnit, einem noch recht jungen Modul, dass Sie in diesem Punkt (automatisiertes Testen etc.) evtl. unterstützen kann. Das Modul wird mit einer umfangreichen Dokumentation geliefert. Unit Tests mit pnUnit 18.3.8 Template/Example-Modul als Einstieg Das Template-Modul ist ein hilfreicher Einstieg in die Welt der PostNuke-Programmierung. Sie sollten sich daher an diesem Punkt die Zeit nehmen und das Modul, dessen Dateien, seinen Sourcecode und alle Kommentare genau studieren. Probieren Sie es auch aus: installieren und deinstallieren Sie es und schauen Sie, was passiert. Sie finden das Modul unter modules/Template. Beim Studium werden Sie feststellen: Das Template-Modul ist zwar pnAPI-, aber nicht Xanthia-konform. In einigen Versionen heißt das Modul auch Example. Dieses ist Xanthia-konform und kann als Basis für neue Entwicklungen herangezogen werden. 18.3 Grundlagen zur Modulentwicklung 223 Da wir uns zusätzlich die Entwicklung einfacher machen wollen, werden wir ab jetzt in einigen Punkten von dem Code-Vorschlag in Template/Example abweichen. 18.4 Entwicklung des Moduls „Rooms“ Anhand eines Beispiels möchten wir die Programmierung eines Moduls unter PostNuke veranschaulichen. Dabei wird das Zusammenwirken der Oberfläche (Template-Dateien, *.htm), der Schnittstelle zu Benutzern (pnuser.php und pnadmin.php), ModulBlöcken und der im Hintergrund laufenden APIs (pnuserapi.php, pnadminapi.php) verdeutlicht. 18.4.1 Vorgehensweise Die Vorgehensweise ist grundsätzlich immer gleich. Nach der Anforderungsdefinition macht man sich Gedanken über ein passendes Rechtesystem innerhalb des Moduls. Anschließend erfolgt die Definition der Datenbank-Struktur (die wir hier bewusst einfach halten werden). Nachdem Benutzer- und Admin-Funktionen separiert wurden, geht es an deren Implementierung. 18.4.2 Anforderungsdefinition Die fiktive Firma möchte ein Modul zur einfachen Verwaltung ihrer vielen Konferenzräume einsetzen: 224 PostNuke-Benutzer mit Administrationsrechten dürfen Räume anlegen, editieren und löschen Standard PostNuke-Benutzer sollen eine Auflistung aller Räumlichkeiten und deren Status (frei/belegt von) sehen. Ist der Raum frei, soll er auf den Benutzer gebucht werden können. Gebuchte Räume können nur vom Admin oder dem Bucher selber storniert werden. Die Rechtevergabe soll bis auf Raum-Ebene herunter möglich sein, so dass Benutzer einzelne Räume nicht sehen können. 18 Die PostNuke-Programmierung Zum Modul soll es einen Block geben, der in verkürzter Form die Funktionen der Benutzer-Sicht anbietet. Aus Gründen der Einfachheit verzichten wir hier auf erweiterte Funktionen wie Kalender (wann ist der Raum gebucht) etc. Das Beispiel darf daher gerne von Ihnen abgewandelt oder erweitert werden. 18.4.3 Rechte Aus den Anforderungen an das Modul ergibt sich das zu implementierende Rechtesystem: Nicht-eingeloggte Besucher sollen innerhalb dieses Moduls nichts durchführen dürfen. Dafür muss eine Regel im Zugriffsrechtemodul angelegt werden. Eingeloggte PostNuke-Benutzer besitzen Rechte zur Reservierung und Stornierung eines Raumes  wird vom Modul umgesetzt. Nur PostNuke-Benutzer mit Admin-Rechten dürfen Räume editieren  wird vom Modul umgesetzt. Abb. 18.2: Die Rechte für das Rooms-Modul 18.4.4 Datenbank-Struktur Für die Speicherung unserer Daten müssen wir uns eine geeignete Datenbankstruktur überlegen. Es gilt Räume zu verwalten und Buchungen für diese Räume zu tätigen. Uns sollen hier zwei Tabellen reichen: 18.4 Entwicklung des Moduls „Rooms“ 225 Lassen wir mal die dritte Normalform außer acht Tabelle RoomList: Auflistung der vorhandenen Räume room_id: interne Tupel-ID room_number: Raumnummer room_description: Raumbeschreibung Tabelle BookingList: Auflistung aller Buchungen (wenn ein Eintrag vorhanden ist, gilt der Raum als gebucht) room_id: welcher Raum ist gebucht pn_uid: welcher PostNuke-Benutzer hat gebucht 18.4.5 Name des Moduls, Verzeichnisse anlegen Achten Sie bei allen folgenden Beispielen auf die richtige Groß/Kleinschreibung und verwenden Sie wo möglich nur Kleinbuchstaben. Der eindeutige Name eines Moduls ist eminent wichtig und findet sich an vielen Stellen im Sourcecode wieder. Da der Modul-Ordner ebenfalls den Namen des Moduls tragen muss, sollte der Modulname keine Leerzeichen enthalten. Zudem ist der Modulname casesensitiv. Außerdem sollte ein Namenskonflikt mit offiziellen PNModulen vermieden werden. Das Modul soll für unsere Zwecke schlicht „rooms“ heißen. Erstellen Sie also unterhalb von modules einen Ordner namens rooms. Dort werden alle im folgenden besprochenen Dateien abgelegt. Erzeugen Sie im Verzeichnis rooms weitere Unterverzeichnisse namens pnblocks, pndocs, pnimages, pnlang/deu und pntemplates. Studieren Sie das folgende Beispiel bitte genau. 18.4.6 pnversion.php Die Datei pnversion.php beinhaltet allgemeine Angaben zum Modul und wird direkt im Verzeichnis rooms gespeichert. PostNuke nutzt die darin enthaltenen Informationen beispielsweise im Credits-Modul oder zur Steuerung des Installationsprozesses. Ebenso werden hier die im Modul verwendeten Berechtigungsstufen in 226 18 Die PostNuke-Programmierung Form eines Sicherheitsschemas bekannt gegeben und bei Initialisierung bzw. Aktivierung des Moduls im Zugriffsrechte-Modul registriert. Auch der Administrator profitiert von sauberen Angaben – sieht er doch so in der Modulverwaltung auf einen Blick, wofür das von Ihnen angebotene Modul gut ist. 'internal room id::'); ?> 18.4 Entwicklung des Moduls „Rooms“ 227 Mit der Versionsnummer sollten Sie vorsichtig umgehen. Ändern sich bei neuen Versionen Ihres Moduls die Tabellenstrukturen, sollten Sie die Versionsnummer nach oben anpassen und gleichzeitig in der Datei pninit.php die passenden Daten-Upgrade-Routinen (zum Beispiel von Version 1.0 auf Version 1.5) implementieren. Erzeugen Sie für das Modul im rooms/pndocs-Verzeichnis die oben angegebenen vier Dateien: help.txt: Alle Informationen, die Administratoren und Benutzer benötigen, um das Modul nutzen zu können. license.txt: Diese Datei sollte Informationen zur Lizenzierungsart des Moduls enthalten. credits.txt: In der Regel befinden sich hier Informationen über die Entwickler des Moduls. changelog.txt: Wurden bereits mehrere Versionen eines Moduls freigegeben, so können hier jeweils die Unterschiede zur Vorversion dokumentiert werden. Keine Sorge, die Dateien sind optional. Sollten Sie sich also beispielsweise dazu entschließen, keine Hilfe-Datei mitzuliefern, so entfernen Sie die entsprechende Zeile in der pnversion.php. 18.4.7 consts.rooms.php Diese Datei definiert einige Konstanten unseres Moduls, die wir anstelle von einfachen Strings – z.B. für den Zugriff auf Tabellenspalten – in unserem Sourcecode verwenden werden. Das ist im Original-Codevorschlag nicht der Fall, erfährt aber Unterstützung durch den Sourcecode-Editor, vereinfacht einiges und erweist sich als fehlerresistenter in der weiteren Modul-Entwicklung. 228 18 Die PostNuke-Programmierung define("RM_ROOMS_ID", 'room_id'); define("RM_ROOMS_NUMBER", 'room_number'); define("RM_ROOMS_DESCR", 'room_description'); // table definition define("RM_BOOKS", PN_TABLEPREFIX . '_rooms_bookinglist'); define("RM_BOOKS_ROOM_ID", 'room_id'); define("RM_BOOKS_PN_UID", 'pn_uid'); // common module constants define("RM_VAR_BLOCKVIEW", 'blockview'); define("RM_VAR_ACTION", 'action'); ?> 18.4.8 pntables.php Die Datei pntables.php (direkt im Verzeichnis rooms) wird dazu verwendet, alle vom Modul benötigten Tabellen in ihrer Struktur dem PostNuke-System bekannt zu geben. Hier wird die physische Tabellen-Struktur auf eine für die Programmierung allgemeinere logische Struktur abgebildet (Datenbank-Unabhängigkeit). Nach der Rückgabe an PostNuke braucht man sich nicht mehr um die physikalische Ausprägung der Tabellenstrukturen zu kümmern. So ist es im Original – Sie werden es aber durch die Definitionen in consts.rooms.php noch einfacher haben. Deswegen sieht die pntables.php jetzt so aus: 18.4 Entwicklung des Moduls „Rooms“ 229 18.4.9 pninit.php Unterschied zum Template/ExampleModul Die Datei pninit.php ist für das physikalische Anlegen der Tabellen in der Datenbank und für das Erzeugen von Modulvariablen bei der Initialisierung des Moduls zuständig, und wird direkt im Verzeichnis rooms gespeichert. Ändert sich die Versionsnummer des Moduls und führt der Administrator ein Upgrade durch, werden hier die entsprechenden Upgrade-Routinen ausgeführt. Deinstallationsroutinen kümmern sich um das Entfernen der Modul-Tabellen und Modulvariablen. Die Routinen für das Upgrading oder Entfernen des Moduls entnehmen Sie bitte dem Templates/ExampleModul. Man beachte: Die Create-Statements werden in unserem Beispiel durch die datenbank-unabhängige ADODB-Schicht erzeugt. CreateTableSQL(RM_ROOMS, $flds); $dbconn->Execute($sql[0]); if ($dbconn->ErrorNo() != 0) { pnSessionSetVar('errormsg', "DB error " . __FUNCTION__ . " " . __LINE__ . " " . $dbconn->ErrorMsg()); return false; } $datadict = NewDataDictionary($dbconn); $flds = RM_BOOKS_ROOM_ID . 230 18 Die PostNuke-Programmierung " I(4) NOTNULL PRIMARY," . RM_BOOKS_PN_UID . " I(11) DEFAULT 0 NOTNULL"; $sql = $datadict->CreateTableSQL(RM_BOOKS, $flds); $dbconn->Execute($sql[0]); if ($dbconn->ErrorNo() != 0) { pnSessionSetVar('errormsg', "DB error " . __FUNCTION__ . " " . __LINE__ . " " . $dbconn->ErrorMsg()); return false; } pnModSetVar('rooms', 'module_active', 1); return true; } ?> 18.4.10 Erster Installations-Test Das Modul ist jetzt installierbar, legt zwei Datenbank-Tabellen an, erzeugt eine Modulvariable (module_active) und lässt sich anschließend aktivieren. Funktional ist es noch nicht. Auch die Deinstallationsroutinen fehlen noch. Versuchen Sie diese selbst zu implementieren: Die Routine sollte beide Datenbank-Tabellen löschen und auch die Modulvariable entfernen. 18.4.11 Entwurf der Admin-Oberfläche Als nächstes sollte die Administrations-Oberfläche des Moduls entAbb. 18.3: Die AdminOberfläche des Rooms-Modul 18.4 Entwicklung des Moduls „Rooms“ 231 worfen werden. Dazu verwendet man die schon öfter angesprochenen Templates, die sich im rooms/pntemplates-Verzeichnis befinden müssen. Wichtig: Wenn Sie den folgenden Sourcecode abtippen, ersetzen Sie alle Zeilenumbrüche innerhalb der Smarty-Tags . Ansonsten wird Smarty einen Fatal Error melden. Nähere Angaben zu Smarty-Tags finden Sie im Kapitel Smarty. In Wirklichkeit geht die Entwicklung der Templates als auch der pn*.php-Dateien Hand in Hand. Nach einigen Iterationsschritten (Trial & Error) gelangt man zu folgender Template-Struktur. rooms_admin_menu.htm: Stellt das Admin-Menü des Moduls dar. "> | "> | "> rooms_admin_status.htm: Gibt Status- und Fehler-Meldungen aus, jeweils in grün oder rot. 232 18 Die PostNuke-Programmierung rooms_admin_newroom.htm: Oberfläche zum Anlegen neuer Räume. " method="post" enctype="application/x-www-form-urlencoded"> " /> | " value="" size="4" maxlength="32" /> | " value="" size="40" 18.4 Entwicklung des Moduls „Rooms“ 233 maxlength="32" /> " /> rooms_admin_main.htm: Die eigentliche Admin-Oberfläche. Setzt sich aus den vorangegangenen Oberflächen zusammen. | | | | | | []  [] 234 18 Die PostNuke-Programmierung Verschönern Sie doch einfach mal die Templates. Wir haben bewusst auf Tabellenstrukturen verzichtet, um den Source-Code so kurz wie möglich zu halten. 18.4.12 Smarty-Plugin Eine Liste aller zur Verfügung stehenden pnRender-Plugins finden Sie im Verzeichnis modules/pnRender/plugins. Damit werden typische PostNuke-API-Funktionen auf Smarty abgebildet. Wir verwenden in unseren Templates eine in der Version 0.750 Gold nicht vorhandene Funktionalität: pnsessiondelvar (deswegen läuft das Modul auch noch nicht). An dieser Stelle möchten wir Sie kurz bitten, ein kleines Plugin zu schreiben, welches Smarty genau um die PostNuke-Funktion des Löschens einer SessionVariablen erweitert. Wir werden im Kapitel Smarty etwas genauer auf solche Smarty-Techniken eingehen. Erstellen Sie im Verzeichnis modules/rooms/ pntemplates/plugins eine neue PHP-Datei namens function.pnsessiondelvar.php und fügen Sie folgenden Inhalt ein: trigger_error("pnsessiondelvar: attribute name required"); return false; } $result = pnSessionDelVar($name); if (isset($assign)) { $smarty->assign($assign, $result); } else { return $result; } } ?> 18.4 Entwicklung des Moduls „Rooms“ 235 18.4.13 Programmierung der pnadmin.php Der Administrator soll Räume anlegen, löschen und editieren können. Darüber hinaus sollte er die Möglichkeit haben, das Modul temporär für Benutzer ab- und wieder einzuschalten. Die verwendeten API-Funktionen sind im Kapitel Die PostNukeAPI dokumentiert. Die pnadmin.php ist eine Schnittstelle zwischen Template und den internen Funktionen des Moduls aus der pnadminapi.php. Speichern Sie den folgenden Code in rooms/pnadmin.php. Rule Rule Rule Rule Rule Rule Rule Rule Rule Rule Rule Rule 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: no global vars no redeclarations pnSecAuthKey() pnSecAuthAction() pnSecConfirmAuthKey() pnVarCleanFromInput check params pnVarPrepForStore() pnVarPrepForOS() pnVarPrepHTMLDisplay() pnVarCensor() (not necessary) pnModCallHooks include_once( 'modules/rooms/consts.rooms.php'); // main routine function rooms_admin_main() { if (!pnSecAuthAction(0, 'rooms::', '::', ACCESS_ADMIN)) { return _RM_ERR_ACCESSDENIED; } if(!pnModAPILoad('rooms', 'user')) { return _RM_ERR_APILOADFAILED; } $smarty =& new pnRender('rooms'); $smarty->assign('roomlist', 236 18 Die PostNuke-Programmierung pnModAPIFunc('rooms', 'user', 'getroomlist', array())); return $smarty->fetch( 'rooms_admin_main.htm'); } // enable or disable module for users function rooms_admin_setstate() { if (!pnSecAuthAction(0, 'rooms::', '::', ACCESS_ADMIN)) { return _RM_ERR_ACCESSDENIED; } pnModSetVar('rooms', 'module_active', !pnModGetVar('rooms', 'module_active')); pnRedirect(pnModUrl('rooms', 'admin')); } // prepare form for creating new rooms function rooms_admin_newroom() { if (!pnSecAuthAction(0, 'rooms::', '::', ACCESS_ADMIN)) { return _RM_ERR_ACCESSDENIED; } // form-handling: are there any user inputs // stored? If so, get the values $room_number = pnSessionGetVar( 'room_number'); $room_descr = pnSessionGetVar( 'room_descr'); if (!empty($room_number)) { pnSessionDelVar('room_number'); } if (!empty($room_descr)) { pnSessionDelVar('room_descr'); } // pass old form values to template // and avoid an empty form after reload 18.4 Entwicklung des Moduls „Rooms“ 237 $smarty =& new pnRender('rooms'); $smarty->assign('room_number', $room_number); $smarty->assign('room_descr', $room_descr); return $smarty->fetch( 'rooms_admin_newroom.htm'); } // pass form-values to api function // and create a new room function rooms_admin_storeroom() { if (!pnSecAuthAction(0, 'rooms::', '::', ACCESS_ADMIN)) { return _RM_ERR_ACCESSDENIED; } if (!pnModAPILoad('rooms', 'admin')) { return _RM_ERR_APILOADFAILED; } if (!pnSecConfirmAuthKey( pnVarCleanFromInput( 'authid' )) ) { return _RM_ERR_FORMNOTVALID; } // get form-vars and clean them up list($RM_ROOMS_ID, $RM_ROOMS_NUMBER, $RM_ROOMS_DESCR) = pnVarCleanFromInput(RM_ROOMS_ID, RM_ROOMS_NUMBER, RM_ROOMS_DESCR); if (!pnModAPIFunc('rooms', 'admin', 'storeroom', array (RM_ROOMS_ID => $RM_ROOMS_ID, RM_ROOMS_NUMBER => $RM_ROOMS_NUMBER, RM_ROOMS_DESCR => $RM_ROOMS_DESCR))) { // error in form, so store last // user input values pnSessionSetVar('room_number', $RM_ROOMS_NUMBER); pnSessionSetVar('room_descr', $RM_ROOMS_DESCR); pnRedirect(pnModUrl('rooms', 'admin', 'newroom')); } 238 18 Die PostNuke-Programmierung else { // room stored, everything ok pnRedirect(pnModUrl('rooms', 'admin')); }; } ?> Versuchen Sie sich doch mal an der Implementierung für das Editieren und Löschen von Räumen. 18.4.14 Programmierung der pnadminapi.php Hier werden alle Funktionen hinterlegt, die beispielsweise direkt auf der Datenbank arbeiten oder ganz allgemein nichts mit der Oberfläche zu tun haben. // store a new room item into database function rooms_adminapi_storeroom($args) { if (!pnSecAuthAction(0, 'rooms::', '::', ACCESS_ADMIN)) { pnSessionSetVar('errormsg', pnVarPrepForDisplay(_RM_ACCESSDENIED)); return false; } if (empty($args[RM_ROOMS_NUMBER]) OR empty($args[RM_ROOMS_DESCR])) { pnSessionSetVar('errormsg', pnVarPrepForDisplay(_RM_NOEMPTYFIELDS)); return false; } // for the future we provide more then // one db connection 18.4 Entwicklung des Moduls „Rooms“ 239 list($dbconn) = pnDBGetConn(); if (isset($args[RM_ROOMS_ID]) AND is_numeric($args[RM_ROOMS_ID])) { // write your UPDATE routines here } else { // INSERT new tupel $id = $dbconn->GenID(RM_ROOMS); $sql = "INSERT INTO " . RM_ROOMS . " (" . RM_ROOMS_ID . "," . RM_ROOMS_NUMBER . "," . RM_ROOMS_DESCR . ") VALUES (" . $id . "," . $dbconn->qstr($args[RM_ROOMS_NUMBER]) . "," . $dbconn->qstr($args[RM_ROOMS_DESCR]) . ");"; $dbconn->Execute($sql); if ($dbconn->ErrorNo() != 0) { pnSessionSetVar('errormsg', pnVarPrepForDisplay( _RM_ERR_INSERTFAILED . ": " . $dbconn->ErrorMsg() . " (" . __FILE__ . "/" . __LINE__ . ")")); return false; } pnSessionSetVar('statusmsg', pnVarPrepForDisplay(_RM_ADMIN_INSERTED)); // we created a tupel, so call all create // hooks. PO_Insert_ID is a portable // way to retrieve the last tupel id. pnModCallHooks('item', 'create', $dbconn->PO_Insert_ID(), RM_ROOMS_ID); return true; } } ?> 240 18 Die PostNuke-Programmierung 18.4.15 Entwurf der Benutzeroberfläche Abb. 18.4.: Die Benutzeroberfläche des Rooms-Modul Benutzer dürfen Räume auf ihren Namen buchen. Der Administrator darf jeden Raum wieder stornieren, der Benutzer nur seinen eigenen. Hier wird auch implementiert, dass Benutzer u.U. nicht jeden Raum sehen dürfen. rooms_user_status.htm: gleiche Aufgabe wie das Template für administrativen Status-Nachrichten. rooms_user_main.htm: Das Herzstück der BenutzerOberfläche. Verwendet eine Schleife (Section), um alle Räume aufzulisten und fragt gleichzeitig die Berechtigungen des Benutzers ab. 18.4 Entwicklung des Moduls „Rooms“ 241 | | | | 242 18 Die PostNuke-Programmierung | | ["> ] | ["> ] 18.4 Entwicklung des Moduls „Rooms“ 243 18.4.16 Programmierung der pnuser.php Natürlich gelten auch hier die 12 Regeln zur Modulentwicklung, soweit irgendwie möglich. Die pnuser.php, die direkt im rooms-Verzeichnis abgelegt wird, kümmert sich um die Weitergabe von Buchungs- oder Stornierungsanfragen an die pnuserapi.php. // main routine function rooms_user_main($args) { if (!pnSecAuthAction(0, 'rooms::room', '::', ACCESS_OVERVIEW)) { return _RM_ERR_ACCESSDENIED; } if(!pnModAPILoad('rooms')) { return _RM_ERR_APILOADFAILED; } $smarty =& new pnRender('rooms'); $smarty->assign('bookedroomlist', pnModAPIFunc('rooms', 'user', 'getbookedroomlist')); $smarty->assign('blockview', $args[RM_VAR_BLOCKVIEW]); return $smarty->fetch('rooms_user_main.htm'); } // more complex routine // able to distinguish between canceling // and booking rooms function rooms_user_processroom() { list($RM_BOOKS_ROOM_ID, $RM_VAR_ACTION) = pnVarCleanFromInput(RM_BOOKS_ROOM_ID, RM_VAR_ACTION); 244 18 Die PostNuke-Programmierung if (!pnSecAuthAction(0, 'rooms::', $RM_BOOKS_ROOM_ID . '::', ACCESS_OVERVIEW)) { return _RM_ERR_ACCESSDENIED; } if(!pnModAPILoad('rooms', 'user')) { return _RM_ERR_APILOADFAILED; } switch($RM_VAR_ACTION){ case 'book': break; case 'cancel': break; default: pnSessionSetVar('errormsg', pnVarPrepForDisplay( _RM_ERR_ACTIONINVALID)); pnRedirect(pnModUrl('rooms')); } // switch pnModAPIFunc('rooms', 'user', 'processroom', array(RM_BOOKS_ROOM_ID=> $RM_BOOKS_ROOM_ID, RM_BOOKS_PN_UID =>pnUserGetVar('uid'), RM_VAR_ACTION => $RM_VAR_ACTION)); pnRedirect(pnModUrl('rooms')); } ?> 18.4.17 Programmierung der pnuserapi.php Neben der pnadminapi.php eine der wichtigsten Dateien eines Moduls. Die Funktion getroomlist wird von der Benutzer- als auch von der Admin-Oberfläche benötigt. Daher befindet sie sich in der pnuserapi.php – hier haben alle Benutzer Zugriff. Die Funktion selbst fragt aber den exakten Zugriffslevel noch einmal ab, um unbefugte Abfragen zu verhindern. 18.4 Entwicklung des Moduls „Rooms“ 245 Da die Benutzeroberfläche Funktionen für „Raum buchen/stornieren“ anbietet, werden hier die dazu passenden BackendFunktionen implementiert. // retrieves a list with all rooms // and their attributes function rooms_userapi_getroomlist($args) { if (!pnSecAuthAction(0, 'rooms::', '::', ACCESS_OVERVIEW)) { pnSessionSetVar('errormsg', pnVarPrepForDisplay(_RM_ERR_ACCESSDENIED)); return false; } $sql = "SELECT * FROM " . RM_ROOMS; if (isset($args[RM_ROOMS_ID]) AND is_numeric($args[RM_ROOMS_ID])) { $sql .= " WHERE " . RM_ROOMS_ID . " = " . $args[RM_ROOMS_ID]; } $sql .= " ORDER BY " . RM_ROOMS_NUMBER . ";"; list($dbconn) = pnDBGetConn(); // have a look at the ADODB documentation // how to fetch tupels associative $dbconn->SetFetchMode(ADODB_FETCH_ASSOC); $result = $dbconn->Execute($sql); $dbconn->SetFetchMode(ADODB_FETCH_DEFAULT); if ($dbconn->ErrorNo() != 0) { pnSessionSetVar('errormsg', pnVarPrepForDisplay( _RM_ERR_GETROOMLISTFAILED)); return false; } // get the result set as an array $roomlist = array(); while(!$result->EOF) { 246 18 Die PostNuke-Programmierung $roomlist[] = $result->fields; $result->MoveNext(); } return $roomlist; } // returns all booked rooms (via join // of the room table and the booking // list table) function rooms_userapi_getbookedroomlist($args) { if (!pnSecAuthAction(0, 'rooms::', '::', ACCESS_OVERVIEW)) { pnSessionSetVar('errormsg', pnVarPrepForDisplay( _RM_ERR_ACCESSDENIED)); return false; } // create the retrieve statement (with join) // normally you have to use ADODB for this $sql = "SELECT " . RM_ROOMS . ".*, " . RM_BOOKS . "." . RM_BOOKS_PN_UID . " FROM " . RM_ROOMS . " LEFT JOIN " . RM_BOOKS . " ON " . RM_ROOMS . "." . RM_ROOMS_ID . "=" . RM_BOOKS . "." . RM_BOOKS_ROOM_ID . " WHERE "; // // // // // // // // if something special: This is for handling the internal PostNuke search engine, because we use this function to return all search results, too. To optimize our sourcecode and the usage of the sql statement, we moved the following part from the search plugin, where it is normally located. (isset($args['q']) AND isset($args['bool'])) { $w = search_split_query($args['q']); 18.4 Entwicklung des Moduls „Rooms“ 247 $flag = false; foreach($w as $word) { if($flag) { switch($args['bool']) { case 'AND': $sql .= ' AND '; break; case 'OR' : default : $sql .= ' OR '; } } else { $flag = true; } $sql .= '('; $sql .= RM_ROOMS . "." . RM_ROOMS_NUMBER . " LIKE '$word' OR "; $sql .= RM_ROOMS . "." . RM_ROOMS_DESCR . " LIKE '$word'"; $sql .= ')'; } } else { // simple where clause, no input from // search engine $sql .= " 1"; } $sql .= " ORDER BY " . RM_ROOMS . "." . RM_ROOMS_NUMBER . ";"; list($dbconn) = pnDBGetConn(); $dbconn->SetFetchMode(ADODB_FETCH_ASSOC); $result = $dbconn->Execute($sql); $dbconn->SetFetchMode(ADODB_FETCH_DEFAULT); if ($dbconn->ErrorNo() != 0) { pnSessionSetVar('errormsg', pnVarPrepForDisplay( _RM_ERR_GETBOOKEDROOMSLISTFAILED)); return false; } // ready to return the results $bookedroomlist = array(); while(!$result->EOF) { $bookedroomlist[] = $result->fields; 248 18 Die PostNuke-Programmierung $result->MoveNext(); } return $bookedroomlist; } // this routine books or cancels a room function rooms_userapi_processroom($args) { if (!pnSecAuthAction(0, 'rooms::room', $args[RM_BOOKS_ROOM_ID] . '::', ACCESS_OVERVIEW)) { pnSessionSetVar('errormsg', pnVarPrepForDisplay( _RM_ERR_ACCESSDENIED)); return false; } if (!isset($args[RM_BOOKS_ROOM_ID]) OR !is_numeric($args[RM_BOOKS_ROOM_ID])) { pnSessionSetVar('errormsg', pnVarPrepForDisplay( _RM_ERR_MISSINGID)); return false; } $statusmsg = ""; list($dbconn) = pnDBGetConn(); switch($args[RM_VAR_ACTION]){ case 'book': $sql = "INSERT INTO " . RM_BOOKS . " (" . RM_BOOKS_ROOM_ID . ", " . RM_BOOKS_PN_UID . ") VALUES (" . $dbconn->qstr($args[RM_BOOKS_ROOM_ID]) . "," . $dbconn->qstr($args[RM_BOOKS_PN_UID]) . ");"; $statusmsg = pnVarPrepForDisplay(_RM_USER_BOOKED); break; 18.4 Entwicklung des Moduls „Rooms“ 249 case 'cancel': $sql = "DELETE FROM " . RM_BOOKS . " WHERE " . RM_BOOKS_ROOM_ID . "=" . $args[RM_BOOKS_ROOM_ID]; $statusmsg = pnVarPrepForDisplay(_RM_USER_CANCELED); break; default: } // switch // an error occures when trying to book a // room that is already booked (because of // the primary attribute of room_id) $dbconn->Execute($sql); if ($dbconn->ErrorNo() != 0) { pnSessionSetVar('errormsg', pnVarPrepForDisplay( _RM_ERR_PROCESSROOMFAILED)); return false; } pnSessionSetVar('statusmsg', $statusmsg); return true; } ?> 18.4.18 Programmierung des Modul-Blocks Durch die geschickte Verwendung unserer Konzepte zur Modulentwicklung und die Wiederverwendung des intelligenten XanthiaTemplate für die Benutzeroberfläche fällt die Implementierung des Block-Codes wesentlich einfacher aus als bei autarken Blöcken. An und für sich ist nur die Display-Funktion wirklich interessant. Abb. 18.5: Der Block zum Rooms-Modul Das Xanthia-Template (siehe oben) wurde bewusst so entwickelt, dass es erkennt, ob es im Block-Kontext läuft oder nicht, und zeigt dann weniger Informationen als im Content-Fenster an. 250 18 Die PostNuke-Programmierung include_once ( "modules/rooms/pnlang/" . pnUserGetLang() . "/global.php"); // security schema of block function rooms_roomsblock_init() { pnSecAddSchema('rooms:roomsblock:', 'Block title::'); } // return block infos to Blocks module // (more infos then necessary, just for // demonstrating purposes) function rooms_roomsblock_info() { return array( 'text_type' => 'rooms', 'module' => 'rooms', 'text_type_long' => 'Show rooms', 'allow_create' 'allow_delete' 'allow_multiple' 'form_content' 'form_refresh' 'show_preview' ); => => => => => => true, true, false, false, true, true } // show block content function function rooms_roomsblock_display($row) { if (!pnSecAuthAction(0, 'rooms:roomsblock:', "$row[title]::", ACCESS_OVERVIEW)) { return ""; } if (!pnModLoad('rooms')) { return _RM_ERR_MODLOADFAILED; } $content = pnModFunc('rooms', 'user', 'main', 18.4 Entwicklung des Moduls „Rooms“ 251 array('blockview' => true)); // Populate block info and pass to theme $blockinfo['content'] = $content; if (empty($blockinfo['title'])) { $blockinfo['title'] = _RM_MODULENAME; } return themesideblock($blockinfo); } ?> 18.4.19 Search-Plugin Natürlich sollen die Konferenzräume auch über die PostNukeSuchmaschine auffindbar und im Suchergebnis direkt buchbar sein. Dazu muss ein Plugin für das Search-Modul entwickelt werden, was folgendes Aussehen haben muss: Abb. 18.6: Das Ergebnis des Such-Plugins bei der Suche nach „0815“ 'rooms', 'func_search' => 'search_rooms', 'func_opt' => 'search_rooms_opt' ); 252 18 Die PostNuke-Programmierung // one old style method, sorry for this, // but necessary for search module // shows the checkbox 'Search Rooms' in // the search options dialog function search_rooms_opt() { global $bgcolor2, $textcolor1; $output =& new pnHTML(); $output->SetInputMode(_PNH_VERBATIMINPUT); if (pnSecAuthAction(0, 'Rooms::', '::', ACCESS_OVERVIEW)) { $output->Text(" <span>   " . _RM_SEARCH_ROOMS." "); } return $output->GetOutput(); } function search_rooms() { if (!pnSecAuthAction(0, 'rooms::room', '::', ACCESS_OVERVIEW)) { return '<span class="pn-normal">'. _RM_SEARCH_RESULTS . ": " . _RM_ERR_ACCESSDENIED . ' '; } // used in pnuserapi-function for // searching (getbookedroomlist) list($active_rooms, $startnum, $total, $bool, $q) = pnVarCleanFromInput('active_rooms', 'startnum', 'total', 'bool', 'q'); if(empty($active_rooms)) { 18.4 Entwicklung des Moduls „Rooms“ 253 return; // nothing to do } if (!isset($startnum) || !is_numeric($startnum)) { $startnum = 1; } if (isset($total) && !is_numeric($total)) { unset($total); } if (!pnModAPILoad('rooms', 'user')) { return _RM_ERR_APILOADFAILED; } $bookedroomlist = pnModAPIFunc('rooms', 'user', 'getbookedroomlist', array('q' => $q, 'bool' => $bool)); // return results to template if (count($bookedroomlist)) { $smarty =& new pnRender('rooms'); $smarty->assign('bookedroomlist', $bookedroomlist); return $smarty->fetch( 'rooms_user_main.htm'); } else { return '<span class="pn-normal">' . _RM_SEARCH_RESULTS . ": " . _RM_NO_RESULTS . ' '; } } ?> Such-Plugins verarbeiten die beiden Variablen $q (der Suchstring) und $bool normalerweise direkt an Ort und Stelle und erstellen aus diesen ein SQL-Statement zur Datenbankabfrage. Da wir uns das erneute Coden des Statements ersparen wollten (einmal pnuserapi.php und einmal im Such-Plugin), übergeben wir die Parameter an die API-Funktion getbookedroomlist(), die damit zusätzlich Suchergebnisse zurückliefern kann (siehe auch Kommentar in der pnuserapi-Funktion). 254 18 Die PostNuke-Programmierung 18.4.20 Sprachpakete Wir haben noch keine Übersetzung für unsere Sprach-Konstanten definiert. Das macht man – wie bei den autarken Blöcken – mit Sprach-Dateien, die in das entsprechende rooms/pnlangUnterverzeichnis abgelegt werden müssen. Legen Sie Dateien mit den Namen admin.php, adminapi.php, pnblocks.php, user.php, userapi.php und global.php in rooms/pnlang/deu an. Füllen Sie sie mit Inhalt. In admin.php werden alle Konstanten geschrieben, die nur die Admin-Oberfläche betreffen, entsprechendes für die user.php. Die global.php enthält Konstanten, die für beides gelten, z.B. Fehler-Meldungen oder der obige Modulname. global.php: user.php: (include-Zeile gilt auch für alle anderen wie admin.php usw.) Wie findet man aber nun alle Konstanten, die im Modul definiert wurden? Verwenden Sie dazu das Languages-Modul (wie im Kapitel Module beschrieben). Beachten Sie, dass es nicht alle Konstanten erfasst, manuelle Nacharbeit ist also noch notwendig. 18.4 Entwicklung des Moduls „Rooms“ 255 18.4.21 Modul-Icon Das Administrations-Icon des rooms-Modul sollte noch geändert werden. Einfach im Ordner rooms/pnimages ein aussagekräftiges admin.gif (oder .jpg oder .png) mit einer Größe von 60 x 60 Pixel ablegen. 18.4.22 Persönliche Benutzer-Shortcuts Für PostNuke-Benutzer lassen sich persönliche Links unter Einstellungen hinterlegen, was seitens der fiktiven Firma für die Benutzeransicht des rooms-Modul geschehen soll. Legen Sie eine Datei links.rooms.php im Verzeichnis modules/NS-Your_Account/user/links an und geben Sie dieser folgenden Inhalt: Details zu dieser Vorgehensweise entnehmen Sie bitte der Beschreibung des Moduls Your_Account im Kapitel Module. 18.4.23 Tuning & Code Review Das Sahnehäubchen zum Schluss: Jetzt kann man sich noch überlegen, seinen Code oder seine Tabellen-Strukturen zu optimieren, z.B. durch Ersetzung von regulären Ausdrücken durch StringOperationen oder mittels Setzen von Indizes. Meist folgt mit einigem zeitlichen Abstand ein Code-Review: Sind unnötige Variablen oder Funktionen entfernt? Werden alle Eingaben sauber geprüft? Stimmen alle Bedingungen? Werden ReturnCodes ausgewertet? Stimmt die Dokumentation mit dem SourceCode überein? usw. 256 18 Die PostNuke-Programmierung 18.4.24 Vollständiger Modul-Test Testen Sie Ihr Modul gründlich, auch unter verschiedenen Browsern. Der Test sollte folgende Schritte umfassen: 1. Initialisierung des Moduls 2. Aktivierung des Moduls 3. Datenbank: sind alle Tabellen korrekt angelegt worden? Sind die Modulvariablen angelegt und korrekt vorbelegt? 4. Deaktivierung des Moduls (es dürfen keine Daten gelöscht werden) 5. Aktivierung des Moduls 6. Löschen des Moduls: werden alle Tabellen sauber entfernt? Auch alle Modulvariablen? Werden durch das Modul eventuell angelegte (auch temporäre) Dateien entfernt? 7. Daten anlegen 8. Berechtigungen setzen 9. Berechtigungen in Zusammenhang mit verschiedenen PostNuke-Benutzern – auch im ausgeloggten Zustand – testen. 10. Suchfunktion testen 11. Ungültige Daten eingeben 12. Versuchen Sie Ihr Modul zu hacken 13. Lassen Sie es von jemand Unbedarftem testen 18.5 Zusammenfassung Nach einem kurzen Abriss der Grundlagen wurde die Modulentwicklung anhand eines Beispiels aus dem Alltag veranschaulicht. Das Rooms-Modul zeigt gegenüber dem Templates/ExamplesModul fortgeschrittene Methodiken und kann von Ihnen beliebig erweitert werden. 18.5 Zusammenfassung 257 18.6 Ausblick Die wichtigsten (und auch in diesem Kapitel eingesetzten) SmartyTags werden nachfolgend beschrieben. 258 18 Die PostNuke-Programmierung 19 Smarty Smarty ist wie HTML eine Art tag-basierte Sprache. PostNukeModule übergeben ihren Content an pnRender, welches die SmartyTags in einem Xanthia-Template füllt. Smarty-Tags sind allerdings viel mehr als einfache Platzhalter. Das ganze Konzept ist so mächtig, dass viele Funktionen aus den PHP-Moduldateien in die Templates wandern können. Im Extremfall wären mit Smarty und seiner Plugin-Technologie sogar Templates möglich, welche die pnadmin.php und pnuser.php nur zum Laden von Smarty-Templates verwenden – und zu mehr nicht. Smarty-Tags werden in Steuerzeichen eingeschlossen. In PostNuke wird für den Anfang eines Smarty-Tags die Zeichenfolge "" verwendet. Das Kapitel soll nur einen kurzen Einblick in die wichtigsten Smarty-Konzepte, Funktionen und Plugins geben. So erklären wir die Parameter nicht, zeigen aber kleine Beispiele. Die meisten hier erläuterten Tags fanden auch in unserem vorigen ProgrammierungsKapitel Anwendung. Ausführliche Informationen zu Smarty finden sich auf http://smarty.php.net 19.1 Kommentare Kommentare werden verwendet, um die Templates zu beschreiben und damit verständlicher zu machen. 19.1 Kommentare 259 19.2 section, sectionelse section kann für Schleifenkonstrukte verwendet werden. Der Name der Section ist frei wählbar. Sections können beliebig tief verschachtelt werden. Nachname: 19.3 foreach, foreachelse Die foreach-Schleife ist als Alternative zu section zu sehen. Erforderliche Parameter sind "from" und "item". "from" definiert die Anzahl der Schleifendurchläufe, "item" ist der Name des aktuellen Elements. foreach-Schleifen bringen auch eigene Variablen mit, z.B. Ausgabe der aktuellen Iteration. Nachname: 19.4 if, elseif, else Für if können folgende Bedingungen verwendet werden: 260 gleich: eq oder == ungleich: ne oder neq oder != größer gleich: gte oder ge oder >= 19 Smarty größer als: gt oder > kleiner gleich: lte oder le oder <= kleiner als: lt oder < und: and oder && oder: or oder || Zahl gerade: "is even" oder "is not odd" Variable gerade, gruppiert nach Anzahl: "is even by" oder "is not odd by" Zahl ungerade: "is odd" oder "is not even" Variable ungerade, gruppiert nach Zahl: "is odd by" oder "is not even" Teilbar durch: "is div by" modulo: mod i ist größer als 5 19.5 Funktionen Ein Smarty-Tag ruft entweder eine Funktion oder eine Variable auf. Funktionen werden mit dem Funktionsnamen und den notwendigen Parametern aufgerufen. Getrennt werden die Parameter durch ein Leerzeichen. 19.6 Variablen In Smarty gibt es mehrere Typen von Variablen, deren Typ durch das Vorzeichen bestimmt wird. Innerhalb des Templates können Variablen Werte zugewiesen werden. 19.5 Funktionen 261 Von einem PHP-Skript/PostNuke-Modul zugewiesene Variablen werden in Smarty mit einem Dollar-Zeichen ($) versehen. Ich heisse . Auf ein assoziatives Array kann zugegriffen werden, indem nach einem Punkt (.) der Schlüssel angegeben wird: Ein Array kann auch über den Index angesprochen werden. Auf Eigenschaften und Methoden von PHP-Objekten kann mit Hilfe des -> Operators zugegriffen werden: 19.7 $smarty Es gibt auch eine reservierte -Variable. Sie wird benutzt, um auf spezielle Bereiche zuzugreifen, z.B. GET/POSTParameter, Request-Array, Cookie-Daten oder Server-Variablen. Weitere -Variablen: : 262 19 Smarty Ausgabe des UNIX-Timestamp (in Sekunden). Im folgenden Beispiel wird diese Sekundenzahl mit der Funktion "date_format" in eine lesbare Ausgabe umgewandelt. Den Namen des gerade verarbeiteten Templates enthält: 19.8 Templates durch Plugins erweitern Werden im Template zusätzliche PHP-Funktionalitäten benötigt, ist es möglich, sich eigene Funktionen zu schreiben, die das gewünschte Ergebnis in Smarty zurückgeben – die so genannten Plugins. Plugin-Namen unterliegen einer strengen Namenskonvention. Sie müssen nach dem Schema type.name benannt werden. "type" kann folgende Werte annehmen: function modifier block compiler prefilter postfilter outputfilter resource insert "name" darf aus Buchstaben, Zahlen und Unterstrichen bestehen und legt den Namen des Plugins fest. 19.8 Templates durch Plugins erweitern 263 Die Funktion innerhalb einer Plugin-Datei muss nach dem gleichen Schema smarty_type_name() benannt werden. Im Kapitel Die PostNuke-Programmierung wurde bereits ein so genanntes Funktions-Plugin erzeugt. Mit diesem kann man APIFunktionen aus PostNuke in Smarty bekannt machen. Schauen Sie sich das Beispiel einmal an, der Mechanismus ist recht einfach. Weiterführende und sehr gut strukturierte Informationen erhalten Sie auf http://smarty.php.net. 19.9 Ausblick Es folgt eine detaillierte alphabetische Auflistung aller APIFunktionen, die zur Programmierung von PostNuke zur Verfügung stehen. 264 19 Smarty 20 Die PostNuke-API Dieses Kapitel stellt Ihnen eine alphabetische Übersicht über alle in PostNuke definierten Routinen zur Verfügung. Alle Routinen werden folgendermaßen dargestellt: 20.1 pnNameDerRoutine [NameDerAPI] Aufruf $ausgabe = pnNameDerRoutine($eingabe) Aufgabe Kurzbeschreibung der Routine Eingabe Auflistung der Eingabeparameter mit Angabe des zugehörigen Datentyps. Ausgabe Auflistung der möglichen Ausgabeparameter mit Angabe des zugehörigen Datentyps. Zurückgegebene PostNuke-Fehlerkonstanten werden separat als FEHLERKONSTANTE gekennzeichnet. Beispiel Wo nötig oder sinnvoll geben wir ein Source-Code-Beispiel an. 20.1 pnNameDerRoutine [NameDerAPI] 265 20.2 Fehlerkonstanten in PostNuke BAD_PARAM Ungültiger Parameter DATABASE_ERROR Datenbank-Fehler beim Lesen oder Schreiben aufgetreten ID_NOT_EXIST Unbekannte Benutzer-, Modul- oder sonstige ID MODULE_FILE_NOT_EXIST Datei im Modul fehlt (z.B. pnuser.php o.ä.) MODULE_FUNCTION_NOT_EXIST Angegebene Funktion im Modul fehlt MODULE_ NOT_EXIST Modul fehlt (z.B. ‘News’ o.ä.) NO_PERMISSION Keine Berechtigung für aktuelle Operation NOT_LOGGED_IN Aktueller Benutzer ist nicht eingeloggt UNKNOWN Interner und unbekannter Fehler aufgetreten VARIABLE_NOT_REGISTERED Variable nicht registriert und daher unbekannt 266 20 Die PostNuke-API 20.3 accesslevelname [pnSecurity] Aufruf string = accesslevelname($level); Aufgabe Gibt in Abhängigkeit zur aktuell eingestellten Sprache in PostNuke zum numerischen Sicherheitslevel den zugehörigen Text zurück (Inhalt der Sprachkonstanten). Eingabe int $level Numerischer Sicherheitslevel Definiert sind folgende Stufen: 'ACCESS_INVALID' 'ACCESS_NONE' 'ACCESS_OVERVIEW' 'ACCESS_READ' 'ACCESS_COMMENT' 'ACCESS_MODERATE' 'ACCESS_EDIT' 'ACCESS_ADD' 'ACCESS_DELETE' 'ACCESS_ADMIN' => -1 => 0 => 100 => 200 => 300 => 400 => 500 => 600 => 700 => 800 Ausgabe Name des entsprechenden Levels oder leerer String, falls Fehler aufgetreten sind. Beispiel $level = accesslevelname(300); // $level enthält in einer deutschen Sprachumgebung // 'kommentieren' 20.4 accesslevelnames [pnSecurity] Aufruf array = accesslevelnames(); 20.3 accesslevelname [pnSecurity] 267 Aufgabe Gibt in Abhängigkeit zur eingestellten Sprache in PostNuke eine assoziative Liste der Sicherheitslevel zurück (Nummer => Inhalt der Sprachkonstanten). Bezieht sich auf dieselben Stufen wie in der Funktion accesslevelname() gezeigt. Eingabe Ausgabe Assoziatives Array der Sicherheitslevels. Beispiel $levels = accesslevelnames(); print_r($levels); // damit wird folgendes Array dargestellt: // Array // ( // [0] => keines // [100] => Übersicht // [200] => lesen // [300] => kommentieren // [400] => moderieren // [500] => editieren // [600] => hinzufügen // [700] => löschen // [800] => administrieren // ) Siehe auch accesslevelname() 20.5 addinstanceschemainfo [pnSecurity] Aufruf bool = addinstanceschemainfo($component, $schema); 268 20 Die PostNuke-API Aufgabe Registriert ein Sicherheitsschema im Rechtesystem. Die Funktion ist ein Alias für pnSecAddSchema($component, $schema); (siehe pnSecAddSchema). 20.6 authorised [pnSecurity] Aufruf bool = authorised($testrealm, $testcomponent, $testinstance, $testlevel); Aufgabe Überprüft, ob ein Benutzer berechtigt ist, eine bestimmte Operation durchzuführen. Ist ein Alias für pnSecAuthAction($testrealm, $testcomponent, $testinstance, $testlevel); (siehe pnSecAuthAction). 20.7 blocks [pnBlocks] Aufruf void blocks($side); Aufgabe Erzeugt den HTML-Code der linken, mittleren oder rechten Block-Seite und gibt diese mittels des echo-Befehls direkt aus. Eingabe string $side Position, deren Blöcke angezeigt werden sollen. Möglich sind Parameter für die linke ('l'), mittlere ('c') und rechte ('r') Seite. Ausgabe HTML-Source-Code mittels eines echo-Befehls; darüber hinaus gibt es keine speziellen Rückgabewerte. 20.6 authorised [pnSecurity] 269 Beispiel blocks('r'); // gibt die gegenwärtig zur rechten Seite zugeordneten Blöcke aus 20.8 getinstanceschemainfo [pnSecurity] Aufruf array = getinstanceschemainfo(); Aufgabe Gibt ein assoziatives Array aller Sicherheitsschemata zurück. Eingabe Ausgabe Assoziatives Array der Schemata. Beispiel $schemas = getinstanceschemainfo(); print_r($schemas); /* würde folgendes Array ausgeben (Auszug) Array ( [AvantGo::] => :: [Blocks::] => Block key:Block title:Block ID [books::Category] => Category Name::Cat ID [Censor::] => :CensorMode: [Credits::] => :: … ) */ Siehe auch getmodulesinstanceschemainfo() 270 20 Die PostNuke-API 20.9 getmodulesinstanceschemainfo [pnSecurity] Aufruf void getinstanceschemainfo(); Aufgabe Lädt die Sicherheitsschemata in eine globale Variable, damit diese im Rechte-Modul über die GUI eingesehen werden können. Eingabe Ausgabe Siehe auch getinstanceschemainfo() 20.10 pnADODBInit [pnAPI] Aufruf void pnADODBInit (); Aufgabe Initialisiert die ADODB Bibliothek. Diese Funktion wird von pnInit() aufgerufen und sollte nicht von Modulen oder Blöcken verwendet werden. Eingabe Ausgabe - 20.9 getmodulesinstanceschemainfo [pnSecurity] 271 20.11 pnAssert [pnAPI] Aufruf void pnAssert($assertion, [$file='Unknown'], [$line='Unknown'], [$msg='']); Aufgabe Überprüft eine Bedingung auf Gültigkeit und gibt gegebenenfalls eine Fehlermeldung aus. Eingabe bool string string string $assertion Bedingung die gültig sein soll $file Optionaler Parameter zur Ausgabe des Dateinamens, in dem die Routine aufgerufen wurde, falls die Bedingung zu false ausgewertet wird $line Optionaler Parameter zur Ausgabe der Zeilennummer, in der die Routine aufgerufen wurde, falls die Bedingung zu false ausgewertet wird $msg Optionaler Parameter zur Ausgabe einer benutzerspezifischen Fehlermeldung, falls die Bedingung zu false ausgewertet wird Ausgabe Void wenn erfolgreich, andernfalls Fehlermeldung und Skriptabbruch Beispiel $assertion = 5 < 3; // invalid assertion pnAssert($assertion); // führt zur Meldung ‚Assertion failed in Unknown at // line Unknown’ pnAssert($assertion, __FILE__, __LINE__, "5 ist nicht kleiner als 3") ; // führt zur Meldung ‚ Assertion failed in pnuser.php at line 4 – // 5 ist nicht kleiner als 3’ 272 20 Die PostNuke-API 20.12 pnBannerDisplay [pnBanners] Aufruf string = pnBannerDisplay([$type=0]); Aufgabe Erzeugt HTML-Code zur Darstellung eines Werbe-Banners vom angegebenen Typ. Gibt es mehrere Banner für einen Typ, so wird bei jedem Laden der PostNuke-Seite ein Banner zufällig ausgewählt. Eingabe int $type Optionaler Parameter zum Setzen des Typs. Wird $type nicht angegeben, werden immer nur Banner des Typs 0 per PHP-echo-Kommando ausgegeben. Die Banner-Typen 0, 1 und 2 werden immer mittels eines echo-Kommandos direkt an Ort und Stelle des Aufrufs der API-Funktion ausgegeben, also nicht „sauber“ an das aufrufende Programm zurückgegeben. Typen > 2 werden als String (= HTML-Code) zurückgegeben und müssen daher vom Programmierer explizit ausgegeben werden. Mit diesen BannerTypen hat der Programmierer volle Kontrolle über eine mögliche Bildschirm-Ausgabe. Ausgabe HTML-Code, der vom Browser interpretiert wird, um Banner anzeigen zu können Beispiel pnBannerDisplay(); // gibt einen Banner des Typs 0 per echo-Kommando direkt aus $banner = pnBannerDisplay(3); // $banner enthält den HTML-Code für einen Banner des Typs 3 20.12 pnBannerDisplay [pnBanners] 273 20.13 pnBlockGetInfo [pnBlocks] Aufruf array = pnBlockGetInfo($bid); Aufgabe Liefert alle Informationen zu einem Block anhand seiner ID. Eingabe int $bid ID des Blocks, dessen Informationen geladen werden sollen Ausgabe Assoziatives Array der Informationen zum jeweiligen Block. Void, falls ein Fehler aufgetreten ist. Mögliche Fehlerkonstanten sind: BAD_PARAM DATABASE_ERROR ID_NOT_EXIST Beispiel $block = pnBlockGetInfo(5); print_r($block); /* liefert nachfolgendes Array Array ( [mid] => 0 [language] => [last_update] => 20041008103400 [refresh] => 0 [active] => 1 [weight] => 10.0 [position] => l [url] => [content] => Put anything you want here [title] => Users Block [bkey] => user ) */ Siehe auch pnBlockGetInfoByTitle() 274 20 Die PostNuke-API 20.14 pnBlockGetInfoByTitle [pnBlocks] Aufruf array = pnBlockGetInfoByTitle($title); Aufgabe Liefert sämtliche Informationen zu einem Block mittels seines Titels. Eingabe string $title Titel des Blocks, dessen Informationen geladen werden sollen Ausgabe Assoziatives Array der Informationen zum jeweiligen Block. Void, falls ein Fehler aufgetreten ist. Mögliche Fehlerkonstanten sind: BAD_PARAM DATABASE_ERROR ID_NOT_EXIST Beispiel $block = pnBlockGetInfoByTitle('Login'); print_r($block); /* liefert nachfolgendes Array (Auszug) Array ( [bid] => 13 [mid] => 0 [language] => [last_update] => 20041008103400 [refresh] => 1800 [active] => 1 [weight] => 4.0 [position] => l [content] => [title] => Login [unix_update] => 1097224440 ) */ Siehe auch pnBlockGetInfo() 20.14 pnBlockGetInfoByTitle [pnBlocks] 275 20.15 pnBlockLoad [pnBlocks] Aufruf bool = pnBlockLoad($modname, $blockname); Aufgabe Lädt einen Block. Um ihn anzuzeigen, ist ein nachfolgender Aufruf von pnBlockShow() nötig. Eingabe string $modname string $blockname Name des Moduls, zu dem der Block gehört. Um Core-Blöcke zu laden, muss hier „Core“ angegeben werden. Name des Blocks Ausgabe true wenn erfolgreich. Void, falls ein Fehler aufgetreten ist. Mögliche Fehlerkonstanten sind: BAD_PARAM DATABASE_ERROR ID_NOT_EXIST MODULE_FILE_NOT_EXIST Beispiel if (!pnBlockLoad('News', 'past')) { die('Konnte Past-Articles Block aus dem News-Modul nicht laden!'); } Siehe auch pnBlockShow() 20.16 pnBlockLoadAll [pnBlocks] Aufruf array = pnBlockLoadAll(); Aufgabe Lädt alle im PostNuke-System vorhandenen Blöcke. 276 20 Die PostNuke-API Eingabe Ausgabe Assoziatives Array mit Informationen über alle Blöcke Beispiel $blocks = pnBlockLoadAll(); /* Inhalt von $blocks (Auszug) Array( ... [banners] => Array ( [func_display] => blocks_banner_block [func_add] => blocks_banner_add [func_update] => blocks_banner_update [func_edit] => blocks_banner_edit [text_type] => banners [text_type_long] => Custom Banner Display [allow_create] => [allow_multiple] => 1 [allow_delete] => [form_content] => [form_refresh] => [show_preview] => 1 [bkey] => banners [module] => Core [mid] => 0 ) ... ) */ 20.17 pnBlockShow [pnBlocks] Aufruf string = pnBlockShow($modname, $blockname, [$blockinfo = array()]); 20.17 pnBlockShow [pnBlocks] 277 Aufgabe Gibt den Output eines Block zurück, indem dessen DisplayFunktion aufgerufen wird. Eingabe string $modname string array $blockname $blockinfo Name des Moduls, zu dem der Block gehört Name des anzuzeigenden Blocks Assoziatives Array mit BlockParametern, die eventuell nötig sind, um einen Block anzuzeigen Ausgabe HTML-Code, der vom Browser interpretiert wird, um den Block anzeigen zu können. Void, falls ein Fehler aufgetreten ist. Mögliche Fehlerkonstanten sind: BAD_PARAM DATABASE_ERROR ID_NOT_EXIST MODULE_FILE_NOT_EXIST Beispiel $block = pnBlockShow('quotes', 'quote', pnBlockGetInfoByTitle('Zitat')); // $block enthält den HTML -Source-Code, vorausgesetzt // der Block heißt ‚Zitat’ Siehe auch pnBlockGetInfoByTitle() 20.18 pnBlockVarsFromContent [pnBlocks] Aufruf array = pnBlockVarsFromContent($content); Aufgabe Mittels pnBlockVarsFromContent lassen sich Block-Variablen (z.B. Konfigurationseinstellungen eines Blocks) aus einem serialisierten String, der mit pnBlockVarsToContent erzeugt wurde, gesammelt in einem Array zurückgeben. 278 20 Die PostNuke-API Eingabe string $content Block-Content Ausgabe Assoziatives Array aller Konfigurationsvariablen (sieht potentiell für jeden Block anders aus, da sich die Konfigurationseinstellungen stark unterscheiden können) Beispiel $vars = pnBlockVarsFromContent($block['content']); /* ergäbe beispielsweise $vars['storiestype'] = 4; $vars['topic'] = 2; $vars['category'] = 1; $vars['limit'] = 8; */ Siehe pnBlockVarsToContent 20.19 pnBlockVarsToContent [pnBlocks] Aufruf string = pnBlockVarsToContent($vars); Aufgabe Speichert die Konfiguration zu einem Block, indem aus einer Sammlung von Block-Variablen ein serialisierter String erzeugt und an den eigentlichen Inhalt des Blocks angefügt wird. Die BlockVariablen sind als assoziatives Array zu übergeben. Eingabe array $content Block-Variablen Ausgabe Serialisierter String, der die Block-Variablen enthält Beispiel $vars['storiestype'] = 4; $vars['topic'] = 2; $vars['category'] = 1; 20.19 pnBlockVarsToContent [pnBlocks] 279 $vars['limit'] = 8; $blockinfo['content']= pnBlockVarsToContent($vars); Siehe pnBlockVarsFromContent 20.20 pnConfigDelVar [pnAPI] Aufruf bool = pnConfigDelVar($name); Aufgabe Löscht eine Konfigurationsvariable des PostNuke-Systems. Eingabe string $name Name der Variablen, die gelöscht werden soll Ausgabe true wenn erfolgreich, andernfalls false. Mögliche Fehlerkonstanten sind: BAD_PARAM DATABASE_ERROR Beispiel $result = pnConfigDelVar('locale'); Siehe auch pnConfigGetVar(), pnConfigSetVar() 20.21 pnConfigGetVar [pnAPI] Aufruf mixed = pnConfigGetVar($name); Aufgabe Gibt den Inhalt einer spezifizierten Konfigurationsvariable zurück. 280 20 Die PostNuke-API Eingabe string $name Name der Variablen, deren Inhalt zurückgegeben werden soll. Der Name ist nicht von der Groß-/Kleinschreibung abhängig. Folgende Variablen können abgefragt werden: adminmail E-Mail des PostNuke-Admins banners Sind Banner eingeschaltet (0/1) censorlist Liste aller zensierten Wörter in einem assoziativen Array censormode In welchem Modus arbeitet das Censor-Modul (1/2/3) debug Ist Debugging eingeschaltet (0/1) language Aktuelle Sprache, z.B. „deu“ locale Aktuelle Lokalität, z.B. „de_DE“ seclevel Sicherheitslevel der Site, z.B. „Medium“ sitename Sitename slogan Slogan der Site startpage Modul, mit dem gestartet wird, z.B. ‚News’ timezone_offset Gibt Zeitzone-Offset zurück, z.B. „13“ version_id gibt ‚PostNuke’ zurück version_num PostNuke-Versionsnummer version_sub gibt Sub-Version, z.B. ‚Phoenix’ zurück Ausgabe Inhalt der Variablen. Void, wenn die Variable nicht existiert oder falls ein Fehler aufgetreten ist. Mögliche Fehlerkonstanten sind: BAD_PARAM DATABASE_ERROR Beispiel $locale = pnConfigGetVar('locale'); // enthält z.B. „de_DE“ Siehe auch pnConfigDelVar(), pnConfigSetVar() 20.21 pnConfigGetVar [pnAPI] 281 20.22 pnConfigInit [pnAPI] Aufruf bool = pnConfigInit(); Aufgabe Lädt sämtliche Konfigurationsparameter in die globale Variable $pnconfig. Diese Variable ist ein assoziatives Array(), enthält hauptsächlich Informationen zur Datenbankanbindung sowie die SystemKonfigurationsvariablen und sieht auszugsweise wie folgt aus: Array ( [dbtype] => mysql [dbtabletype] => MyISAM [dbhost] => localhost [dbuname] => root [dbpass] => [dbname] => build [system] => 1 [prefix] => ite [encoded] => 0 [pconnect] => 1 [temp] => pnTemp … ) Eingabe Ausgabe true wenn erfolgreich, andernfalls false 20.23 pnConfigSetVar [pnAPI] Aufruf bool = pnConfigSetVar($name, $value); 282 20 Die PostNuke-API Aufgabe Setzt den Inhalt einer spezifizierten Konfigurationsvariable. Falls die Variable nicht existiert, wird sie erzeugt. Eingabe string mixed $name Name der Variablen, deren Inhalt gesetzt werden soll $value Zu setzender Inhalt der Variablen Ausgabe true wenn erfolgreich, andernfalls false. Mögliche Fehlerkonstanten sind: BAD_PARAM DATABASE_ERROR Beispiel if (!pnConfigSetVar('locale', 'de_DE')) { die('Fehler beim Setzen der Konfigurationsvariable'); } Siehe auch pnConfigDelVar(), pnConfigGetVar() 20.24 pnDBGetConn [pnAPI] Aufruf array / reference = pnDBGetConn([$pass_by_reference = null]); Aufgabe Gibt ein Array von Datenbankverbindungs-Objekten oder eine Referenz darauf zurück. Zur Zeit ist nur das nullte Element im zurückgegebenen assoziativen Array verwendbar. Zukünftige Versionen von PostNuke können mit den weiteren Array-Einträgen Verbindungen zu Cluster- oder Failover-Datenbanken vorhalten. Eingabe bool $pass_by_reference Bei true wird eine Referenz auf das entsprechende Objekt zurückgegeben 20.24 pnDBGetConn [pnAPI] 283 Ausgabe Datenbankverbindungs-Objekte oder Referenz auf ein Objekt Beispiel list($dbconn) = pnDBGetConn(); /* dbconn enthält danach z.B. adodb_mysql Object ( [dataProvider] => mysql [databaseType] => mysql [database] => build [host] => localhost [user] => root [password] => [debug] => [maxblobsize] => 256000 [concat_operator] => + [substr] => substring [length] => length [random] => rand() [upperCase] => upper [fmtDate] => 'Y-m-d' [fmtTimeStamp] => 'Y-m-d H:i:s' ... ) */ $sql = "SELECT * FROM $table;"; $result = $dbconn->Execute($sql); 20.25 pnDBGetTables [pnAPI] Aufruf array = pnDBGetTables(); Aufgabe Gibt ein assoziatives Array über alle Datenbanktabellen zurück. Eingabe - 284 20 Die PostNuke-API Ausgabe Assoziatives Array aller PostNuke-Datenbanktabellen Beispiel $tables = pnDBGetTables(); print_r($tables) /* gibt ein assoziatives Array folgender Art aus Array ( … [blocks] => ite_blocks [blocks_column] => Array ( [bid] => ite_blocks.pn_bid [bkey] => ite_blocks.pn_bkey [title] => ite_blocks.pn_title [content] => ite_blocks.pn_content [url] => ite_blocks.pn_url [mid] => ite_blocks.pn_mid [position] => ite_blocks.pn_position [weight] => ite_blocks.pn_weight [active] => ite_blocks.pn_active [refresh] => ite_blocks.pn_refresh [last_update] => ite_blocks.pn_last_update [blanguage] => ite_blocks.pn_language [language] => ite_blocks.pn_language ) ... ) */ Siehe auch pnModDBInfoLoad() 20.26 pnDBInit [pnAPI] Aufruf bool = pnDBInit(); 20.26 pnDBInit [pnAPI] 285 Aufgabe Initialisiert die Datenbankverbindung (wird nur intern benötigt, da pnInit() diese Routine aufruft). Eingabe Ausgabe true wenn erfolgreich, andernfalls false Siehe auch pnInit() 20.27 pnDBSetTables [pnAPI] Aufruf void pnDBSetTables(); Aufgabe Erzeugt ein assoziatives Array über alle Datenbanktabellen, falls dieses noch nicht erzeugt wurde (wird nur intern benötigt, da pnInit() diese Routine aufruft) Eingabe Ausgabe Siehe auch pnDBGetTables() 20.28 pnGetBaseURI [pnAPI] Aufruf string = pnGetBaseURI(); 286 20 Die PostNuke-API Aufgabe Gibt die aktuelle Base URI (alles ohne Server- und Dateinamen bzw. Parametern) zurück. Eingabe Ausgabe Base URI zum PostNuke System Beispiel $baseURI = pnGetBaseURI(); // bei „http://localhost/html/index.php?module=myModule“ // käme '/html' zurück Siehe auch GetBaseURL() 20.29 pnGetBaseURL [pnAPI] Aufruf string = pnGetBaseURL(); Aufgabe Gibt die aktuelle Base URL (alles vor dem Dateinamen wie index.php) zum PostNuke System zurück. Das letzte Zeichen in der zurückgegebenen URL ist immer der Slash „/“. Eingabe Ausgabe Base URL zum PostNuke System Beispiel $baseURL = pnGetBaseURL(); // bei „http://localhost/html/index.php?module=myModule“ // käme 'http://localhost/html/' zurück Siehe auch GetBaseURI() 20.29 pnGetBaseURL [pnAPI] 287 20.30 pnGetCurrentURI [pnAPI] Aufruf string = pnGetCurrentURI([$args = array()]); Aufgabe Gibt die aktuelle URI zurück und nimmt optional Modifikationen vor (ersetzt vorhandene Parameter oder fügt neue hinzu). Eingabe array $args Optional zum Setzen/Überschreiben von Parametern Ausgabe Aktuelle URI, gegebenenfalls mit zusätzlichen/überschriebenen Parametern Beispiel $currentURI = pnGetCurrentURI(); // $currentURI könnte ‚/html/index.php’ enthalten $currentURI = pnGetCurrentURI(array('module' => 'test', 'func' => 'view')) // $currentURI könnte // ‚/html/index.php?module=test&func=view’ enthalten 20.31 pnGetStatusMsg [pnAPI] Aufruf string = pnGetStatusMsg(); Aufgabe Gibt die Statusmeldung der letzten Operation zurück und entfernt sie gleichzeitig aus den Sitzungsinformationen. Die Meldung wird entweder aus der Variablen statusmsg oder errormsg zurückgeliefert. Sind beide Variablen gleichzeitig mit Werten gefüllt, dann wird errormsg zurückgegeben. 288 20 Die PostNuke-API Eingabe Ausgabe Die letzte Statusmeldung. Void, wenn keine Meldung vorliegt. Siehe auch pnSessionGetVar(), pnSessionSetVar() 20.32 pnInit [pnAPI] Aufruf void = pnInit(); Aufgabe Initialisiert PostNuke: lädt alle Include-Dateien, erzeugt Sessions und Datenbank-Verbindungen und lädt die System-Konfiguration. Eingabe Ausgabe - 20.33 pnLocalReferer [pnAPI] Aufruf bool = pnLocalReferer(); Aufgabe Überprüft, ob ein lokaler Referer vorliegt. Ein Referer ist die URL der vorherigen Webseite, die zur aktuellen Seite geführt hat. Ein lokaler Referer liegt also vor, wenn die vorherige und die aktuelle Seite zur selben Site gehören. Eingabe - 20.32 pnInit [pnAPI] 289 Ausgabe true wenn erfolgreich, andernfalls false 20.34 pnMail [pnAPI] Aufruf bool = pnMail($to, $subject, $message, $headers, [$html = 0], [$debug = 0]); Aufgabe Versenden von Emails über SMTP. Verwendet die Einstellungen aus dem Mailer-Modul, wenn dieses aktiv ist. Ansonsten wird die Mail mit dem Standard-Mail-Befehl von PHP versendet (der über die php.ini konfiguriert wird). Eingabe string string string array bool $to $subject $message $headers $html bool $debug Empfänger der Email Betreff der Email Text der Email Extra-Header für die Email Text-Mail oder HTMLMail (optional) falls true wird der Inhalt der Mail ausgegeben Ausgabe true wenn erfolgreich, andernfalls false Beispiel $to = "[email protected]"; $subject = "This is the subject of the message"; $message = "This is the content of the message"; $headers = array(); $html = true; $result = pnMail($to, $subject, $message, $headers, $html); 290 20 Die PostNuke-API 20.35 pnModAPIFunc [pnMod] Aufruf mixed = pnModAPIFunc($modname, [$type = 'user'], [$func = 'main'], [$args = array()]) Aufgabe Führt eine API-Funktion eines Moduls aus. Das Modul muss zuvor über pnModAPILoad() geladen werden. Eingabe string $modname string $type string array $func $args Name des Moduls, in der die Funktion definiert ist Typ der API-Funktion (‚user’ oder ‚admin’) Name der Funktion Assoziatives Array mit zu übergebenden Parametern (key => value) Ausgabe Das Ergebnis der jeweils aufgerufenen Funktion. Void, falls ein Fehler aufgetreten ist. Mögliche Fehlerkonstanten sind: BAD_PARAM MODULE_FUNCTION_NOT_EXIST Beispiel $articles = pnModAPIFunc('News', 'user', 'getarticles', array('id' => 3)); if (!isset($articles)) { // pnModAPIFunc() fehlgeschlagen } elseif ($articles == false) // getarticles fehlgeschlagen } else { // getarticles erfolgreich, Daten in $articles } Siehe pnModAPILoad(), pnModFunc(), pnModLoad() 20.35 pnModAPIFunc [pnMod] 291 20.36 pnModAPILoad [pnMod] Aufruf bool = pnModAPILoad($modname, [$type = 'user'], [$force = false]) Aufgabe Lädt die API-Funktionen des angegebenen Moduls in das PostNuke-System, um einen Aufruf über pnModAPIFunc() zu ermöglichen. Gibt true zurück, wenn das Modul bereits geladen ist. GUI-Funktionen des angegebenen Moduls müssen separat über pnModLoad() geladen werden. Eingabe string $modname string $type bool $force Name des Moduls, dessen Funktionen geladen werden sollen Typ der Funktionen (‚user’ oder ‚admin’) Funktionen laden, auch wenn das Modul inaktiv ist Ausgabe true wenn erfolgreich. Void, falls ein Fehler aufgetreten ist. Mögliche Fehlerkonstanten sind: BAD_PARAM DATABASE_ERROR MODULE_FILE_NOT_EXIST MODULE_NOT_EXIST Beispiel if (!pnModAPILoad('News', 'user')) { die(' User-API-Funktionen des News-Modul nicht geladen.'); } Siehe auch pnModAPIFunc(), pnModAvailable(), pnModFunc(), pnModGetVar(), pnModLoad() 292 20 Die PostNuke-API 20.37 pnModAvailable [pnMod] Aufruf bool = pnModAvailable($modname); Aufgabe Überprüft, ob ein Modul vorhanden und gleichzeitig aktiv ist. Inaktive oder nicht initialisierte Module gelten als nicht verfügbar. Eingabe string $modname Name des Moduls, das überprüft werden soll Ausgabe true wenn erfolgreich, andernfalls false. Void, wenn ein Fehler aufgetreten ist. Mögliche Fehlerkonstanten sind: BAD_PARAM DATABASE_ERROR Beispiel if (pnModAvailable('News')) { if (!pnModAPILoad('News', 'user')) { // User-API des Moduls ‘News’ konnte nicht geladen //werden } } 20.38 pnModCallHooks [pnMod] Aufruf mixed = pnModCallHooks($hookobject, $hookaction, $hookid, $extrainfo); Aufgabe Startet die Abarbeitung von Hook-Funktionen. Eingabe string $hookobject Objekt, dessen Hooks gestartet werden sollen (‚category’/‘item’) 20.37 pnModAvailable [pnMod] 293 string $hookaction int $hookid mixed $extrainfo Aktion der Hooks (‚create’, ‚delete’, ‚transform’ oder ‚display’) Modulspezifische Objekt-ID, für die der Hook aufgerufen wird Zusätzliche Parameter, abhängig von der Hook-Aktion Ausgabe Konkateniertes Ergebnis der verschiedenen intern aufgerufenen Hook-Funktionen. Void, falls ein Fehler aufgetreten ist. Mögliche Fehlerkonstanten sind: BAD_PARAM DATABASE_ERROR MODULE_FILE_NOT_EXIST MODULE_FUNCTION_NOT_EXIST Beispiel $my_tid = 4711; $my_content = 'Mein Output'; $url_to_my_content = pnModURL('MyModule', 'user', 'my_function', array('tid' => $my_tid)); // Unser Modul ist mit der Erstellung seines Contents fertig und // bereit zur Anzeige. // Vorher wollen wir allen Display-Hooks im System die // Möglichkeit geben, unseren Content vor der Anzeige zu // verändern. Display-Hooks müssen wir als Extra-Info // die URL zu unserem Objekt mitteilen. return pnModCallHooks('item', 'display', $my_tid, $url_to_my_content); // So sieht ein Create-Hook aus: pnModCallHooks('item', 'create', $room_id, 'room_id'); Siehe auch pnModRegisterHook(), pnModUnregisterHook() 294 20 Die PostNuke-API 20.39 pnModDBInfoLoad [pnMod] Aufruf bool = pnModDBInfoLoad($modname, [$directory = '']); Aufgabe Lädt sämtliche Datenbank-Definitionen des angegebenen Moduls (z.B. Tabellen- und Spaltennamen) in die globale DatenbankInformationstabelle von PostNuke hinzu, die dann später über pnDBGetTables() abgefragt werden kann. Fehlen Datenbank-Definitionen für das angegebene Modul, wird true zurückgeliefert. Eingabe string $modname string $directory Name des Moduls, dessen DBDefinitionen geladen werden sollen Optionaler Parameter für das Verzeichnis des Moduls (falls bekannt) Ausgabe true wenn erfolgreich. Void, falls ein Fehler aufgetreten ist. Mögliche Fehlerkonstanten sind: BAD_PARAM DATABASE_ERROR MODULE_NOT_EXIST Beispiel $var = pnModDBInfoLoad('MyPersonalModule'); Siehe auch pnDBGetTables() 20.40 pnModDelVar [pnMod] Aufruf bool = pnModDelVar($modname, $name); 20.39 pnModDBInfoLoad [pnMod] 295 Aufgabe Löscht eine Modulvariable mitsamt ihrem Inhalt. Eingabe string $modname string $name Name des Moduls, zu dem die Variable gehört Name der Variablen, die gelöscht werden soll Ausgabe true wenn erfolgreich. Void, falls ein Fehler aufgetreten ist. Beispiel $result = pnModDelVar('Autolinks', 'itemsperpage'); Siehe auch pnModGetVar(), pnModSetVar() 20.41 pnModFunc [pnMod] Aufruf mixed = pnModFunc($modname, [$type = 'user'], [$func = 'main'], [$args = array()]); Aufgabe Führt eine GUI-Funktion eines Moduls aus. Das Modul muss zuvor über pnModLoad() geladen werden. Eingabe string $modname string $type string array $func $args Name des Moduls, in der die Funktion definiert ist Typ der GUI-Funktion (‚user’ oder ‚admin’) Name der Funktion Assoziatives Array mit zu übergebenden Parametern (key => value) Ausgabe Das Ergebnis der jeweils aufgerufenen Funktion. Void, falls ein Fehler aufgetreten ist. Mögliche Fehlerkonstanten sind: 296 20 Die PostNuke-API BAD_PARAM MODULE_FUNCTION_NOT_EXIST Beispiel $retc = pnModFunc('messages', 'user', 'getMessage', array('id' => 3)); if (!isset($retc)) { // pnModAPIFunc() fehlgeschlagen } elseif ($retc == false) // getMessage fehlgeschlagen } else { // getMessage erfolgreich, Daten in $retc } Siehe auch pnModAPIFunc(), pnModAPILoad(), pnModLoad() 20.42 pnModGetAdminMods [pnMod] Aufruf array = pnModGetAdminMods(); Aufgabe Gibt ein assoziatives Array über aller aktiven Module zurück, die eine Administrations-Komponente besitzen. Die Details zu den einzelnen Modulen werden über pnModGetInfo() ermittelt. Eingabe Ausgabe Liste der Admin-Module. Void, falls ein Fehler aufgetreten ist. Mögliche Fehlerkonstante ist: DATABASE_ERROR Beispiel $adminmods = pnModGetAdminMods(); print_r($adminmods); /* gäbe ein assoziatives Array folgender Art aus Array ( 20.42 pnModGetAdminMods [pnMod] 297 [34] => Array ( [name] => User [type] => 1 [directory] => NS-User [regid] => 27 [displayname] => Users [description] => User Administration [admin_capable] => 1 [user_capable] => 1 [version] => 0.2 ) ... ) */ Siehe auch pnModGetInfo(),pnModGetUserMods() 20.43 pnModGetAllMods [pnMod] Aufruf array = pnModGetAllMods(); Aufgabe Gibt eine Liste aller Module zurück. Eingabe Ausgabe Liste der Module Beispiel $allmods = pnModGetAllMods(); print_r($adminmods); /*gäbe ein assoziatives Array folgender Art aus Array ( [47] => Array ( 298 20 Die PostNuke-API [name] => Xanthia [type] => 2 [directory] => Xanthia [regid] => 0 [displayname] => Xanthia [description] => Xanthia Theme Engine [admin_capable] => 1 [user_capable] => 1 [version] => 2.0 ) ... ) */ 20.44 pnModGetIDFromName [pnMod] Aufruf int = pnModGetIDFromName($modname); Aufgabe Gibt die ID eines Moduls anhand seines Namens zurück. Eingabe string $modname Name des Moduls, zu dem die ID geliefert werden soll Ausgabe ID des Moduls. Void, falls ein Fehler aufgetreten ist. Mögliche Fehlerkonstanten sind: BAD_PARAM DATABASE_ERROR MODULE_NOT_EXIST Beispiel $modid = pnModGetIDFromName('Autolinks'); // gibt z.B. „11“ zurück 20.44 pnModGetIDFromName [pnMod] 299 20.45 pnModGetInfo [pnMod] Aufruf array = pnModGetInfo($modid); Aufgabe Gibt sämtliche Informationen zu einem Modul zurück. Eingabe int $modid ID des Moduls Ausgabe Liste der Modulvariablen. Void, falls ein Fehler aufgetreten ist. Mögliche Fehlerkonstanten sind: BAD_PARAM DATABASE_ERROR ID_NOT_EXIST Beispiel $modid = pnModGetIDFromName('Autolinks'); $modinfo = pnModGetInfo($modid); print_r($modinfo); /* gäbe ein assoziatives Array folgender Art aus Array ( [version] => 1.01 [state] => 3 [description] => Automatically link keywords [displayname] => Autolinks [regid] => 11 [directory] => Autolinks [type] => 2 [name] => Autolinks ) */ Siehe auch pnModGetAdminMods(),pnModGetIDFromName(), pnModGetUserMods(), pnModGetVar() 300 20 Die PostNuke-API 20.46 pnModGetName [pnMod] Aufruf string = pnModGetName(); Aufgabe Gibt den Namen des Moduls zurück, in dem diese Funktion aufgerufen wird. Eingabe Ausgabe Name des Moduls Beispiel $var = pnModGetName(); // z.B. ‚News’ 20.47 pnModGetUserMods [pnMod] Aufruf array = pnModGetUserMods(); Aufgabe Gibt ein assoziatives Array über aller aktiven Module zurück, die eine Benutzer-Komponente besitzen. Die Details zu den einzelnen Modulen werden über pnModGetInfo() ermittelt. Eingabe Ausgabe Liste der Benutzer-Module. Void, falls ein Fehler aufgetreten ist. Mögliche Fehlerkonstante ist. DATABASE_ERROR Beispiel $usermods = pnModGetUserMods(); 20.46 pnModGetName [pnMod] 301 print_r($usermods); /* gäbe ein assoziatives Array folgender Art aus Array ( ... [3] => Array ( [name] => FAQ [type] => 1 [directory] => FAQ [regid] => 4 [displayname] => FAQ [description] => Frequently Asked Questions [admin_capable] => 1 [user_capable] => 1 [version] => 1.11 ) ... ) */ Siehe auch pnModGetAdminMods(), pnModGetInfo() 20.48 pnModGetVar [pnMod] Aufruf mixed = pnModGetVar($modname, [$name]); Aufgabe Gibt eine spezielle Modulvariable zurück, oder alle Modulvariablen, wenn kein Variablenname angegeben ist. Der Name eines Moduls ist in der Regel der Name des Modulverzeichnisses. 302 Eingabe string $modname string $name 20 Die PostNuke-API Name des Moduls, zu dem die Variable gehört Optionaler Parameter zur Spezifizierung des Variablennamens Ausgabe Wert der spezifizierten Modulvariablen, oder ein assoziatives Array sämtlicher Modulvariablen. Void, falls ein Fehler aufgetreten ist. Mögliche Fehlerkonstanten sind: BAD_PARAM DATABASE_ERROR Beispiel $blocksarecollapseable = pnModGetVar('Blocks', 'collapseable'); // gibt z.B. ‚0’ zurück 20.49 pnModIsHooked [pnMod] Aufruf bool = pnModIsHooked($tmodule, $smodule); Aufgabe Überprüft, ob ein Modul (Target) Hook-Funktionalitäten von einem anderen Modul (Source) nutzt. Eingabe string string $tmodule $smodule Name des Target-Moduls Name des Source-Moduls Ausgabe true wenn erfolgreich, andernfalls false Beispiel $result = pnModIsHooked(‘Ratings’, ‘Autolinks’); 20.50 pnModLoad [pnMod] Aufruf bool = pnModLoad($modname, [$type = 'user'], [$force = false]); 20.49 pnModIsHooked [pnMod] 303 Aufgabe Lädt die GUI-Funktionen des angegebenen Moduls in das PostNuke-System, um einen Aufruf über pnModFunc() zu ermöglichen. Gibt auch dann true zurück, wenn das Modul bereits geladen ist. API-Funktionen des angegebenen Moduls müssen separat über pnModAPILoad() geladen werden. Eingabe string $modname string $type bool $force Name des Moduls, dessen Funktionen geladen werden sollen Typ der Funktionen (‚user’ oder ‚admin’) Funktionen laden, auch wenn das Modul inaktiv ist Ausgabe true wenn erfolgreich. Void, falls ein Fehler aufgetreten ist. Mögliche Fehlerkonstanten sind: BAD_PARAM DATABASE_ERROR MODULE_FILE_NOT_EXIST MODULE_NOT_EXIST Beispiel if (!pnModLoad('News', 'user')) { die(' User-GUI-Funktionen des News-Modul nicht geladen.'); } Siehe auch pnModAPIFunc(), pnModAPILoad(), pnModAvailable(), pnModFunc(), pnModGetVar() 20.51 pnModRegisterHook [pnMod] Aufruf bool = pnModRegisterHook($hookobject, $hookaction, $hookarea, $hookmodule, $hooktype, $hookfunc); 304 20 Die PostNuke-API Aufgabe Registriert eine Hook-Funktion. Eingabe string $hookobject string $hookaction string $hookarea string $hookmodule string $hooktype string $hookfunc Objekt, zu dem der Hook gehört (‚category’ oder ‘item’) Aktion, die zum Aufruf führt (‚create’, ‚delete’, ‚transform’ oder ‚display’) Bereich, zu dem der Hook gehört (‘GUI’ oder ‘API’) Name des Moduls, zu dem der Hook gehört Typ, zu dem die Hook-Funktion gehört (‘admin’ oder ‘user’) Name der Hook-Funktion Ausgabe true wenn erfolgreich, andernfalls false. Void, falls ein Fehler aufgetreten ist. Mögliche Fehlerkonstante ist: DATABASE_ERROR Beispiel if (!pnModRegisterHook('item', 'transform', 'API', 'Autolinks', 'user', 'transform')) { pnSessionSetVar('errormsg', 'Hook konnte nicht registriert werden.'); return false; } Siehe auch pnModUnregisterHook() 20.52 pnModSetVar [pnMod] Aufruf bool = pnModSetVar($modname, $name, $value); Aufgabe Setzt eine modulspezifische Variable. Falls die Variable nicht existiert, wird sie erzeugt. 20.52 pnModSetVar [pnMod] 305 Eingabe string $modname string $name mixed $value Name des Moduls, zu dem die Variable gehört Name der Variablen, die gesetzt werden soll Inhalt der Variablen Ausgabe true wenn erfolgreich. Void, falls ein Fehler aufgetreten ist. Mögliche Fehlerkonstanten sind: BAD_PARAM DATABASE_ERROR Beispiel $result = pnModSetVar('Autolinks', 'itemsperpage', 20); Siehe auch pnModDelVar(), pnModGetVar() 20.53 pnModUnRegisterHook [pnMod] Aufruf bool = pnModUnRegisterHook($hookobject, $hookaction, $hookarea, $hookmodule, $hooktype, $hookfunc); Aufgabe Deregistriert eine Hook-Funktion. 306 Eingabe string $hookobject string $hookaction string $hookarea string $hookmodule 20 Die PostNuke-API Objekt, zu dem der Hook gehört (‚category’ oder ‘item’) Aktion, die zum Aufruf führt (‚create’, ‚delete’, ‚transform’ oder ‚display’) Bereich, zu dem der Hook gehört (‘GUI’ oder ‘API’) Name des Moduls, zu dem der Hook gehört string $hooktype string $hookfunc Typ, zu dem die Hook-Funktion gehört (‘admin’ oder ‘user’) Name der Hook-Funktion Ausgabe true wenn erfolgreich. Void, falls ein Fehler aufgetreten ist. Mögliche Fehlerkonstante ist: DATABASE_ERROR Beispiel if (!pnModUnregisterHook('item', 'transform', 'API', 'Autolinks', 'user', 'transform')) { pnSessionSetVar('errormsg', _AUTOLINKSCOULDNOTUNREGISTER); return false; } Siehe auch pnModRegisterHook() 20.54 pnModURL [pnMod] Aufruf string = pnModURL($modname, [$type = 'user'], [$func = 'main'], [$args = array()], [$ssl=null]); Aufgabe Erzeugt eine absolute, PostNuke-kompatible URL zu einer Funktion eines Moduls und gibt die URL zurück. Eingabe string $modname string $type string array $func $args bool $ssl Name des Moduls innerhalb des PostNuke-Systems Typ der Modul-Funktion (‚user’ oder ‚admin’) Name der Modul-Funktion Parameter, die übergeben werden sollen Erzeuge URL der Form „https://...“ 20.54 pnModURL [pnMod] 307 Ausgabe Absolute URL zu einer Modulfunktion Beispiel $url = pnModURL('Messages', 'user', 'viewMessage', array('id' => 3)); // wenn die Site unter http://localhost/html/index.php zu // erreichen ist, enthält $url den Wert // ‚http://localhost/html/index.php?module= // Messages&func=viewMessage&id=3’ 20.55 pnModVarExists [pnMod] Aufruf bool = pnModVarExists($modname, $name); Aufgabe Überprüft, ob eine Modulvariable existiert. Eingabe string $modname string $name Name des Moduls, zu dem die Variable gehört Name der Variablen, die überprüft werden soll Ausgabe true wenn erfolgreich, andernfalls false Beispiel $result = pnModVarExists('Autolinks', 'itemsperpage'); // $result enthält true 20.56 pnRedirect [pnAPI] Aufruf void pnRedirect($redirectURL); 308 20 Die PostNuke-API Aufgabe Erzeugt eine absolute URL innerhalb der PostNuke-Umgebung und veranlasst durch Setzen des HTTP-Headers eine HTTP1.1Weiterleitung. Daten, die vor dem Aufruf der Funktion ausgegeben werden, werden nicht mehr angezeigt. Eingabe string $redirectURL Absolute oder relative URL, auf die umgeleitet werden soll. Die URL kann GET-Parameter enthalten. Ausgabe Beispiel // Umleitung zur Startseite pnRedirect('index.php'); // Umleitung zu einer News-Seite pnRedirect(pnModURL('News', 'user', 'view', array('sid' => 3, 'index' => 0))); // Umleitung zu einer fremden Seite pnRedirect('http://www.remotesite.com'); Siehe auch pnModURL() 20.57 pnSecAddSchema [pnSecurity] Aufruf bool = pnSecAddSchema($component, $schema); Aufgabe Registriert ein Sicherheitsschema im Rechtesystem. Das Sicherheitsschema dient zur Dokumentation der durch ein Modul angebotenen Rechte, die im Rechte-Modul über die GUI eingesehen und dort verwendet werden können. Diese Funktion hieß früher „addinstanceschemainfo()“. 20.57 pnSecAddSchema [pnSecurity] 309 Eingabe string $component string $schema Komponente des Sicherheitsschemas Instanz des Sicherheitsschemas Ausgabe true wenn das Schema hinzugefügt, false wenn es nicht hinzugefügt werden konnte, Void, falls ein interner API-Fehler aufgetreten ist. Beispiel $result = pnSecAddSchema('Kundenkartei::', 'Akte:Kunde:Kunden-ID'); 20.58 pnSecAuthAction [pnSecurity] Aufruf bool = pnSecAuthAction($testrealm, $testcomponent, $testinstance, $testlevel, [$uid]); Aufgabe Überprüft anhand der PostNuke-Berechtigungen, ob ein Benutzer die Rechte hat, eine bestimmte Operation durchzuführen. Wird keine Benutzer-ID angegeben, werden die Berechtigungen für den aktuellen Benutzer geprüft. Berechtigungen sollten jeweils so früh wie möglich innerhalb einer Funktion geprüft werden Die Funktion hieß früher „authorised()“. Eingabe int string string int int 310 $testrealm Bereich, der getestet werden soll (momentan immer 0) $testcomponent Zu prüfende Komponente $testinstance Zu prüfende Instanz $testlevel Sicherheitslevel, der erfüllt sein muss $uid Benutzer-ID 20 Die PostNuke-API Ausgabe true wenn autorisiert, andernfalls false. Void, falls eine Exception aufgetreten ist. Mögliche Fehlerkonstante ist: DATABASE_ERROR Beispiel // Prüfe ob der Benutzer Lese-Rechte auf die Kunden-Akte Nr. 4 // des Moduls 'Kundenkartei' besitzt if (pnSecAuthAction(0, 'Kundenkartei::', 'Akte:Kunde:4', ACCESS_READ)) { // Ja, Zugriff } else { // Nein, kein Zugriff } 20.59 pnSecConfirmAuthKey [pnSecurity] Aufruf bool = pnSecConfirmAuthKey(); Aufgabe Die Funktion überprüft einen Autorisierungsschlüssel, der mittels pnSecGenAuthKey() erzeugt und per verstecktem Formularfeld übergeben wurde, auf Gültigkeit. Eingabe Ausgabe true wenn der Schlüssel gültig ist, andernfalls false Beispiel if (!pnSecConfirmAuthKey()) { pnSessionSetVar('errormsg', _BADAUTHKEY); pnRedirect(pnModURL('Autolinks', 'admin', 'view')); 20.59 pnSecConfirmAuthKey [pnSecurity] 311 return true; } Siehe pnSecGenAuthKey() 20.60 pnSecGenAuthKey [pnSecurity] Aufruf string = pnSecGenAuthKey([$modname='']); Aufgabe Generiert einen Autorisierungsschlüssel, der meist in einem als „authid“ bezeichneten versteckten Formularfeld verwendet wird. Damit werden Formulare eindeutig gekennzeichnet, um z.B. ein Mehrfach-Submit ausschließen zu können oder abzusichern, dass Eingaben in ein PostNuke-System nur über die angebotenen Formulare und nicht über fremde POST/GET-Daten außerhalb des Systems gelangen. Eingabe string $modname Name des Moduls, für welches der Schlüssel gültig sein soll Ausgabe Autorisierungsschlüssel Beispiel 20.61 pnSecGetAuthInfo [pnSecurity] Aufruf array = pnSecGetAuthInfo(); 312 20 Die PostNuke-API Aufgabe Gibt Autorisierungsinformationen zum aktuellen Benutzer zurück. Eingabe Ausgabe Zweidimensionales Array mit Benutzer und Gruppenberechtigungen Beispiel $secinfo = pnSecGetAuthInfo(); print_r($secinfo); /* gibt ein zweidimensionaler Array folgender Art zurück, wobei Index 0 die speziellen Benutzerberechtigungen zeigt und Index 1 die Berechtigungen der Gruppe, zu welcher der Benutzer gehört Array ( [0] => Array ( ) [1] => Array ( [0] => Array ( [realm] => 0 [component] => .* [instance] => .* [level] => 800 ) [1] => Array ( [realm] => 0 [component] => (Polls:.*:)|(Pollblock:.*:) [instance] => .* [level] => 300 ) ) ) */ 20.61 pnSecGetAuthInfo [pnSecurity] 313 20.62 pnServerGetVar [pnAPI] Aufruf mixed = pnServerGetVar($name); Aufgabe Gibt spezifizierte Servervariablen zurück (bekannt aus der PHPVariablen $_SERVER). Eingabe string werden soll $name Name der Variablen, die zurückgegeben Ausgabe Inhalt der entsprechenden Variablen Beschreibung $_SERVER enthält nachfolgende Informationen: SYSTEMROOT, PATH, COMSPEC, PATHEXT, WINDIR, TMP, TEMP, SERVER_SOFTWARE, SERVER_NAME, SERVER_PROTOCOL, COOKIE, SERVER_PORT, REMOTE_ADDR, REMOTE_PORT, GATEWAY_INTERFACE, DOCUMENT_ROOT, REQUEST_URI, SCRIPT_NAME, SCRIPT_FILENAME, REQUEST_METHOD, QUERY_STRING, CONTENT_LENGTH, REMOTE_USER, HTTP_ACCEPT, HTTP_REFERER, HTTP_ACCEPT_LANGUAGE, HTTP_ACCEPT_ENCODING, HTTP_USER_AGENT, HTTP_HOST, HTTP_CONNECTION, HTTP_COOKIE, PATH_INFO, PATH_TRANSLATED, REDIRECT_STATUS, PHP_SELF Beispiel $host = pnServerGetVar('HTTP_HOST'); 20.63 pnSessionDelVar [pnSession] Aufruf bool = pnSessionDelVar($name); 314 20 Die PostNuke-API Aufgabe Löscht eine Session-Variable. Eingabe string $name Name der zu löschenden Session-Variable Ausgabe true wenn erfolgreich. Void, falls ein Fehler aufgetreten ist. Beispiel $result = pnSessionDelVar('errormsg'); // damit wird die Fehlermeldung innerhalb einer Benutzer-Session // gelöscht 20.64 pnSessionGetVar [pnSession] Aufruf mixed = pnSessionGetVar($name); Aufgabe Liefert eine Session-Variable zurück. Beachten Sie, dass interne PostNuke-Optimierungsvorgänge Variablen einer inaktiven Session eliminieren können. Verwenden Sie deshalb keine SessionVariablen, um längerfristig Informationen zu speichern. Eingabe string $name Name der Session-Variable, die zurückgegeben werden soll Ausgabe Inhalt der Variablen. False, wenn die Variable nicht existiert. Void, falls ein Fehler aufgetreten ist. Beispiel $errormsg = pnSessionGetVar('errormsg'); echo $errormsg; // würde die aktuelle Fehlermeldung ausgeben Siehe auch pnSessionDelVar(), pnSessionSetVar() 20.64 pnSessionGetVar [pnSession] 315 20.65 pnSessionInit [pnSession] Aufruf bool = pnSessionInit(); Aufgabe Initialisiert eine neue oder eine bestehende Session, setzt notwendige Benutzer-Cookies und erstellt aktuelle Session-Variablen. Diese Funktion wird von pnInit() aufgerufen und sollte nicht von Modulen oder Blöcken verwendet werden. Eingabe Ausgabe true wenn erfolgreich, andernfalls false. Void, falls ein interner API-Fehler aufgetreten ist. Siehe auch pnInit(), pnSessionSetup() 20.66 pnSessionSetup [pnSession] Aufruf bool = pnSessionSetup(); Aufgabe Setzt diverse PHP-Optionen, so dass PostNuke persistente Benutzer-Sessions über multiple HTTP-Verbindungen steuern kann. Diese Funktion wird von pnInit() aufgerufen und sollte nicht von Modulen oder Blöcken verwendet werden. Eingabe - 316 20 Die PostNuke-API Ausgabe true wenn erfolgreich, andernfalls false. Void, falls ein interner API-Fehler aufgetreten ist. Siehe auch pnInit(), pnSessionInit() 20.67 pnSessionSetVar [pnSession] Aufruf bool = pnSessionSetVar($name, $value); Aufgabe Setzt den Inhalt einer spezifizierten Session-Variable. Falls die Variable nicht existiert, wird sie angelegt. Eingabe string string $name Name der zu setzenden Session-Variable $value Inhalt der Session-Variablen Ausgabe true wenn erfolgreich, andernfalls false. Void, falls ein interner API-Fehler aufgetreten ist. Beispiel $result = pnSessionSetVar('errormsg', 'Tabellen konnten nicht angelegt werden'); 20.68 pnStripslashes [pnAPI] Aufruf pnStripslashes($name); (wird „by reference“ aufgrufen) Aufgabe Beseitigt Slashes in multidimensionalen Arrays (wird nur intern benötigt, da pnVarCleanFromInput diese Routine aufruft). 20.67 pnSessionSetVar [pnSession] 317 Eingabe array $name Multidimensionales Array, in dem Slashes entfernt werden sollen Ausgabe - 20.69 pnThemeGetVar [pnAPI] Aufruf mixed = pnThemeGetVar ($name); Aufgabe Gibt den Inhalt einer Variablen vom aktiven Theme zurück. Eingabe string $name Name der Variablen, die zurückgegeben werden soll Ausgabe Inhalt der entsprechenden Variablen. Void falls ein interner APIFehler aufgetreten ist. Beispiel $themepath = pnThemeGetVar('themepath'); 20.70 pnThemeLoad [pnAPI] Aufruf bool = pnThemeLoad($theme); Aufgabe Lädt das Theme des aktuellen Benutzers und setzt dabei einige globale Variablen für Rückwärts-Kompatibilität zu älteren Themes. Ein Aufruf von pnThemeLoad(pnUserGetTheme()) lädt zum Bei- 318 20 Die PostNuke-API spiel die alten pnHTML-Funktionen wie OpenTable oder CloseTable in aktuelle Theme-Umgebungen. Eingabe string $theme Name des zu ladenden Themes Ausgabe true wenn erfolgreich, andernfalls false Beispiel $result = pnThemeLoad(pnUserGetTheme()); 20.71 pnUserDelVar [pnUser] Aufruf bool = pnUserDelVar($name); Aufgabe Löscht eine Benutzer-Variable im Kontext des aktuellen Benutzers. Eingabe string $name Name der Benutzer-Variablen Ausgabe true wenn erfolgreich, andernfalls false Beispiel $result = pnUserDelVar('temp'); 20.72 pnUserGetAll [pnUser] Aufruf array = pnUserGetAll(); 20.71 pnUserDelVar [pnUser] 319 Aufgabe Gibt Informationen zu allen aktiven Benutzern in einem assoziativen Array zurück. Diese Funktion ist veraltet und wird nicht weiter gepflegt. Stattdessen sollten Sie die Funktion „getall“ aus dem Users-Modul verwenden: $users = pnModAPIFunc('users', 'user', 'getall'); Eingabe Ausgabe Array bestehend aus uname, uid, name, email, url und avatar, jeweils pro Benutzer-ID Beispiel $userinfo = pnUserGetAll(); print_r($userinfo); /* würde ein Array folgender Art ausgeben Array ( [1] => Array ( [uname] => Anonymous [uid] => 1 [name] => [email] => [url] => [avatar] => blank.gif ) ... ) */ 20.73 pnUserGetIDFromName [pnUser] Aufruf mixed = pnUserGetIDFromName($uname); Aufgabe Gibt die passende ID zum Benutzernamen zurück. 320 20 Die PostNuke-API Eingabe string $uname Benutzername Ausgabe ID des Benutzers, andernfalls false Beispiel $pnuid = pnUserGetIDFromName('Anonymous'); 20.74 pnUserGetLang [pnUser] Aufruf string = pnUserGetLang(); Aufgabe Gibt das Kürzel der Sprache zurück, die der aktuelle Benutzer gewählt hat. Siehe dazu die PostNuke-Sprachentabelle im Kapitel Sprachpakete und Sprachentabelle. Ist der aktuelle Benutzer nicht eingeloggt, wird die Standard-Sprache des Systems zurückgegeben. Eingabe Ausgabe Aktuell eingestellte Sprache. Void falls eine Exception aufgetreten ist. Mögliche Fehlerkonstante ist: DATABASE_ERROR Beispiel return pnUserGetLang(); // gibt z.B. „deu“ zurück 20.75 pnUserGetTheme [pnUser] Aufruf string = pnUserGetTheme(); 20.74 pnUserGetLang [pnUser] 321 Aufgabe Gibt den Namen des vom Benutzer eingestellten Themes zurück. Ist der aktuelle Benutzer nicht eingeloggt, wird das Standard-Theme des Systems zurückgegeben. Eingabe Ausgabe Name des Benutzer-Themes. Void falls eine Exception aufgetreten ist. Mögliche Fehlerkonstante ist: UNKNOWN Beispiel $theme = pnUserGetTheme(); 20.76 pnUserGetVar [pnUser] Aufruf string = pnUserGetVar($name, [$uid]); Aufgabe Gibt eine spezifische Benutzer-Information zurück. Ist $uid nicht angegeben, werden Daten über den aktuellen Benutzer verwendet. Eingabe string string 322 $name Name der Benutzer-Variablen, wobei $name folgenden Wert haben kann: email: E-Mail-Adresse des Benutzers name: Klartext-Name des Benutzers theme: Theme des Benutzers timezone_offset: Die Zeitzone des Benutzers, Offset von GMT – 12 uid: Benutzer-ID uname: Login-Name des Benutzers url: Homepage des Benutzers user_avatar: Dateiname des BenutzerFotos $uid Benutzer-ID 20 Die PostNuke-API Neue Variablen können durch Modul-Entwickler mittels der „register_user_var“-Funktion aus dem Modul „Modules“ hinzugefügt werden. Ausgabe Inhalt der Variablen. Void, wenn die Variable nicht existiert oder ein Fehler aufgetreten ist. Mögliche Fehlerkonstanten sind: BAD_PARAM DATABASE_ERROR ID_NOT_EXIST MODULE_FILE_NOT_EXIST MODULE_FUNCTION_NOT_EXIST MODULE_NOT_EXIST NO_PERMISSION NOT_LOGGED_IN UNKNOWN VARIABLE_NOT_REGISTERED Beispiel return pnUserGetVar('name'); // gibt z.B. „Max Mustermann“ zurück Siehe auch pnUserSetVar() 20.77 pnUserGetVars [pnUser] Aufruf array = pnUserGetVars($uid); Aufgabe Gibt sämtliche Informationen zu einer Benutzer-ID in einem assoziativen Array zurück. Diese Funktion wird nicht mehr unterstützt, da sie nicht auf Basis der neuen „Dynamic User Data“-Architektur arbeitet. Eingabe int $uid Benutzer-ID 20.77 pnUserGetVars [pnUser] 323 Ausgabe Assoziatives Array aller Informationen zu einem bestimmten Benutzer zurück. Beispiel $uservars = pnUserGetVars(pnSessionGetVar('uid')); print_r($uservars); /* gibt ein assoziatives Array nachfolgender Art aus Array ( [pn_uid] => 1 [pn_name] => [pn_uname] => Anonymous [pn_email] => [pn_femail] => [pn_url] => [pn_user_avatar] => blank.gif [pn_user_regdate] => 1091100759 [pn_user_icq] => [pn_user_occ] => [pn_user_from] => [pn_user_intrest] => [pn_user_sig] => [pn_user_viewemail] => 0 [pn_user_theme] => 0 [pn_user_aim] => [pn_user_yim] => [pn_user_msnm] => [pn_pass] => [pn_storynum] => 10 [pn_umode] => [pn_uorder] => 0 [pn_thold] => 0 [pn_noscore] => 0 [pn_bio] => [pn_ublockon] => 0 [pn_ublock] => [pn_theme] => [pn_commentmax] => 4096 [pn_counter] => 0 [pn_timezone_offset] => 12.0 [uid] => 1 [email] => [femail] => 324 20 Die PostNuke-API [name] => [theme] => [timezone_offset] => 12.0 [uname] => Anonymous [ublock] => [ublockon] => 0 [user_avatar] => blank.gif [user_icq] => … [user_occ] => [user_intrest] => [user_sig] => [bio] => [url] => [storynum] => 10 [umode] => [uorder] => 0 [thold] => 0 [noscore] => 0 [commentmax] => 4096 ) */ 20.78 pnUserLoggedIn [pnUser] Aufruf bool = pnUserLoggedIn(); Aufgabe Überprüft, ob der aktuelle Benutzer eingeloggt ist. Eingabe Ausgabe true wenn eingeloggt, andernfalls false Beispiel if (pnUserLoggedIn()) { ... 20.78 pnUserLoggedIn [pnUser] 325 // z.B. erst jetzt Ausgaben zulassen etc. } Siehe auch pnUserLogIn(), pnUserLogOut() 20.79 pnUserLogIn [pnUser] Aufruf bool = pnUserLogIn($uname, $pass, $rememberme); Aufgabe Loggt einen Benutzer ins PostNuke-System ein. Eingabe string string bool $uname $pass $rememberme Benutzername Passwort Sitzung des Benutzers bleibt maximal so lange gespeichert, wie es die durch den Administrator konfigurierten Sicherheitsrichtlinien erlauben. Ausgabe true wenn erfolgreich, andernfalls false. Void, falls eine Exception aufgetreten ist. Mögliche Fehlerkonstanten sind: BAD_PARAM DATABASE_ERROR MODULE_FILE_NOT_EXIST MODULE_FUNCTION_NOT_EXIST MODULE_NOT_EXIST Beispiel if (!pnUserLogIn('username', 'password', true)) { die('Falscher Benutzername oder unbekanntes Passwort.'); } else { // Login erfolgreich } Siehe auch pnUserLoggedIn(), pnUserLogOut() 326 20 Die PostNuke-API 20.80 pnUserLogOut [pnUser] Aufruf bool = pnUserLogOut(); Aufgabe Loggt den aktuellen Benutzer aus. Eingabe Ausgabe true wenn erfolgreich oder wenn Benutzer bereits ausgeloggt ist. Void, falls eine Exception aufgetreten ist. Mögliche Fehlerkonstante ist: DATABASE_ERROR Beispiel pnUserLogOut(); Siehe auch pnUserLoggedIn(), pnUserLogIn() 20.81 pnUserSetVar [pnUser] Aufruf bool = pnUserSetVar($name, $value); Aufgabe Speichert eine Variable für den aktuellen Benutzer. Eingabe string int $name Name der Benutzer-Variablen $value Inhalt der Variablen Ausgabe true wenn erfolgreich, andernfalls false. Void, falls eine Exception aufgetreten ist. BAD_PARAM DATABASE_ERROR 20.80 pnUserLogOut [pnUser] 327 ID_NOT_EXIST MODULE_FILE_NOT_EXIST MODULE_FUNCTION_NOT_EXIST MODULE_ NOT_EXIST NO_PERMISSION UNKNOWN VARIABLE_NOT_REGISTERED Beispiel if (!pnUserSetVar('email', '[email protected]')) { die('E-Mail Adresse des aktuellen Benutzers konnte nicht gesetzt werden'); } 20.82 pnVarCensor [pnAPI] Aufruf string = pnVarCensor ($variable, [$variable], [$variable], ...); Aufgabe Ersetzt anhand der Wortliste aus dem Censor-Modul bestimmte Wörter innerhalb einer Variable durch Sternchen. Teilworte werden nicht ersetzt. Die Funktion arbeitet unabhängig von der Groß/Kleinschreibung. Die zur Prüfung herangezogene Wortliste findet sich in der PostNuke-Variablen „CensorList“. Eingabe string $variable Name der Variablen, deren Inhalt bereinigt werden soll Ausgabe Bereinigte Variable (falls mehrere Variablen übergeben wurden, wird ein Array zurückgegeben). Void, falls ein Fehler aufgetreten ist. Beispiel // Benutzer-Kommentar erhalten und zensieren $comment = pnVarCleanFromInput('comment'); $comment = pnVarCensor($comment); 328 20 Die PostNuke-API // Enthält Kommentar zensierte Worte? $userinput = pnVarCleanFromInput('info'); if ($userinput != pnVarCensor($userinput)) { // ja, wurde zensiert } 20.83 pnVarCleanFromInput [pnAPI] Aufruf mixed = pnVarCleanFromInput ($variable, [$variable], [$variable], …); Aufgabe Liefert Input-Variablen zurück, die zum Beispiel durch ein Formular-Submit erzeugt wurden. Dabei wird der Inhalt der Variablen um als gefährlich angesehenen PHP- oder HTML-Code bereinigt. Die Anwendung von pnVarCleanFromInput vor der Übergabe von Benutzereingaben an API-Funktionen ist ein Muss und sollte als einzige Möglichkeit angesehen werden, um an Variablen aus dem globalen Namespace oder anderen Arrays wie HTTP_POST_VARS heranzukommen. Eingabe string $variable Name der Variablen, deren Inhalt bereinigt werden soll Ausgabe Bereinigte Variable (falls mehrere Variablen übergeben wurden, wird ein Array zurückgegeben). Void, falls ein Fehler aufgetreten ist. Beispiel $id = pnVarCleanFromInput('id'); // oder list($id, $category) = pnVarCleanFromInput('id', 'category'); 20.83 pnVarCleanFromInput [pnAPI] 329 20.84 pnVarPrepForDisplay [pnAPI] Aufruf mixed = pnVarPrepForDisplay($variable, [$variable], [$variable], …); Aufgabe Wandelt alle Sonderzeichen eines Textes in die entsprechende HTML-Codierung um. Die bereinigte Variable sollte nur zur Ausgabe verwendet werden, da sich die mehrfache Anwendung dieser Funktion (oder anderer wie pnVarPrepHTMLDisplay) auf die gleiche Variable kumuliert. Die Bereinigung ist nicht umkehrbar. Eingabe string $variable Name der Variablen, deren Inhalt bereinigt werden soll Ausgabe Bereinigte Variable (falls mehrere Variablen übergeben wurden, wird ein Array zurückgegeben). Void, falls ein Fehler aufgetreten ist. Beispiel $var = pnVarPrepForDisplay("5 >= 3 & 6 > 4"); // ergibt: 5 >= 3 & 6 > 4 20.85 pnVarPrepForOS [pnAPI] Aufruf mixed = pnVarPrepForOS($variable); Aufgabe Bereinigt Variablen, so dass sie betriebssystemunabhängig z.B. als (Teile von) Dateinamen verwendet werden können. Eingabe string 330 $variable 20 Die PostNuke-API Name der Variablen, deren Inhalt bereinigt werden soll Ausgabe Bereinigte Variable (falls mehrere Variablen übergeben wurden, wird ein Array zurückgegeben). Void, falls ein Fehler aufgetreten ist. Beispiel $filename = "modules/" . pnVarPrepForOS($modulename); 20.86 pnVarPrepForStore [pnAPI] Aufruf mixed = pnVarPrepForStore($variable, [$variable], [$variable], ...); Aufgabe Bereitet eine Variable durch das Quoten von Zeichen so auf, dass der Inhalt der Variablen in einer SQL-Datenbank korrekt verwendet werden kann. Zeitgleich werden durch die Anwendung dieser Funktion SQL-Injections vermieden. Die bereinigte Variable sollte nur zur Speicherung in der Datenbank verwendet werden, da sich die mehrfache Anwendung dieser Funktion (oder anderer wie pnVarPrepForDisplay) auf die gleiche Variable kumuliert. Die Bereinigung ist nicht umkehrbar, es sei denn der Entwickler weiß, wie oft pnVarPrepForStore angewendet wurde. Eingabe string $variable Name der Variablen, deren Inhalt für die DB vorbereitet werden soll Ausgabe Bereinigte Variable (falls mehrere Variablen übergeben wurden, wird ein Array zurückgegeben). Void, falls ein Fehler aufgetreten ist. Beispiel $myval .= "Abfrage auf 'Wert'"; $query .= " AND $columndef['thiscolumn'] = '" . pnVarPrepForStore($myval) . "'"; 20.86 pnVarPrepForStore [pnAPI] 331 // $myval wird folgendermaßen gequotet: Abfrage auf \'Wert\' // man beachte, dass pnVarPrepForStore in einer SQL-Anfrage // in Single-Quotes gehört 20.87 pnVarPrepHTMLDisplay [pnAPI] Aufruf mixed = pnVarPrepHTMLDisplay($variable, [$variable], [$variable], …); Aufgabe Bereinigt eine HTML-Code enthaltende Ausgabevariable um alle nicht erlaubten HTML-Tags. Zur Überprüfung wird die PostNukeVariable „AllowableHTML“ abgefragt; anschließend werden alle unerlaubten Tags gequotet. Sonderzeichen werden wie bei pnVarPrepForDisplay HTML-konform umgesetzt. Der bereinigte HTML-Code sollte nur zur Ausgabe verwendet werden, da sich die mehrfache Anwendung dieser Funktion (oder anderer wie pnVarPrepForDisplay) auf die gleiche Variable kumuliert. Die Bereinigung ist nicht umkehrbar. Eingabe string $variable Name der Variablen, deren Inhalt bereinigt werden soll (Referenz) Ausgabe Bereinigte Variable (falls mehrere Variablen übergeben wurden, wird ein Array zurückgegeben). Void, falls ein Fehler aufgetreten ist. Beispiel $var = pnVarPrepHTMLDisplay("5 >= 3 & 6 > 4"); // ergibt bei abgeschaltetem -Tag: 5 >= 3 & // 6 > 4 Siehe auch pnVarPrepForDisplay() 332 20 Die PostNuke-API 20.88 pnVarValidate [pnAPI] Aufruf bool = pnVarValidate($var, $type, [$args]); Aufgabe Überprüft eine Benutzervariable auf (syntaktische) Gültigkeit. Momentan kann diese Funktion prüfen, ob eine übergebene E-MailAdresse oder URL gültig ist. Eingabe string $var string $type array $args Name der Variablen, deren Inhalt überprüft werden soll Typ der Überprüfung (Gegenwärtig ‚email’ oder ‚url’) Wird zur Zeit nicht verwendet Ausgabe true bei erfolgreicher Prüfung, andernfalls false. Void falls ein interner API-Fehler aufgetreten ist. Mögliche Fehlerkonstanten sind: BAD_PARAM DATABASE_ERROR UNKNOWN VARIABLE_NOT_REGISTERED Beispiel if (!pnVarValidate('[email protected]', 'email')) { echo „Ungültige E-Mail-Adresse.“; } 20.88 pnVarValidate [pnAPI] 333 21 PostNuke 0.760 Die CSS-Klassen in der styleNN.css verringern sich weiter. pnnormal, pn-title und pn-pagetitle werden gegenüber 0.750 nicht mehr verwendet. Stattdessen werden h1- und h2-Tags eingesetzt. Die Benutzeroberflächen der Blöcke und Module verwenden jetzt ul-Listen statt ·. Die Angabe von op=modload&file=index ist jetzt optional. Für die Druckausgabe kommt ein eigenes Printer-Theme zum Einsatz. Das alte Präfix „NS-„ wurde bei allen Modulen entfernt. Es sind jetzt wesentlich mehr Module pnAPI- und Xanthiakonform. Darüber hinaus sind zwei neue Module hinzugekommen, die zur Drucklegung des Buches nicht mehr beschrieben werden konnten. Der Core sowie die Modul- und Blockverwaltung hat einige Detailverbesserungen und Zusatzfunktionen erhalten, z.B. die Definition eines Modul-Alias oder das temporäre Abschalten der Site zu Wartungszwecken. Die Benutzerverwaltung und die Administrationsoberfläche der admin.php sind verbessert worden, z.B. kategorisierbare Admin-Ansicht. 20.88 pnVarValidate [pnAPI] 335 22 Begriffe Im PostNuke-Umfeld gibt es einige wichtige Begriffe, deren Verständnis für den Betrieb einer PostNuke-Seite von essentieller Bedeutung ist. 22.1 ADODB Ein Datenbank-Abstraktionslayer für PHP (und Python). ADODB unterstützt den Zugriff auf folgende Datenbanken: MySQL, PostgreSQL, Interbase, Firebird, Informix, Oracle, MS SQL, Foxpro, Access, ADO, Sybase, FrontBase, DB2, SAP DB, SQLite, Netezza, LDAP, und generisches ODBC, ODBTP. Wird im PostNukeUmfeld für den Zugriff auf Datenbanken verwendet. 22.2 API (Application Programming Interface) Eine Programmier-Schnittstelle. PostNuke bietet eine eigene API an, die für die Entwicklung von Blöcken und Modulen wichtige Befehle zur Verfügung stellt, z.B. Abfrage der Rechte eines Benutzers, Setzen von Konfigurationsvariablen, Herstellen von Verbindungen zur Datenbank etc. 22.1 ADODB 337 22.3 Artikel Vergleichbar mit den Artikeln einer Zeitung werden die Texte in Artikeln organisiert. Artikel stellen üblicherweise den Hauptanteil des Inhalts eines PostNuke-Systems dar. Bereits in der Einführung haben wir unseren ersten Artikel erstellt. 22.4 BaseURI Die BaseURI (wobei URI = Uniform Resource Identifier) des PostNuke-Systems setzt sich ausschließlich aus den Verzeichnispfaden der gesamten URL zusammen. Ist PostNuke beispielsweise unter http://localhost/html/index.php zu erreichen, dann enthält die BaseURI den Wert /html. 22.5 BaseURL Die BaseURL (wobei URL = Uniform Resource Locator) des PostNuke-Systems ist die BaseURI mit vorangestelltem http:// gefolgt vom Hostnamen des Systems. Bei http://localhost/html/index.php wäre die BaseURL demnach http://localhost/html/. 22.6 BBCode (Bulletin Board Code) BBCode ist eine Sammlung verschiedener Zeichenfolgen, mit denen man bestimmte Anwendungen – wie z.B. Foren oder einige PostNuke-Module – anweisen kann, Text zu formatieren. 338 22 Begriffe 22.7 Benutzer Ein PostNuke-System bietet die Möglichkeit, unabhängig von der verwendeten Plattform Benutzer anzulegen, die sich mit einem Benutzernamen und Passwort am System anmelden können. Benutzer können unterschiedlichen Benutzergruppen zugeordnet sein und damit unterschiedliche Rechte haben. Benutzer werden auch Mitglieder genannt. Siehe Besucher. 22.8 Berechtigungen Siehe Zugriffsrechte. 22.9 Besucher Benutzer der Webseite, die sich nicht am System angemeldet haben, werden als „anonyme Besucher“ oder einfach als „Besucher“ bezeichnet. Besucher haben beispielsweise nur Leserechte auf Teile der Webseite, während Benutzer auch Artikel auf der Webseite verfassen dürfen. Siehe Benutzer. 22.10 Block Die sichtbare Oberfläche von PostNuke wird größtenteils aus Blöcken zusammengesetzt, welche die kleinste funktionale Einheit in PostNuke darstellen. Je nach Theme können Blöcke unterschiedlich aussehen, meist handelt es sich aber um rechteckige Bereiche, die links, rechts oder mittig auf der Oberfläche angeordnet werden können. Das Hauptmenü oder der Login-Bereich sind Beispiele für Blöcke. 22.7 Benutzer 339 22.11 Blog Ein Blog ist eine Website, auf der fortlaufend Beiträge veröffentlicht werden. Neue Beiträge stehen ganz oben und werden von Besuchern zuerst gelesen. Anschließend schreiben diese einen Kommentar dazu, verlinken darauf oder führen andere Aktionen durch. PostNuke ist in seiner Standard-Ausstattung also eher ein Blog denn ein CM-System. Erst Dritt-Module wie Pagesetter machen aus PostNuke ein ernstzunehmendes CMS. 22.12 Category Kategorien stellen keine Unterhierarchie zu Themen (inhaltliche Strukturierung der Seite) dar und haben mit diesen nichts zu tun, was man beim Erstellen eines Artikels vermuten könnte, sondern ermöglichen es, Artikel nach anderen Gesichtspunkten zu gruppieren. Kategorien sind beispielsweise „Artikel“, „Exklusiv-Bericht“, „Frisch eingetroffen“, „2005“ o.ä., Bereiche also, die in jedem Thema verwendet werden könnten. Natürlich hindert Sie auch keiner daran, die Kategorien „Deutschland“ und „Ausland“ nur in Verbindung mit dem Thema „Politik“ zu verwenden, und so Thema und Kategorie einigermaßen miteinander korrelieren zu lassen. Passt ein Artikel in keine vorhandene Kategorie bzw. es ist nicht notwendig, diesen Artikel zu kategorisieren, dann kann man die Kategorie „Beiträge“ wählen. Zusammengefasst: Themen dienen der vertikalen, Kategorien der horizontalen Gruppierung von Artikeln. Themen werden global im gesamten PostNuke-System verwendet (durch das Topics-Modul realisiert), Kategorien gibt es dagegen nur im News-Modul. 22.13 CMS (Content Management System) CMS verwalten das Layout der Site in so genannten Templates unabhängig vom Inhalt; das Look and Feel bleibt so auf allen Seiten der Site hindurch einheitlich. Tagesaktuell und ortsunabhängig können Redakteure Inhalte der Site bearbeiten, ohne sich mit HTMLDetails oder Programmierung befassen zu müssen. 340 22 Begriffe 22.14 Content Englisch für Inhalt (in Form von Texten, Bildern, Dateien, Audio/Video etc.). 22.15 Core Der Kern eines Systems, auch Kernel genannt. 22.16 Document Root Das Stamm-Verzeichnis, aus dem ein Webserver wie Apache oder IIS Dokumente an einen Browser ausliefert. 22.17 Ephemerid Ein Ephemerid, zu deutsch etwa „Eintagsfliege“, ist in PostNuke der Begriff für einen kalenderartigen Eintrag nach dem Motto „Was geschah heute vor x Jahren?“ oder „Es war einmal...“. 22.18 Extranet Ein Auftritt im Internet-Bereich, der nur einer geschlossenen Benutzergruppe (z.B. einer Partner-Firma) zugänglich ist. Das Extranet wird dabei oft im Corporate Identity des Partners gestaltet und bietet neben dem Content aus dem Internet-Auftritt spezielle, nur auf den Partner zugeschnittene Informationen. In PostNuke erstellt man Extranets mit der Multisite-Technik. 22.14 Content 341 22.19 Fork Englisch für „Verzweigung“. Bezeichnet ein neues System, welches auf PostNuke basiert. 22.20 Gruppe Benutzer können in Gruppen zusammengefasst werden, um die Rechtevergabe zu vereinfachen. So sind beispielsweise alle Administratoren üblicherweise einer Gruppe zugeordnet. 22.21 Hack Bezeichnet im PostNuke-Umfeld eine geänderte Datei, um z.B. den Kernel um eine bestimmte Funktion zu erweitern. Wird ein Hack nicht Bestandteil der nächsten Releases, so wird dessen Pflege bei einem Update des Systems immer Probleme bereiten. Neuere Module lassen sich über Plugins erweitern, womit Hacks überflüssig werden. 22.22 Hooks Hooks (= englisch für „Haken“) sind Funktionen eines Moduls, die auf Ereignisse (Events) in anderen Modulen reagieren. 22.23 Intranet Ein Intranet ist ein lokales Netz, welches zur Informationsdarstellung (beispielsweise firmeninterne Mitteilungen) die Techniken des Internets wie HTTP-Protokoll, CMS und Internet-Browser verwendet. 342 22 Begriffe 22.24 LAMPP Abkürzung für Linux, Apache, MySQL, PHP, Perl. Siehe XAMPP. 22.25 Modul Nahezu sämtliche Funktionalität eines PostNuke-Systems wird von Modulen bereitgestellt. Üblicherweise werden Erweiterungen für PostNuke in Form von Modulen angeboten. Die Funktionen für das Erstellen von Artikeln, die wir bereits benutzt haben, stellt z.B. das News-Modul zur Verfügung. Andere Module stellen beispielsweise Downloads zur Verfügung oder verwalten die Benutzer des PostNuke-Systems. 22.26 Multisites Im PostNuke-Umfeld die Bezeichnung für den Betrieb mehrerer Webpräsenzen auf einer einzigen physikalischen PostNukeInstallation. 22.27 Permissions Siehe Zugriffsrechte. 22.28 Portal Bezeichnung für ein System, das verschiedene Internet-Dienste unter einer Oberfläche vereint und meist für eine umfassende Kommunikations- und Interaktionsplattform verwendet und oft mit einem CMS realisiert wird. Der Begriff stammt ursprünglich aus dem Lateinischen und beschreibt einen architektonisch hervorgehobenen Eingang von Tempeln, Kirchen und Palästen. 22.24 LAMPP 343 22.29 PostNuke PostNuke ist ein in PHP geschriebenes, im Quelltext vorliegendes, hochmodulares CMS. 22.30 PostNuke-API Siehe API. 22.31 Rechte Siehe Zugriffsrechte. 22.32 RSS (RDF Site Summary) RSS (= RDF Site Summary, wobei RDF = Resource Description Framework) ist ein Format zum Austauschen von Nachrichten. Mittels eines RSS-Blocks können Inhalte von anderen Seiten integriert werden, auch von anderen PostNuke-Portalen. 22.33 Section In Sektionen lassen sich sehr lange Artikel, zum Beispiel ganze Handbücher, strukturiert unterbringen. Sektionen teilen sehr lange Artikel in Einzelseiten auf, zwischen denen man wie in den Seiten eines Buches blättern kann. Sektionen sind wie Kategorien ebenfalls unabhängig von Themen. 344 22 Begriffe 22.34 SSL Secure Socket Layer. Verschlüsselt die Datenübertragung zwischen Webserver und Webbrowser. Der Datenstrom über diese Verbindung kann zwar noch abgehört werden, die Daten sind für den Lauscher allerdings unbrauchbar. Oft wichtig in Intranets, Extranets, bei der Implementierung von Formularen oder Online-Shops. 22.35 Template Englisch für Schablone. Ein Template ist eine Datei, die das Layout (eines Teils) einer Webseite z.B. über HTML und CSS festlegt – ohne deren Inhalt. Der Content wird über Platzhalter in einem Template dynamisch eingefügt. Eine Sammlung von TemplateDateien ergibt in PostNuke ein Theme. 22.36 Theme Das Layout und Verhalten einer PostNuke-Oberfläche hängt vom verwendeten Theme ab. Ein Theme besteht physikalisch aus einer Reihe von Dateien, die das Grundgerüst der Seite und deren einzelne Elemente wie Modulausgaben oder Blöcke anordnen und grafisch gestalten. Die Dateien eines Themes werden Templates (zu deutsch etwa „Schablone“) genannt und enthalten vorwiegend HTML-Code. Themes, (anderes Wort wäre „Skin“, „Layout“ oder übersetzt etwa „Schablone“), bieten die Möglichkeit, das optische Erscheinungsbild eines PostNuke-Systems unabhängig vom Inhalt zu gestalten. Jeder Benutzer des Systems kann sich aus den vom Administrator installierten Themes sein eigenes konfigurieren und damit „seine“ PostNuke-Seite individuell gestalten. Themes sind vergleichbar mit Skins in anderen Programmen und in großer Zahl verfügbar. 22.34 SSL 345 22.37 Topics Der Administrator kann beliebig Themen hinzufügen, löschen und umbenennen. Das Thema eines Artikels wird bei dessen Erstellung gewählt. Auch später lässt es sich jederzeit ändern. Themen einer Firmenwebseite sind zum Beispiel „Presse“, „Jobs“, „Knowledge Base“ usw. Siehe auch Category. 22.38 URI Uniform Resource Identifier. Liefert eine Internet-Adresse ohne den Servernamen zurück. Aus der URL http://localhost/postnuke/ html/index.php wird damit postnuke/html/index.php. 22.39 URL Uniform Resource Locator. Andere Bezeichnung für eine Internetadresse, wie z.B. http://localhost/postnuke/html/index.php. 22.40 WAMPP Abkürzung für Windows, Apache, MySQL, PHP, Perl. Siehe XAMPP. 22.41 Workflow Englische Bezeichnung für Arbeitsablauf. Spielen in Zusammenhang mit Freigabe-Mechanismen eine bedeutende Rolle in CMSystemen. 346 22 Begriffe 22.42 Wiki Wiki ist ebenfalls – wie BBCode – eine Syntax, mit deren Hilfe Textformatierungen vorgenommen werden können. Ein Hauptunterschied ist die Art wie ein Tag geöffnet bzw. geschlossen wird. Eine unformatierte Ausgabe wird beispielsweise in den Tags ... ausgegeben. 22.43 WYSIWYG (What You See Is What You Get) Im PostNuke-Umfeld werden die eingebauten HTML-Editoren als WYSIWYG-fähig bezeichnet, wenn Sie die Formatierung von Texten ohne Programmier- und HTML-Kenntnisse ermöglichen und der Artikel nach dem Abspeichern genau so wieder abrufbar ist, wie er vom Benutzer eingegeben und formatiert wurde. 22.44 XAMPP WAMPP und LAMPP werden unter dem Begriff XAMPP zusammengefasst, wobei das „X“ als Platzhalter für die verschiedenen Betriebssystem-Varianten dient. 22.45 Xanthia Xanthia ist das in PostNuke ab Version 0.750 verwendete Layoutbzw. Template-Verwaltungssystem. 22.46 XMLRPC Entfernte Funktionsaufrufe, wobei der Datenaustausch im XMLFormat stattfindet. Mit dem XMLRPC-Modul in PostNuke lassen 22.42 Wiki 347 sich so auch mit anderen Tools als dem Webbrowser Inhalte ins CMS einbringen. 22.47 XTE (Xanthia Templating Engine) Siehe Xanthia. 22.48 Zugriffsrechte PostNuke erlaubt eine sehr fein granulierte und mitunter komplex anmutende Zugriffskontrolle auf seine Inhalte und Funktionen. Themen, Kategorien, Module, Blöcke und vieles weitere mehr können für bestimmte Benutzer oder Gruppen freigegeben oder gesperrt werden. 348 22 Begriffe 23 Links 23.1 Zu PostNuke http://www.postnuke.com: Das englischsprachige HauptPortal, Heimat von PostNuke, Forum, Fundstelle für Blöcke, Module und Themes jeder Art http://www.post-nuke.net: Das größte deutschsprachige Portal mit Dokumentation, Handbüchern und exzellentem Support http://www.pncommunity.de: Diese Seite ist die Heimat des PostNuke Übersetzungs-Projektes - neben den offiziellen Sprachpaketen für PostNuke gibt es auch die Übersetzungen für My_eGallery, PostCalendar, PostWrap sowie Xexpress (Content Express) http://www.pnaddons.com: Weitere PostNuke Add-Ons und Hacks http://www.warp-speed.de: Auf dieser Seite findet sich beinahe jeder Code-Schnipsel zu allen Nuke-Systemen. http://www.netz-id.de: Online-Magazin für Webmaster mit Schwerpunkt auf Nuke-Systemen. http://www.markwest.me.uk: Seite eines der Core-Entwickler von PostNuke http://lottasophie.sourceforge.net: PostNuke Modules :: EZComments :: My_eGallery http://www.cmsmodules.com: Umfangreiche Modulsammlung für fast jedes freie CMS 23.1 Zu PostNuke 349 23.2 Weitere Module 350 http://smarty.php.net: Dokumentation zum Smarty-Projekt https://sourceforge.net/project/showfiles.php?group_id=442 76&package_id=46091: Heimat des typetool HTML WYSIWYG-Editors http://www.elfisk.dk: Pagesetter und Photoshare 23 Links Index . .htaccess 54 A Abarbeitungsreihenfolge 58 Absicherung von Formularen 218 ACCESS_ADD 58 ACCESS_ADMIN 58 ACCESS_COMMENT 57 ACCESS_DELETE 58 ACCESS_EDIT 57 ACCESS_MODERATE 57 ACCESS_NONE 57 ACCESS_OVERVIEW 57 ACCESS_READ 57 accesslevelname 267 accesslevelnames 267 addinstanceschemainfo 268 AddStory 81 Admin 82 Admin Messages 83 ADODB 230 Anmelden am System 27 Apache 53 API 265 API-Hooks 221 Aufruf von Modulen 34 autarke Blöcke 32, 213 authorised 269 AutoLinks 85 Autoren-Gruppe 43 AvantGo 86 B Backup 178 Banners 87 Beiträge 40 Benutzer 28 Benutzerberechtigungen 57 Berechtigungen 55 Blöcke 31, 36, 37, 63 blocks 269 Blocks 90 Block-Verkleinerung 37 Block-Zonen 139 Button Link Block 64 C Caching 141 Categories Menu 65 ccblock.htm 145 Censor 91 CMS 1 Comments 92 config.php 17 Config-Cache 140 Content Management Systeme 1 Content-Fenster 26 Credits 93 Custom Banner Display 65 custom pnRender block 76 CVS 195 D Datenbank-Tabellen 163 Display module output in a block 77 Index 351 Display Poll 65 Downloads 95 K E Encoder 191 eNvolution 3 Ephemerids 66, 96 erweiterter Text 41 Exception-Handling 219 Extranets 167 F FAQ 97 Footer 26 Forks 2 Formatierungstyp 41 Freigabe von Artikeln 42 FXP Currency Exchange 66 G Generic Menu 66 getinstanceschemainfo 270 getmodulesinstanceschemainfo 271 Groups 99 Gruppen 30 Gruppenberechtigungen 57 GUI-Hooks 222 Kategorien 46 Komponente 56 L Languages 69, 100 Latest Web Links 70 Legal Documents 102 Leistungsfähigkeit 3 Login 27 Logo Block for Xanthia Themes 77 LostPassword 103 lsblock.htm 145 M Mailer 104 MailUsers 104 mainmenu.htm 145 manuelle Installation 16 master.htm 145 Members List 105 Messages 106 Modul-Block 32, 250 Module 31, 79 Modules 107 Modul-Variablen 219 Multisites 108, 167 N H Hauptmenü-Block 38 Header 26 Hooks 48, 221 HTML 67 HTML-Editor 38 HTTP-Kompression 191 News 109 Newsticker 32 NewUser 109 O Online 70 I IDN-Domains 22 install.php 13 Installation 13 Instanz 56 Intranet 167 IPSec 55 ISO 639-2/T 202 352 Index P Pagesetter 109 Past Articles 70 Past_Nuke 110 Performance 187 Permissions 111 Permissions Reset 178 persönliche Seite 131 PGP 55 PHP 51 PHP Script 71 PHPNuke 2 Plain Text 71 Plugins 263 pnadmin.php 236 pnadminapi.php 239 pnADODBInit 271 pnAntiCracker 20 pnAPI 265 pnAssert 272 pnBannerDisplay 273 pnBlockGetInfo 274 pnBlockGetInfoByTitle 275 pnBlockLoad 276 pnBlockLoadAll 276 pnBlockShow 277 pnBlockVarsFromContent 278 pnBlockVarsToContent 279 pnConfigDelVar 280 pnConfigGetVar 280 pnConfigInit 282 pnConfigSetVar 282 pnDBGetConn 283 pnDBGetTables 284 pnDBInit 285 pnDBSetTables 286 pnGetBaseURI 286 pnGetBaseURL 287 pnGetCurrentURI 288 pnGetStatusMsg 288 pnHTML 135 pnInit 289 pninit.php 230 pnLocalReferer 289 pnMail 290 pnmini 181 pnModAPIFunc 291 pnModAPILoad 292 pnModAvailable 293 pnModCallHooks 293 pnModDBInfoLoad 295 pnModDelVar 295 pnModFunc 296 pnModGetAdminMods 297 pnModGetAllMods 298 pnModGetIDFromName 299 pnModGetInfo 300 pnModGetName 301 pnModGetUserMods 301 pnModGetVar 302 pnModIsHooked 303 pnModLoad 303 pnModRegisterHook 304 pnModSetVar 305 pnModUnRegisterHook 306 pnModURL 307 pnModVarExists 308 pnRedirect 308 pnRender 112, 135, 155 pnSecAddSchema 309 pnSecAuthAction 310 pnSecConfirmAuthKey 311 pnSecGenAuthKey 312 pnSecGetAuthInfo 312 pnSecurity Alert 206 pnServerGetVar 314 pnSessionDelVar 314 pnSessionGetVar 315 pnSessionInit 316 pnSessionSetup 316 pnSessionSetVar 317 pnStripslashes 317 pntables.php 229 pnThemeGetVar 318 pnThemeLoad 318 pnuser.php 244 pnuserapi.php 245 pnUserDelVar 319 pnUserGetAll 319 pnUserGetIDFromName 320 pnUserGetLang 321 pnUserGetTheme 321 pnUserGetVar 322 pnUserGetVars 323 pnUserLoggedIn 325 pnUserLogIn 326 pnUserLogOut 327 pnUserSetVar 327 pnVarCensor 328 pnVarCleanFromInput 329 pnVarPrepForDisplay 330 pnVarPrepForOS 330 pnVarPrepForStore 331 pnVarPrepHTMLDisplay 332 pnVarValidate 333 pnversion.php 226 Polls 113 PostNuke 0.760 335 PostNuke Swiss Army Knife 177 Index 353 PostNuke-API 265 Programmierung 213 PSAK 177 Q Quotes 114 R Random Quote 77 Ratings 115 Rechte 55 Recommend Us 116 Recovery 180 Referers 116 Reviews 117 rsblock.htm 145 RSS Extra 73 RSS Newsfeed 72 S Safe Mode 52 Search 118 Search Box 73 Search-Plugin 252 Sections 119 Seitenfuß 26 Seitenkopf 26 Session-Variablen 219 Settings 120 Short URLs 142 Show Admin Messages 64 Sicherheit 51 Sideblocks 26 Simple File Include 73 Slogan 20 Smarty 137, 259 Smarty-Plugin 235 Sprachpakete 18, 100, 201, 255 SSL 54 Startseite 25 Stats 120 Story Related Links 74 Story Titles 74 style.css 144 styleNN.css 144 Submit News 121 Swiss Army Knife 177 354 Index T Tabellen 163 Template 122 Theme Reset 178 theme.php 146 Themen 45 Themes 135 Today’s Big Story 75 Top List 123 Topics 45, 123 Topics Menu 75 trimwhitespace 142 Tuning 187 typetool 38, 124 Ü Übersetzer 100 U URLs 205 user.php 27 User’s Custom Box 76 User’s Login 75 Users 125 utf8 207 V Valider HTML-Code 155 Verzeichnisstruktur 157 virtuelle Hosts 168 Voraussetzungen 5 VPN 55 W Web Links 126 whoisit.inc.php 169 Wiki 47, 127 Workflow 39 WYSIWYG 38 X XAMPP 9 xaninfo.php 146 xaninit.php 146 Xanthia 127, 135 Xaraya 3 Xmlrpc 129 XOOPS 3 XTE 135 Z Zeitzone 207 Zugriffsarten 57 Zugriffsrechte 55, 111 Y Your_Account 131 Index 355 Internet Server - Einrichten und Verwalten Read more Dionysos und das Dionysische German Read more Energieausweis - Das große Kompendium GERMAN Read more Internet and Intranet Security Read more Internet und Intranet: Herausforderung E-Business, 3. Auflage Read more DVD-Player. DivX-Filme erstellen und bearbeiten GERMAN Read more Curso De Internet E Intranet Read more Microsoft SQL Server 7.0 - Kompendium . Für Administration und Entwicklung GERMAN Read more Moderne C-Programmierung: Kompendium und Referenz (Xpert.press) (German Edition) Read more Ränkespieler und Rivalen (Das schwarze Auge) GERMAN Read more Excel 2002 - Kompendium. Professionell analysieren und planen GERMAN Read more Das C++ Kompendium: STL, Objektfabriken, Exceptions GERMAN Read more Klinische MC-Fragen rasch und einfach erstellen Read more Ajax und Java German Read more Erlebnis und Bildung German Read more Arbeits- und Organisationspsychologie GERMAN Read more Bilanzanalyse und Kennzahlen German Read more Kompendium Physikalische Medizin und Rehabilitation: Diagnostische und therapeutische Konzepte Read more Räuchern und Pökeln GERMAN Read more Java 2 Kompendium GERMAN Read more Kompendium Medieninformatik: Medienpraxis GERMAN Read more Kompendium Multimediales Lernen GERMAN Read more Wissensproduktion und Wissenstransfer German Read more Tatort Internet. Das Handbuch gegen Rufschädigung, Beleidigung und Betrug im Internet GERMAN Read more Moderne C-Programmierung: Kompendium und Referenz Read more Exchange Server 2007 SP1 und Outlook Kompendium Read more Kompendium der visuellen Information und Kommunikation Read more Das AJAX Kompendium. Web 2.0-Anwendungen mit JavaScript und XML GERMAN Read more Das Auge und das Schwert Read more Das Geschehen und das Schweigen Read more Recommend Documents Internet Server - Einrichten und Verwalten HTML und das World Wide Web Copyright © 1995 by O'Reilly/International Thomson Verlag Bitte denken Sie daran: Sie düfe... Dionysos und das Dionysische German ... Energieausweis - Das große Kompendium GERMAN Andreas Weglage (Hrsg.) Energieausweis – Das große Kompendium Andreas Weglage (Hrsg.) Energieausweis – Das große Kom... Internet and Intranet Security Internet und Intranet: Herausforderung E-Business, 3. Auflage Internet und Intranet 3 Berlin Heidelberg New York Hongkong London Mailand Paris Tokio Johann Hæller Manfred Pils R... DVD-Player. DivX-Filme erstellen und bearbeiten GERMAN DVD-Player Unser Online-Tipp für noch mehr Wissen … ... aktuelles Fachwissen rund um die Uhr – zum Probelesen, Downlo... Curso De Internet E Intranet Cybercursos.net INTRODUCCIÓN ¿QUÉ ES I NTERNET ? EVOLUCIÓN DE INTERNET Década de los '60 Década de los '70 Década de los... Microsoft SQL Server 7.0 - Kompendium . Für Administration und Entwicklung GERMAN Vorwort 1 Einführung 1.1 Wat is en Dampfmaschin? 1.2 Datenbanksysteme 1.3 Relationale Datenbank-Managementsysteme 1.4 Au... Moderne C-Programmierung: Kompendium und Referenz (Xpert.press) (German Edition) Die Reihe Xpert.press vermittelt Professionals in den Bereichen Softwareentwicklung, Internettechnologie und IT-Managem... Ränkespieler und Rivalen (Das schwarze Auge) GERMAN ... × Report "Das PostNuke Kompendium: Internet-, Intranet- und Extranet-Portale erstellen und verwalten GERMAN" Your name Email Reason -Select Reason- Pornographic Defamatory Illegal/Unlawful Spam Other Terms Of Service Violation File a copyright complaint Description Close Send × Sign In Email Password Remember me Forgot password? Sign In Login with Facebook Our partners will collect data and use cookies for ad personalization and measurement. Learn how we and our ad partner Google, collect and use data. Agree & close