WebsiteBaker Community Forum
WebsiteBaker Support (2.8.x) => 
Hilfe & Support (deutsch) => General Help & Support => Diskussion über WB (closed) => Topic started by: Stefek on October 31, 2010, 01:44:39 AM
-
Hallo,
einige von Euch sind in letzter Zeit auf das OutputFilter Dashboard gestoßen.
(https://forum.WebsiteBaker.org/index.php?action=dlattach;topic=19755.0;attach=7399;image)
https://forum.WebsiteBaker.org/index.php?topic=18857.0
Weil ich im Moment an einigen Plugins arbeite, die ich gerne teilen möchte - eine Veröffentlichung aber auch ein wenig Zeit in Anspruch nimmt - möchte ich gerne vorab "um-mich-fragen", in wie fern es für Euch von Interesse ist.
Schreibt hier, wenn Ihr weitere Fragen habt.
Auch Anmerkungen usw.
Ich krempel gerne meine Ärmel hoch, wenn ich weiß, dass es gewünscht ist.
Wenn Ihr (Antwort 8 ) eine "andere Filter-Methode" angeklickt habt, dann bitte ich Euch, zu beantwoten:
- welche es ist und
- warum ihr sie für besser befindet
Wenn Ihr (Antwort 3) "nicht verstanden" angeklickt habt, dann bitte ich Euch, zu beantwoten ob:
- ihr nicht wußtet, wie man es einsetzt, oder
- nicht wußtet, was das ganze soll und wofür es gut ist, oder
- welcher Teil Euch bei der Verwendung Schwierigkeiten bereitet hat
Danke und Gruß,
Stefek
BTW: Meine Antwort ist natürlich "Nettes Teil, mehr Plugins wären gut."
[gelöscht durch Administrator]
-
So wie ich es bis jetzt kennengelernt, gesehen und empfunden habe ist das Dashboard etwas mit dem sich das Dev-Team mal etwas genauer beschäftigen sollte da es meiner Meinung nach Snippets und Droplets in Zukunft vollständig ersetzen könnte. Der Goal liegt für mich darin das ich einen Filter nicht wie beim Droplet in jede Seite schreiben muss sondern exakt die Seiten, Module setzen kann auf die der Filter wirken soll.
Das Schreiben von Plugins, Filtern erfordert zwar Programmierkenntnis se aber das ist ja bei den Droplets nicht anders.
Meine Antwort ist natürlich "Nettes Teil, mehr Plugins wären gut."
Würde sagen zukunftsgerichtetes Teil, mehr Plugins wären gut. Alleine schon die von Dir gestaltete Oberfläche im Backend ist schon Quantensprung was Backend-Design angeht. ;-)
-
Habe zum ersten mal davon gehört finde es aber extrem interessant. Ich habe bis jetzt meine Outputs einfach per php outputbuffer manuell gefiltert aber das hier scheint mir eine echt super Lösung , vor allem wenn man mehr als einen Filter benötigt.
@Maverik
Die Droplets und Snippits wird es mit Sicherheit nicht ersetzen können , die haben schon ihre jeweilige Existenzberechtigun g, nur werden im Moment die Droplets z.B. für viele Dinge genutzt für die sie nicht wirklich geeignet sind z.b. als Output Filter.
Ich kann mir auch nicht vorstellen das OPF Dashboard geeignet ist globale Funktionen zur Verfügung zu stellen oder Core Funktionen zu ersetzen aber ich geh mir das jetzt erst mal installieren und richtig anschauen.
Auf jeden Fall sehr interessant.
-
aber ich geh mir das jetzt erst mal installieren und richtig anschauen.
Solltest Du machen bevor Du irgendwelche Aussagen über Dinge schreibst die Du nicht kennst.
-
Mal als kleine Vorankündigung, dass wir bereits darüber diskutiert haben, eine Schnittstelle zu schaffen (Hook), mit der Modulecode in den bestehenden WebsiteBakerablauf integriert werden kann, ohne den WB Core zu verändern.
Dietmar
-
@ Luisehahne
Klingt sehr interessant.
@Maverik
Hab ich grade , und ich muss sagen ich bleib dabei. Zumal das übertriebene verwenden von Output Filtern die Seite nicht grade schneller macht.
Im überigen solltest du mal versuchen deine Meinung zu begründen und nicht nutzlos schlechte Laune verbreiten.
Also warum sollte ich im Moment an den Core Dateien rumbasteln, mehrere Pakete installieren, und dann meine gesammte Seite 5 x durch einen Outputfilter laufenlassen, nur um 5 lächerliche 3-6 Zeilen lange Droplets zu ersetzen.
Zumal Droplets den Vorteil haben das ich sie direkt vor Ort mit entsprechenden Parametern versorgen kann und das der Kunde sie im editor findet.
Und möchtest du wirklich so etwas wie Anynews durch durch nen Ausgabefilter ersetzen ?
So, jetzt versuchs mal mit einer nett begründeten Antwort....
-
nett kann maverik nicht :-D
aber bei den aussagen:
Habe zum ersten mal davon gehört finde es aber extrem interessant.
aber ich geh mir das jetzt erst mal installieren und richtig anschauen.
schon vorher mitdiskutieren... ? :wink:
-
Da nach Rückmeldungen gefragt, möchte ich diese hier geben. Da ichmich aber bei der Umfrage nicht wiederfinde, stelle ich meine Gedanken einfach mal hier rein:
Das WICHTIGSTE:
Gekannt hatte ich das Modul bisher nicht. Das was ich dann gelesen finde ich wirklich klasse und bin dabei auch über Dinge gestolpert, die bei mir in den letzten 14 Tagen aktuell waren und mit dem Modul auf einfache Weise hätten gelöst werden können.
Insbesondere auch die Möglichkeit, die Erstezungen Seitenbezogen oder bezogen auf Seitenabschnitte umszusetzen (wenn ich das richtig verstanden habe) finde ich gut.
Das man einfach Programmierkenntnis se für die Filter benötigt sehe ich als unproblematisch. Die Droplets funktionieren genauso. Und den Dode, den ich für meine Lösungen erstellt habe, war letztendlich auch nicht anders.
ALLERDINGS:
Ich wollte das Modul ausprobieren. Zusätzlich zu dem Modul wird ein weiteres Modul PMF benötigt. Dieses Modul benötigt wiederrum Änderungen im Core-Bereich ...
Diese Hürde habe ich dann heute(!) noch nicht genommen, da es erstens Zeit benötigt, ich auf die Schnelle den Sinn und Zweck des zweiten Moduls nicht richtig beurteilen konnte und ich den Aufwand für die mögliche Deinstallation (selbst wenn es sich um eine Testinstallation handelt) heute / dieses WE scheue. (Zumal bei mir auch noch ein paar andere Dinge auf dem Programm stehen, was aber nicht dem Modul anzulasten ist.)
Bei dieser Art der Installation kommen mir folgende Gedanken für eine mögliche Anwendung:
Es ist etwas für Tekkis. Es ist nichts, was man auf die Schnelle mal installiert und verwenden kann. Hier würde ich mir gerade wegen des erhofften und tollen Nutzens eine einfach Plug-An-Play-Lösung wünschen. (Ich weiß, dass das wahrscheinlich nicht möglich ist, aber hier geht es ja um zunächst mal um allgemeine Rückmeldungen, die nicht unbedingt in der weiteren Entwicklung verfolgt werden müssen.)
Aufgrund der komplizierten Installation vermtue ich, dass das Modul trotz des zu erwartenden wirklich hohen Nutzens keine sehr hohe Verbreitung finden würde.
Folgende ergänzende Beobachtung dazu:
Ich habe ein anderes Modul im Einsatz, das ebenfalls Anpassungen im Core benötigt: WYSIWYG-History. Ich glaube, die aktuelle Überarbeitung des Moduls CKEditors erfordert auch Eingriffe in den Core. Dieses Modul hier ebenfalls ... Vermutlich andere ebenfalls.
Wollte man wirklich alle solchen Module parallel fahren frage ich mich, ob da dann nicht irgendwo Inkompatibiltäten auftreten. Klar, testen kann man alles. Aber die Frage ist, ob man den Aufwand bei der Nutzung eines CMS als Admin dann auch wirklich gehen möchte. Der eine wird es tun, der andere nicht. (Und das ist absolut OK und natürlich haben alle dies Module ihre Sinn!)
Kommt hinzu, dass dann nach einem Update die Installiererei und Testerei wieder losgeht.
Übrigens: Der Zeitaufwand zur Lösung der von mir angesprochenen Aufgaben der letzten 14 Tage in Form von Codeabschnitten und die Integration in Template gingen schneller als es mit der Installation der beiden Module hier, dem Ändern des Cores und dem Einarbeiten in die Module und der anschließenden Erstellung/Programmierung des Filters zu erwarten wäre. Für viele Aufgaben wäre die Total-Cost-Of-Admintime über die Nutzung des Moduls wahrscheinlich nicht so gut.
Auch dies ist der Grund, warum ich mir eine Plug-And-Play-Lösung wünschen würde. Die Ankündigung von Luishane ist daher erst mal eine sehr interessante, vereinfacht bei Realisation zwar die Usability, behebt am Ende die Frage nach Inkompatibiltäten nicht.
Ja, ich weiß, dies hat nicht unbedingt etwas direkt und speziell nur mit diesem Modul zu tun. Gehören aber meiner Meinung neben dem Urteil über Nutzen und Leistungsfähigkeit auch dazu.
Zusammenfassend möchte ich daher sagen:
Das Modul hört/liest sich für mich super und wäre wahrscheinlich eine super Lösung für viele Aufgbaen, die es bei der Entwicklung eines Templates zu lösen gilt. (Diese positive Beurteilung und der Wunsch danach soll auf keine Fall untergehen!) Die Hürden der Installation emfpinde ich persönlich allerdings als sehr groß. Ich vermute, dass diese Hürden einer weiten Verbreitung des Moduls im Wege stehen. Dies ist nicht unbedingt ein Ausschluss-Grund, da ja andere Module ähnlich angelegt sind und ihren Zweck haben. Aber gerade wegen des hohen zu erwartenden Nutzens würde ich mir ein solches Modul mit einer einfachen Lösung wünschen. (Ein Grund, so etwas in WSB selbst aufzunehmen? Ja, es wäre für mich etwas, worauf - wie man so schön sagt - viele gewartet hätten ...)
PS: Ja, auch das ist "vorher" mitdiskutiert. Aber zur Usability gehört meiner Meinung auch der Aufwand für die Installation und Pflege im Falle eines Upgrades. Und Anregungen, wie sie hier gegeben sind können, müssen aber nicht aufgegriffen werden und können/sollen von anderer Seite auch aus anders bewertet werden. Entscheiden darüber tut selbstverständlich der Modul-Author, ... und der hat aus meiner Sich immer Recht! (Wer unbedingt anders will, kann ja anders machen, ... wenn er denn kann.)
Generell finde ich es klasse, wenn jemand - wie in diesem Fall - seeeehr viel Arbeit in die Entwicklung einer solchen Idee hineinsteckt. Und egal ob Nutzung oder Nicht-Nutzung: Dafür sage ich danke und klasse!
-
Das Prinzip von Outputfiltern ist hinlänglich bekannt und bei einem System zur Verwaltung von Output Filtern ist es eigentlich ausgeschlossen das es Droplets und Snippets vollständig ersetzen kann. Zumal grade Snippets ja auch völlig andere Dinge abdecken können.
Ausserdem habe ich ja direkt nach dem ich vom Modul erfahren habe erst mal die Doku überflogen das reicht für einen Überblick zu erhalten.
@yetiie
Ich vermute mal das Modul wird wenn es sich bewährt einfach in den Core übernommen. Es soll ja den vorhandenen Fontendfilter ersetzen.
Das Gleiche gilt für wysiwyg history, zumindest hoffe ich das. Wobei ich es noch besser fände wen wysiwyg history einfach ein extra Modul würde das man separat benutzen kann..
Das ist einfach generell das Problem bei experimentellen Modulen und genau deswegen ist die von Luisehahne erwähnte Schnittstelle so toll.
-
@Sgt.Nops.
Naja, das wäre wirklich klasse.
Meine Rückmeludng ist ja auch nicht so sehr als Kritik am Modul oder der Idee selbst zu verstehen. Mehr als: Scheint super, grandios klasse. Genau das wird gebraucht. Und "Quengel": Bitte, wenn möglich: Im Alltag etwas einfacher und auch für Nicht-Tekkis sondern Normal-Admins.
Nachträglich ist mir noch der Gedanke gekommen: Eigentlich würde es für die Filter ja ausreichen, das Droplet-Modul aufzubohren und mit einer Möglichkeit zur Erstellung "genereller Droplets" (=Filter oder =Droplets für jede Seite) zu versehen. Gut, dann kommt noch die optionale Ausführungsbgrenzun g auf einzelne Seiten bzw. Seitenbereiche hinzu sowie die Verwaltung der Einstellungen und der Filter im Backend ...
OK, wie habe ich gesagt:
Wer unbedingt anders will, kann ja anders machen, ... wenn er denn kann.
Ich kann es nicht. Und wenn es jemand macht, dann kostet es jede Menge Arbeit.
Das gilt auch für das was bisher gemacht wurde. Also generell klasse! :-)
Bin auf die weitere Entwicklung jedenfalls sehr gespannt.
-
Ja hallo erstmal und danke für die rege Teilnahme.
Ich antworte hier erstmal auf Eure anregungen.
Gekannt hatte ich das Modul bisher nicht.
Das ist auch der Grund meiner "um-mich-frage" Aktion.
Der Grund für die wenigen Plugins ist, dass wenige Leute auf dieses Modul reagieren.
Es gilt, herauszufinden, was die Nutzungshürden sind, welche Bedenken und Zurückhaltungen.
Daher danke für die ehrlichen Antworten.
Das was ich dann gelesen finde ich wirklich klasse und bin dabei auch über Dinge gestolpert, die bei mir in den letzten 14 Tagen aktuell waren und mit dem Modul auf einfache Weise hätten gelöst werden können.
In der Tat kann man damit Dinge realisieren, die man sonst nur schwer realisieren kann und schon gar nicht, wenn man sich mit PHP schwer tut.
Und auch das ist der Grund, dieses Tool mehr ins Licht zu rücken - je mehr Plugins, desto weniger müßen die "unbedarften Anwender" programmieren müßen und die "Cracks und Tekkis"müßen bestimmte Filter nicht immer mühselig per Hand wiederholen.
Insbesondere auch die Möglichkeit, die Erstezungen Seitenbezogen oder bezogen auf Seitenabschnitte umszusetzen (wenn ich das richtig verstanden habe) finde ich gut.
Ja, das gehört sicherlich zu den Highlights der Funktionalität.
Man kann auswählen, ob ein bestimmter Filter nur auf ein Bestimmtes Modul (z.B. Guestbook) anwendung finden soll, oder nur auf eine bestimmte Seite.
Das spart Ressourcen (ein Performencevorteil gegenüber "festgecoden" Filtern z.B. im Template oder dem Filtern via Droplets).
Das man einfach Programmierkenntnis se für die Filter benötigt sehe ich als unproblematisch.
Ja, auch für Snippets oder Droplets muss man bestimmtes, grundlegendes (mindestens) PHP Verständnis mitbringen, um eigene Funktionen zu schreiben.
Ich wollte das Modul ausprobieren. Zusätzlich zu dem Modul wird ein weiteres Modul PMF benötigt.
Diese Hürde habe ich dann heute(!) noch nicht genommen
Es ist nichts, was man auf die Schnelle mal installiert und verwenden kann.
Na ja, die "Hürde" der Installation dauert etwa 5 Minuten.
PMF installieren, OpF installieren und 2 Corefiles ändern. Also ich persönlich kann dem eine positive Kosten-Nutzen-Rechnung abgewinnen :P
... ich mir eine Plug-And-Play-Lösung wünschen würde.
... zur Usability gehört meiner Meinung auch der Aufwand für die Installation und Pflege im Falle eines Upgrades.
Ja, mit Sicherheit ist das richtig. Beim Upgrade muss man das wieder anpassen, damit es weiterhin funktioniert.
Daher ist auch Luisehahnes "Verkündung", dass es bald ein Hook geben soll, auf das man aufsetzen kann, sehr vielversprechend. Das würde die Corefiles Aänderungen überflüßig machen und den Plug'N'Play effekt steigern.
Was aber sehr vorteilhaft ist, wenn wir bei Plug'N'Play sind:
Die einzelnen OpF Plugins kann man sehr gut Plug'N'Play anwenden.
Sogar die Inline-Plugins (das sind die, die man nicht hochlädt, sondern direkt ins Tool reinschreibt) kann man exportieren und auf einer anderen Installation wieder importieren.
Vergleich mit Droplets:
Das OutputFilter Dashboard ersetzt nicht Droplets, das wäre zwar möglich, aber nicht nötig - zumal die Verwendung von Droplets bereits sehr populär ist.
Ich vermute mal das Modul wird wenn es sich bewährt einfach in den Core übernommen. Es soll ja den vorhandenen Fontendfilter ersetzen.
Ich finde, dass das Modul im Core nichts verloren hat.
Ein Hook, an den man das Modul anstöpseln kann würde vollkommen ausreichen.
Ich würde auch einen WYSIWYG Editor - so rudimentär er auch sein würde, nie im Core gut finden.
Selbst im Paketumfang (das WB was man runterlädt) brauche ich keinen Editor, weil ich den Editor meiner Wahl installieren will.
Gruß,
Stefek
P.S.
Nochmal zum PMF - das "zweite Modul" und wofür es gut ist.
PMF ist einfach eine Funktionssammlung, die der Entwickler Thorn (und andere Entwickler, wie ich z.B.) gelegentlich verwenden, während sie Ihre Module schreiben. Diese Funktionen machen bestimmte Arbeit leichter, und die Module schlanker. Der Nutzen einer Funktions- (oder Klassen-) Sammlung (auch Library, Bibliothek oder einfach nur Lib genannt) liegt darin, dass der Entwickler bestimmte Sachen nicht immer und immer wieder in seine Module einbaut, was die Modulpflege (vor allem aber auch die Entwicklung) der einzelnen Module sehr vereinfacht und schlank fällt.
Es gibt sehr viele Libs für WB. Um einen (vielleicht etwas hinkenden) Vergleich zu geben, auch jQuery hat eine "Lib" und dann noch die große "UI Lib", die für bestimmte jQuery "Module" vorausgesetzt wird. Das erspart den entwicklern dieser "Module" aber sehr viel Arbeit und spiegelt die Philosophie und den praktischen Nutzen einer Lib sehr genau wider.
-
ich hatte es ja auch getestet auf einer installation und hinterher für gut befunden.
heute wußte ich nicht mehr warum es dann nicht auf meiner persönlichen "must have"-liste landete. nach yetiis eintrag fiel es mir auch wieder ein. das prozedere war es wohl.
-
das prozedere war es wohl.
Hallo Frank.
Und damit meinst Du... die Installation und die Änderung der CoreFiles?
Gruß,
Stefek
-
es ist ja nicht nur die installation. wenn man etwas wieder loswerden will, dann weiß man später nicht mehr was noch dazu gehörte, welches modul man noch installieren musste, welche core-änderungen getätigt wurden.
das führt alles weg von "einfach ist einfach gut".
bei absolut notwendigen dingen wie wysiwyg_with_histor y lasse ich mich breitschlagen.
-
Ich verstehe.
Ja gut, dann wird die Notwendigkeit nach einem Filtersystem bei Dir nicht so hoch sein.
(Warte ab, bis ich mit dem nächsten Filter komme, der könnte Dir gefallen.)
"Einfach ist einfach gut" stimmt auch für OpF. Denn einfacher kann man das kaum gestalten.
Bei Dieser Aussage muss man auch "einfach" auf das Einsatzgebiet anpassen.
Es gibt z.B. keine einfach zu bedienenden Flugzeuge für jemanden, der nie geflogen ist. Aber unter den Piloten werden da bestimmt Vorlieben existieren.
Und was die Deinstallation angeht: einfach deinstallieren. Oder auf dem Server lassen, wenn man die paar Kilobytes übrig hat (auch das Corereplacement muss man nicht rückgängig machen).
Gruß,
Stefek
-
Warte ab, bis ich mit dem nächsten Filter komme, der könnte Dir gefallen
bin gespannt.
Flugzeuge sind zu kompliziert.
Wenn "Aldi" ein Notebook anbietet und auf der Verpackung steht: Display gibts bei "Lidl" und Akku bei "Netto".
Insgesamt gute Technik und zusammen günstiger als woanders.
Würdest du kaufen? Vielleicht ja, aber würdest du noch mehr solche "Packs" in anderen Bereichen haben wollen?
Wird einfach irgendwann zu unübersichtlich und bremst die Laune. :wink:
-
Wenn "Aldi" ein Notebook anbietet und auf der Verpackung steht: Display gibts bei "Lidl" und Akku bei "Netto".
Der Vergleich hinkt ein wenig. :roll:
Kann ja sein, dass Du mal ein anderes PMF Modul installierst, dann würdest Du doch nicht auch wollen, dass auch in diesem Modul wieder die ganze Lib ist.
Oder wenn Du auf ein JS Framework verzichten müßtest und jedes JS eine aufgeblähte Bombe wäre? Nicht so gut.
Übrigens, passend zum Thema "ausgelagerte Libs":
https://forum.WebsiteBaker.org/index.php?topic=19543.0
Mehr möchte ich nicht zu diesem Thema sagen (der Sinn von Libs und Frameworks ist bei der Entwicklung schon hinreichend dargelegt worden - wenn es schlecht wäre, würde es kein ernstzunehmender Entwickler machen, stimmt's?).
Warte ab, bis ich mit dem nächsten Filter komme, der könnte Dir gefallen
bin gespannt.
Ja, bin bald fertig.
Ich mache nur noch eine Maske, in der man Einstellungen vornehmen kann (der Admin dann).
Dieser Filter macht dann (unter anderem) aus "schlechtem HTML" auf Wunsch XHTML strict.
Auch das WORD "html" wird ausgefiltert, diese h#ßlichen tuenichtsgut Tags.
Da wird sich mein Freund Hans Toolbox freuen (hoffentlich).
Das ist auch der ganze Zweck dieses Threads, herauszufinden, ob mehr Plugin gewünscht/gebraucht werden.
Denn ich habe hier einige, die ich sehr nützlich finde.
Gruß,
Stefek
-
wenn es schlecht wäre, würde es kein ernstzunehmender Entwickler machen, stimmt's?
Na, da bin ich anderer Meinung, ich hab schon so unendlich viel Programm Müll gesehen alleine wenn ich schon an Winzigweich denke .... die allermeisten rennen einfach der neusten Mode nach egal obs Sinn macht oder nicht .
Oder denke mal an WEB 2.0, 90% Ausschuss 10% richtig geile nützliche Sachen.
Wenn der Hook den Luisehahne erwähnt hat zustandekommt dann ist das natürlich der bessere Weg, ansonsten sollte man den Core zumindest so modifizieren das man den Filter problemlos einbauen kann und in die Liste der Core Module mit aufnehmen.
Alles in die Core Funktionaität zu integrieren ist natürlich unsinnig.
So am Rande bemerkt mein Rechner ist von Atelco, meine externe Platte von Aldi und meine Monitore von der Resterampe nebenan. Und alles mindestens 5 Jahre alt ;-)
Zum Thema wiederherrstellen:
} else {
#require(PAGE_CONTENT); ############### Repalced for OPF Dashboard
######################### here comes the Replacement
// Searchresults! But also some special pages, e.g. guestbook (add entry), news (add comment) uses this
ob_start(); // fetch original content
require(PAGE_CONTENT);
$content = ob_get_contents();
ob_end_clean();
// Apply Filters
if(function_exists('opf_apply_filters')) {
$content = opf_controller('special', $content);
}
// Print Content
echo $content;
##################### End of Replacement
}
Wo ist das Problem mit dem wiederherstellen ein paar Kommentarzeilen wirken manchmal Wunder ...
-
Wenn der Hook den Luisehahne erwähnt hat zustandekommt dann ist das natürlich der bessere Weg, ansonsten sollte man den Core zumindest so modifizieren das man den Filter problemlos einbauen kann und in die Liste der Core Module mit aufnehmen.
Ich bin auch schon gespannt.
Gruß,
Stefek
-
Wo ist das Problem mit dem wiederherstellen ein paar Kommentarzeilen wirken manchmal Wunder ...
und in welchen dateien die verschiedenen module änderungen brauchten, klebt mit zettel am monitor. :wink:
mir ging es nur um das allgemeine: willst du das eine musst du noch dieses und jenes zusätzlich...
deine alte gurke von pc entkräftet nicht das laptop-beispiel. :-D
-
Wie gesagt, man muss nichts rückgängig machen.
... aber warum nicht auch ein wenig off-topic.
-
Wie gesagt, man muss nichts rückgängig machen.
weil wir programm-reste nach deinstallationen bei microsoft gewöhnt sind? :-)
off-topic sollte es natürlich nicht werden.
-
Ich hatte Deine Frage beantwortet, deswegen ist weiteres darauf "rumhacken" off-topic (oder was noch anderes).
Bitte behalte die Intention des Threads im Bewußtsein.
Danke.
-
ohne "rumhacken" kann dbs nicht :-D
-
Hier kommt ein Beispiel eines Inline Filters.
Das sind Filter, die nicht als ZIP hochgeladen werden, sondern die man nach Bedarf
"per Hand" eingeben kann.
ZWECK dieses Filters:
Diese Dinger hier...
<a class="section_anchor" id="wb_18" name="wb_18"></a>
...aus dem Output herauszufiltern.
Wofür das gut ist?
Na, zur Demonstration.
Und vielleicht will jemand mal eine Seite anlegen, die komplett blank ist. :-)
<?php
//get section prefix from database
$anchor_pref = sprintf("SELECT `value` FROM `%s` WHERE `name` = 'sec_anchor'", TABLE_PREFIX."settings");
$anchor_pref = $GLOBALS['database']->get_one($anchor_pref);
//create search pattern
$regex = sprintf('<a class="section_anchor" id="%s\d*" name="%s\d*"></a>',$anchor_pref,$anchor_pref);
$extracts = opf_cut_extract($content, $regex, 0, 'i');
if($extracts) {
foreach($extracts as $key => $str) {
$extracts[$key] = str_replace($extracts[$key],'', $str);
}
opf_glue_extract($content, $extracts);
return(TRUE);
} else { // opf_cut_extract() failed. $content may be damaged, so return FALSE
return(FALSE);
}
?>
Das schöne am OpF Dashboard ist auch, dass man die Inline Filter exportieren kann.
Dann kann man sie als Plugin durchs Netz weiterreichen.
Also hänge ich diesen hier an, dann müßt Ihr nicht abtippen. WB soll ja möglichst einfach bleiben ;-)
Gruß,
Stefek
[gelöscht durch Administrator]
-
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
-
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.
-
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
-
Nee bisher eigentlich eher das Gegenteil :evil:
-
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?
-
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.
-
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.
-
Ja, und hier gibt es ihn:
OpF_htmLawed:
https://forum.WebsiteBaker.org/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.
-
I used Chrome Translation - so i didn't get all of this in english.
Where do I put the code (files)? output_filter folder? in a file?
thanks so much. The anchors are messing with my js.
kevin
-
Hello,
what kind of help do you need?
I don't understand your issue?
Regards,
Stefek
-
Hello,
what kind of help do you need?
I don't understand your issue?
Regards,
Stefek
Thanks Stefek, i just turned off the anchors under settings.
kevin