[php] Artikelverwaltung

[Björn Schotte]

* Manfred G. wrote:
> http://phpnuke.org
> Kennt sich jemand damit aus?

Nein. Ich möchte aber gerne mal das System beschreiben, welches
ich im PHP-Center entwickelt habe. Es basiert im Wesentlichen
auf der Sache, die ich für die Online-Community http://www.telemat.de/
entwickelt habe, fürs PHP-Center jedoch noch mal schnell komplett
neu schrieb. Benötigter Zeitaufwand für die etwas über 1000 Zeilen
Code war ein halber Manntag (4h). Ich kann das include-file dafür
gerne releasen, allerdings wird es sicherlich nicht out-of-the-box
einsetzbar sein, mithin befindet es sich auch noch in Entwicklung.

Dennoch hier zum Verständnis eine "Artikelverwaltung" beschrieben,
wie ich sie für sinnvoll erachte - die ursprüngliche Idee dazu stammt
vom Betreiber von telemat.de, Jürgen Christ.

Das System kennt einen Datensatz Artikel mit den üblichen Feldern:

- Timestamp
- Art des Artikels (die Art wird hierbei als normales Char
  abgespeichert, ist kein Verweis auf eine zweite Tabelle, um
  hier Joins zu sparen, außerdem ist es bei den wenigen
  Rubriken, deren Rubrikname sich sowieso nicht ändern wird,
  IMHO oversized, das auszulagern)
- Autor (Verweis auf die User-ID der Usertabelle, die PHPLIB-like
  ist)

- Redakteur, der die letzte Änderung machte bzw. es freischaltete
  (Verweis auf User-ID der Usertabelle)
- Timestamp der Redakteurs-Änderung

- published-Flag (0: nicht veröffentlicht, 1: veröffentlicht)
- wiedervorlage-Flag (dazu später mehr)

- Titel des Artikels
- Teaser
- eigentlicher Text
- Zusätzliche Links (Typ: TEXT)
(- bei telemat.de noch Möglichkeit eines Dateiuploads, hier wäre
dann der Filename verzeichnet)
- Hinweistext an die Redaktion
- existiert ein Phorum für diesen Artikel
- Clicks auf diesen Artikel

Zwei Felder bedürfen der weiteren Erklärung: die Wiedervorlage
kann man sich wie ein System aus verschiedenen Körben vorstellen,
in die der Artikel wandert. Das ist dann nötig, wenn der Redakteur
den Beitrag redigiert (d.h. überarbeitet), ihn jedoch noch nicht
freischalten, sondern zurückstellen möchte. In meinem System hat
die Zurückstellung den einfachen Wert "1", damit landet es in der
Auflistung in der Wiedervorlage. Das könnte man dahingehend leicht
erweitern, indem man mehrere Wiedervorlage-"Körbe" einrichtet und/oder
diese "Körbe" jeweils nur bestimmten Redakteuren zugänglich macht,
um mit ein klein wenig mehr Aufwand einen Workflow zu erreichen. Ist
jedoch bei uns (noch) nicht nötig.

In der Benutzeroberfläche erscheint die Wiedervorlage als eine
abgetrennte Liste. Hier könnte man sicherlich an der Usability
noch drehen, doch dazu später mehr.

Der Hinweistext an die Redaktion hat folgende Funktion: damit kann
der Autor eines Artikels der Redaktion noch gewisse Dinge mitteilen,
zum Beispiel "Das Buchcover liegt auf http://www.bla.de/fasel.jpg,
bindet es ein, wenn Ihr mögt" oder ähnliche Hinweise. Existiert solch
ein Hinweis, wird der Text in der Liste unterhalb des Titels mit
roter Farbe und fettgedruckt angezeigt.

Siehe dazu auch den Screenshot auf

   http://www.phpcenter.de/img/redaktion.jpg


Bei jedem Proposal eines Beitrags geht eine automatische E-Mail
an unsere Mailingliste redaktion_(at)_phpcenter.de, die in Kurzfassung
alle eingegebenen Daten anzeigt.

Der Redakteur hat dabei in der Spalte "Aktion" weitere Möglichkeiten:
er kann den Artikel bearbeiten (und dabei auch Publikationsdatum und
-uhrzeit verändern), ihn löschen, ihn in die Wiedervorlage schmeißen
oder ihn publizieren und damit öffentlich zugänglich machen.

Die Wiedervorlage kennt momentan nur die Beschränktheit "In die
Wiedervorlage reinschmeißen" und "Aus der Wiedervorlage in die
Liste nicht veröffentlichter Artikel schieben (published=0,
wiedervorlage=0).

Zu jedem Artikel sollte, wie vorhin erwähnt, zusätzlich die
Möglichkeit bestehen, ein Phorum anzuschließen. Phorum bot sich an,
weil wir es bereits einsetzten. Der größte Nachteil bei Phorum ist
jedoch, dass es keine komfortable API bietet. Ich habe mir dazu
1-2 Stunden Zeit genommen und die index.php-Datei aus dem Admin-Teil
von Phorum kopiert, die Loginüberprüfungen herausgebaut und eigene
Funktionen hinzugefügt:

red_get_folderid()
red_activate_phorum()
red_deactivate_phorum()
red_drop_phorum()
red_add_phorum()
red_new_phorum()


red_new_phorum() macht nichts anderes, als einige globale Variablen,
die normalerweise beim Erzeugen eines neuen Phorums durch die
Eingabeformulare belegt werden, mit definierten Werten zu belegen,
d.h. zum Beispiel die Farbgebung des Phorums, wie die Tabelle in
der Datenbank heißen soll (bei uns ein md5-Hash) etc.pp. Die funktion
ruft dann red_add_phorum() auf, die den ursprünglichen Phorum-Code
zum Erzeugen eines neuen Phorums enthält.

red_get_folderid() benötige ich, um die ID eines Folders mit dem
Namen ABC (z.B. "Artikel", oder "News", oder "Zend") herauszubekommen.

Die Redaktionsoberfläche macht nichts anderes, als beim Veröffentlichen
eines Beitrags über diese selbstgestrickte/gekrüppelte Phorum-API ein
Phorum anzulegen und in der Artikel-Tabelle die ID des Phorums abzulegen,
damit später darauf verlinkt werden kann. Wenn ein Beitrag aus der
Veröffentlichung zurückgenommen wird, wird das Phorum deaktiviert, wird
der Beitrag gelöscht, wird auch das Phorum gelöscht.

Zusätzlich kennt das include-File noch einige Funktionen, um z.B. die
einzelnen Artikel auf der Startseite anzuteasern, die detail.php-Seite
mit dem Inhalt des Artikels zu providen sowie eine Liste aller Artikel
ohne Teaser (nur mit dem Titel) aufzulisten. Eingesetzt wird hierbei
PHPLIBs DB- sowie die Template-Klasse mit Blöcken.

Das System ist nicht perfekt, es fehlen noch folgende Funktionen, die
ich noch einbauen möchte:

- bevor ein Autor seinen Beitrag submitted, muß er ihn vorher
  previewen (so wie bei slashdot, freshmeat et al.)

- ein Locking-Mechanismus, wenn ein Redakteur gerade einen Artikel
  bearbeitet. Ist momentan noch nicht nötig dank social engineering.

- einen Batchmode wie bei telemat.de, d.h. dass der Redakteur nicht
  eine Liste der Artikel sieht, sondern direkt in die Eingabemaske
  des neuesten Artikels kommt und somit alle Artikel wie am Fließband
  abarbeiten kann (lohnt aber nur, wenn sehr viele Artikel auf einmal
  reinkommen)

- eine Rückkommunikation zum Autor, d.h. dass Beiträge declined werden
  können: der Autor erhält beim Einloggen ins PHPCenter die Nachricht,
  dass sein Beitrag aus XYZ Gründen abgelehnt wurde und er ihn direkt
  online nachbearbeiten und wieder zurück zur Redaktion schicken kann

- Kleinigkeiten wie ein netter Kalender (http://www.phpinsider.com/php/code/Date_Calc/,
  danke Sebastian für den Tipp damals), den nur die Redakteure sehen

- generelle Verbesserung der Usability, z.B. durch Einsatz der overlib
  (http://www.bosrup.com/web/overlib/), um eine bessere Benutzbarkeit
  des Redakteursfrontends zu erzeugen und um damit die Produktivität
  zu steigern.

Den Schwierigkeitsgrad, so etwas zu entwickeln, stufe ich als gering
bis mittel ein, da hier im Prinzip nur basics (aus der Datenbank
rauslutschen und in sie reinschmeißen, Template-Geschichte, Login-
Mechanismus via PHPLIB out of the box etc.) vorkommen. Die größere
Schwierigkeit sehe ich bei solchen Dingen in der Benutzbarkeit der
Frontends (für Redakteure und Autoren), die durch Dinge wie overlib
oder eine bessere Darstellung der Listen oder Sachen wie Batchmodus
erhöht werden könnten. Dies läßt sich jedoch nur im Laufe der Zeit
feststellen, da Redakteure letztendlich die Opfer, äh, eigentlichen
Benutzer sind und dementsprechend Vorschläge für das System bringen
können.

PHPNuke hatte ich mir bereits angeschaut, allerdings war der Code
nicht besonders gut dazu geeignet, um sich leicht in unser bereits
vorhandenes System integrieren zu lassen. Insbesondere wollte ich
kein zweites Slashdot aufbauen. Wenn ich mich jetzt über die fehlende
Objektorientierung in PHPNuke beschweren würde, müßte ich zugeben,
dass beitraege.inc.php auch nicht objektorientiert daherkommt, was
ich jedoch für meine Zwecke für vernachlässigbar halte, da die Zeit
nicht da war, sich um ein sauberes OO-Design zu kümmern.

Eine wichtige, abschließende Geschichte möchte ich auch nicht
vergessen: das Sammeln von Community-Points. Communities bieten
in der Regel einen zusätzlichen Anreiz für die Benutzer, damit
diese mitarbeiten und die Community mitgestalten (Online Panels
arbeiten nach dem gleichen Prinzip, hier geht es jedoch darum,
die Benutzer dazu zu bekommen, bei Umfragen mitzumachen), in Form
von Punkten. Bei uns ist es z.B. so, dass jeder, der sich einen
Account einrichtet, 100 Startpunkte bekommt. Für jeden eigenen
Beitrag, der veröffentlicht wurde, werden weitere 20 Punkte
gutgeschrieben. Wird ein Beitrag wieder gelöscht, werden die 20
Punkte abgezogen. Damit Redakteure auch etwas von ihrer Arbeit
haben, bekommen sie für jedes Veröffentlichen eines Beitrags 5
Punkte, für jedes Un-Publish'en eines Beitrags werden ihnen diese
5 Punkte wieder abgezogen. Nach einigen Monaten sollen die aktivsten
Nutzer (mich ausgeschlossen) von Sponsoren mit Preisen belohnt
werden.

Das System soll eine Mischung aus vorhandenen Systemen (konkret
Slashdot und linux-community.de) sein, jedoch die Funktionalität
dessen bieten, was ich bereits einmal für eine Community (telemat.de)
entwickelt hatte.

Der Hintergedanke war, dass ich bisher die Meldungen per Hand
auf der Startseite eintrug, es mir jedoch mit der Zeit (da ich
häufig unterwegs bin) unmöglich wurde, möglichst tagesaktuell
zu bleiben - und damit die Arbeit auch nicht nur an mir haften
bleibt, da sonst das Ziel der Aktualität nicht gewährleistet
werden kann.

Mein nächstes Ziel, in das ich noch einiges an Arbeit stecken
muß, ist die Migrierung vorhandener, statischer Contents (z.B.
aus der Rubrik PHP Inside oder von den Case Studies) in das
Beitragssystem. Danach soll es auch durchsuchbar sein.

Positiver Nebeneffekt des ganzen ist, dass wir endlich auch
einen RDF-/RSS-Newsfeed bieten können, der über

   http://www.phpcenter.de/backend/phpcenter.rss

erreichbar ist. Erzeugt wird er übrigens mit der Klasse von

   http://linux.gelrevision.nl/php/ (phpChannel)

Zusätzlich gibt es eine nette Newsbox auf

   http://www.phpcenter.de/backend/box.php und
   http://www.phpcenter.de/backend/box.php?roundtable=1

die übrigens auch bei yaps.de in die eigene Startseite
integriert werden kann.

Das war's soweit, weitere Vorschläge, wie man solch ein
Beitragssystem verbessern kann, sind gerne Willkommen. Vielleicht
hilft es dem einen oder anderen ja, der etwas Ähnliches auf
die Beine stellen möchte - schwierig ist es wie gesagt nicht
bei einem Coding-Aufwand von 4h. (Konzeptionierung hat sicherlich
noch einiges mehr gekostet)

-- 
PHP Schulungen und                     | International PHP Conference
Schulungsmaterial:                     |             05. - 07.11.2001
                                       |      Astron Hotel, Frankfurt
http://thinkphp.de/                    |  http://www.php-kongress.de/