[Umfrage] OpF Dashboard

[Stefek]

Hallo,

ich wollte mich bei allen, die bisher die "Umfrage" geklickt haben bedanken.

Würde mich freuen, wenn die, die es noch nicht gemacht haben, es noch nachholen könnten.


Bitte schreibt auch ganz ehrlich rein, was Euch an diesem Modul am meisten "stört".

Die bislang am häufigsten angegebene "Zurückhaltungsbegründung" lautete:
Man muss da was am Core frickeln.
(Gut, das kann sich mit den zukünftigen Versionen von WB ändern).

Der zweite häufig angegebe Grund ist:
Man muss PHP beherrschen.
Nun, nein. Nich wirklich. Ähnlich wie bei anderen Modulen und Snippets ist es von Vorteil, PHP zu können, um sich auch eigene Filter zu programmieren oder Anpassungen an Filtern vornehmen zu können.
Aber es ist nicht zwingend erforderlich.

Für jede weitere Frage stehe ich gerne zur Verfügung.

Es wurde oft die Antwort "Was heißt es, den Output zu "filtern" und wofür ist es gut?"
Das ist eine gute und berechtigte Frage.

Eine einfache "Erklärung" sieht folgender Maßen aus:
Output ist das, was am Client (im Browser) ankommt.
Im Falle von WebsiteBaker (wie auch anderer PHP basierter Systeme) wird der Output zusammen gestellt aus PHP Code, der dann die Datenbank nach Inhalten fragt, das ganze dann auf dem Server zusammenfasst und (dann den Output im HTML Quellcode für gewöhnlich) an den Client sendet.

Die OutputFilter (wie auch anderer Filter auf PHP Basis), greifen kurz davor ein, um weitere Veränderung vorzunehmen, BEVOR das HTML den Client/Browser erreicht.

Der praktische Nutzen hängt vom jeweiligen Filter ab.

So kann es Filter geben, die nach bestimmten HTML Fragmenten suchen und sie ersetzen, etwas zwischen setzen oder löschen.
Es kann aber auch Filter geben, die zum Beispiel das Datum formatieren und in der gewünschten Sprache und HTML Hervorhebung ausgeben.

Das Prinzip ist eigentlich immer das gleiche und der Nutzen gegenüber Javascrit basierter HTML Manipulation ist einmal die Geschwindigkein und andererseits die Verfügbarkeit von JS (obwohl JS heutzutage ziemlich stark vertreten ist).
Darüberhinaus kann man mit JS nicht wirklich Daten VOR dem eigentlichen Senden an den Browser manipulieren, was eigentlich der wichtigste Vorteil von Filterung dieser Art ist.
(Das soll nicht heißen, dass Javascript schlecht ist - ich selbst bin z.B. ein jQuery und Scriptaculous Liebhaber,läßt es doch lauter lustiges Zeugs mit dem Inhalt der Seiten zu).

Outputfilter sind dort gut, wo Javascript zu spät zum Zuge kommt (wie gesagt, manches läßt sich nicht mit JS umsetzen) oder die Manipulation mit JS zu zu hohen Performance Einbußen führen würde.

Für weitere Fragen stehe ich offen.

Gruß,
Stefek

[FrankH]

Was hier noch fehlt ist eine Erklärung dafür, was der Vorteil eines zusätzlichen Filters gegenüber der eigentlich naheliegenden Methode ist, den output gleich mit dem php-Code zu filtern, der ihn erzeugt.

[Stefek]

Hallo Frank,
meinst Du die Tatsache, dass es keinen Sinn macht, die Filterung jedem einzelnen Modul (Snippet, Template) zu überlassen und der Vorteil darin liegt, eine zentrale Stelle dafür vorzusehen?

Gruß,
Stefek

[FrankH]

Nee bisher eigentlich eher das Gegenteil 

[testör]

Man sollte auf jeden Fall die bisherigen "Filter" aus WB rauswerfen und eine zentrale Schnittstelle bereitstellen - man kann ja dafür die OpF verwenden, thorn hat die jetztige WB 2.7er Core-Filterschnittstelle ja auch schon entwickelt.
Dann könnte man grundsätzlich aus dem Core z.B. die E-Mailfilter usw. ausbauen und hätte dann neben Droplets ein weiteres, nettes Produkt.
Sehr sehr gut ist auf jeden Fall die Registrierung von Modulfiltern, gar keine Frage.
Problem beim Modul ist nur wie so oft: Die wenigsten Leute trauen sich da ran, und die meisten sagen nach wie vor "Droplets ist ja schon igitt, und das ist ja noch schlimmer, weil ich da rumbasteln muss".
Allerdings kann man dadurch nette Sachen realisieren.
Wäre denn angedacht / möglich (sicher ist es möglich, nur halt auch für "Angsthasen" durchführbar), auch externe Scripts wie http://htmlpurifier.org/ einzubinden oder ist das dann doppelt gemoppelt?

[thorn]

Wäre denn angedacht / möglich (sicher ist es möglich, nur halt auch für "Angsthasen" durchführbar), auch externe Scripts wie http://htmlpurifier.org/ einzubinden oder ist das dann doppelt gemoppelt?

htmlpurifier ist ja eigentlich vorrangig ein Eingabe-Filter, und kein Ausgabe-Filter. Damit ist das eher am anderen Ende angesiedelt - nämlich bei der Prüfung von Anwender-Eingaben (z.B. aus $_POST).
Der einzige sinnvolle Einsatz von htmlpurifier als opf-Filter wäre z.B. um HTML in der Ausgabe strict-konform zu machen. Aber dafür gibt es bereits eine bessere (weil kleiner) Lösung: htmlawed als opf-Filter.


thorn.

[testör]

Ok, danke für die Erklärung. Natürlich ist es momentan nicht möglich, $_POST u.ä. Eingaben abzufiltern, und OpF wäre dafür sicherlich auch nicht gedacht und (geht ja nicht anders) auch nicht in der Lage. HTMLawed sieht aber gut aus.

[Stefek]

Ja, und hier gibt es ihn:

OpF_htmLawed:
http://www.websitebaker2.org/forum/index.php/topic,19774.0.html

htmLawed wird übrigens sehr häufig verwendet, hier als Beispiel
Drupal: http://www.drupalcode.com/api/file/htmLawed/htmLawed.module/contrib-6.x-1.x/source
DaDaBik: http://www.dadabik.org/index.php?function=show_home&subfunction=show_message_details&ID_message=54
Typo3: http://typo3.org/extensions/repository/view/htmlawed_tidy/current/
WordPress: http://wordpress.org/support/topic/tip-using-the-htmlawed-html-filterpurifier-in-wordpress
(soll reichen)

Gruß,
Stefek

BTW:

Nee bisher eigentlich eher das Gegenteil

Ja, natürlich, Frank, kannst Du das auch an jedes Modul ranhängen. Oder ins Template.
Das OpF Dashboard ermöglicht jedoch die Filter selektiv zu verwenden (z.B. nur bei bestimmten Modulen, nur auf bestimmten Seiten etc.).
Verwendest Du mehrere Filter an verschiedenen Stellen, kannst Du schnell den Überblick verlieren (oder wenn Du nicht unbedingt, so können es andere).
Eine Zentrale, die all das verwaltet und auch noch ein User Interface bietet, wo die Filter hochgeladen, exportiert oder "auf die Schnelle" geschrieben werden können ist sehr nützlich.