Feature Request für kommende Versionen von WB CMS

[Stefek]

Hallo.

Ich schreib das mal auf Deutsch.
Ist denn doch einfacher.

Folgendes Problem:

- will man auf einer speziellen Seite zusätzliches JS oder CSS einfügen, geht es nur über Umwege. Dabei ist die Lösung für dieses Problem nicht schwer umzusetzen.

Dazu wäre ein weiteres Feld in den Einstellungen von nöten, was sich so ähnlich verhält wie die Kopfzeile, die unter Optionen > Kopfzeile zu finden ist.

Auf diese Weise könnte man in den Head was reinschreiben, was man braucht.

Ja, ja. Die Templates sind nicht auf so etwas ausgerichtet. Kein Problem. Man könnte dieses Feature, dieses Extrafeld über erweiterte Optionen ein/ausschaltbar machen. Und wer es braucht, bindet die nötige Variable in sein Template rein.

Ja, ja. Wir haben doch schon Frontend_Mod_Files. Ja, aber in den heutigen Zeiten der übergroßen JS Frameworks und Libraries ist es leider nicht ausreichend.

Gruß,
Stefek

[doc]

Hi Stefek,

genaus aus diesem Grund sollen in WB 2.8 auch die Droplets von Ruud und John Einzug halten.

Dann kann man ein Droplet schreiben, welches abhängig von bestimmten Ids oder was auch immer Javascript oder CSS Dateien ins Template einfügt. Denke die Optionen die mit Droplets möglich werden sind sehr vielfältig.

Gruss Christian

[Stefek]

Vielen Dank.

Da lass ich mich mal überraschen.

Droplets sind ohnehin ein gutes Ding.

Wird man auch den Outputfilter von Thorn einfach (ohne Corereplacement) installieren können?
Auf dieses Tool will und kann ich nicht mehr verzichten.

Gruß,
Stefek

[thorn]

Hallo,

EDIT
ich hatte mich schon mal mit John über das Thema droplets vs. frontentfilter unterhalten. Es ging darum, das er einen großen Teil der Funktionalität des frontendfilters auch in droplets übernehmen wollte.
Wir sind dann im Grunde übereingekommen, das ich die Entwicklung des frontentfilters einstelle, sobald er auch noch die restlichen Funktionen übernimmt (im wesentlichen die Möglichkeit beliebig JS und CSS im Head zu platzieren).

Es macht einfach keinen Sinn zwei solcher Module nebeneinander zu pflegen. -- Und da die Akzeptanz und Präsenz der doplets offensichtlich höher ist, macht das so herum auch Sinn...

... übereingekommen, das es zu aufwendig wäre _alle_ Fähigkeiten des Frontendfilters in droplets zu übernehmen.

Es wird also auch weiterhin den Frontendfilter geben...

thorn.

[Stefek]

Ach so.
Verstehe.

Gut dann. Muss man schauen, wie es sich dann in der Praxis verhält. Bin gespannt.

Dennoch könnte man wahrscheinlich den FE Filter installieren? Wie gehabt. Waren ja schon ein paar Goodies dabei, dieich gern verwende.

Gruß,
Stefek

[thorn]

Hallo,

hab mich nochmal mit John darüber unterhalten:
Der Frontendfilter bietet ein paar Funktionen (Unterscheidung von page_id, section_id, module; beliebiges platzieren von JS und CSS im head oder body; Unterscheidung zwischen section-Filtern und page-Filtern), die droplets "bauart-bedingt" nicht unterstützen kann.

Ich werde also den Frontendfilter auch weiterhin pflegen.
Zur Zeit kann er aber nicht mit 2.8 (SVN) eingesetzt werden, dafür werden dann ein paar Anpassungen notwendig sein.

thorn.

[mr-fan]

Ich werde also den Frontendfilter auch weiterhin pflegen.
Zur Zeit kann er aber nicht mit 2.8 (SVN) eingesetzt werden, dafür werden dann ein paar Anpassungen notwendig sein.....Der Frontendfilter bietet ein paar Funktionen......die droplets "bauart-bedingt" nicht unterstützen kann

das sind gute nachrichten - nutze den FEF zwar nicht aktiv, aber hab schon ein paar sachen damit probiert und finde ihn echt eine super ergänzung für website baker!

ein high-end-frontend-filter für "zusätzliche funktion/en" & eine droplet-engine für "mini-module" ergibt durchaus sinn!

gruß aus dem freistaat

martin

[Stefek]

ein high-end-frontend-filter für "zusätzliche funktion/en" & eine droplet-engine für "mini-module" ergibt durchaus sinn!

Sehe ich auch so.

Ich werde also den Frontendfilter auch weiterhin pflegen.
Zur Zeit kann er aber nicht mit 2.8 (SVN) eingesetzt werden, dafür werden dann ein paar Anpassungen notwendig sein.

Verstehe.
Ja gut, dann...

Gruß,
Stefek

[Stefek]

BTW.

Ich finde auch, dass der WB Addon Editor im "Lieferumfang" dabei sein sollte.
Ist er denn schon soweit eingeplant?

Gruß,
Stefek

[doc]

Hi,

bisher ist es nicht geplant, den Addon File Editor in die Standardinstallatio n von WB 2.8 zu packen.

Gruss Christian

[Luisehahne]

Hallo,

möchte jetzt mal auch an der Diskussion teilnehmen und mich zu den einzelnen Punkten äussern:

1) Frontendfilter mod-files
ich habe bereits einige Module entsprechend angepasst. ich liebe frontend.css und frontend.js
Problem sind allerdings doppelte selectoren im css oder doppelte funktionen im js, da muss man als coder aufpassen
z.B.  Tiltviewer und Simpleviewer oder was sonst noch swobject.js benötigt, ist dann doppelt und dreifach
Da wäre eine Abfrage ob im Head beretis vorhanden evtl. sinnvoll, damit Nichtcoder keine Probleme bekommen

2) Ich bin auch unbedingt der Meinung, dass der WB Addon Editor im "Lieferumfang" dabei sein sollte.
ist für mich übersichtlicher zum zippen von Modulen und Templates

3) Wann wird der Modulcheck wieder funktionieren? Den von AMASP finde ich nicht so prickelnd. Beim WB eigenen hatte man eine bessere Übersicht, was upgedated werden kann und was neu ist.

4) Droplets nutze ich auch, gibt aber auch andere Möglichkeiten dies umzusetzen. Erstelle zur Zeit eine template.function.p hp zum einbinden ins template, mit der man auch so nette Dinge wie bei Droplets machen kann. Habe da aus vergangener Zeit jede Menge nette Funktionen die ich jetzt an WB anpassen werde.

So das wars im Moment, werde diesen Thread weiterhin verfolgen und hoffe, dass ich mithelfen kann WB zu erhalten und zu verbessern.

Gruss
Dietmar

[erpe0812]

Habe mal einen ganz einfachen Wunsch für die kommenden Versionen :

Alle Optionen im  Backend unter Admintools/Javascriptadmin als Default-Werte enabled.

Aber vielleicht hat da ja schon jemand dran gedacht.

Gibt es eigentlich schon einen Termin für den RC?

Gruss

erpe

[vsharma]

Dann kann man ein Droplet schreiben, welches abhängig von bestimmten Ids oder was auch immer Javascript oder CSS Dateien ins Template einfügt. Denke die Optionen die mit Droplets möglich werden sind sehr vielfältig.

[dussy]

Was ich mir wünschen würde wäre ein Dropdown-Feld mit den verfügbaren Droplets, das im FCK-Editor eingebaut ist. So könnte man die Droplets leichter einfügen. Ein Button mit Popupfenster wäre in diesem Fall vielleicht auch nicht schlecht.
Irgendwas, das einem das Einfügen von Droplets ins WYSIWYG-Modul erleichtert.

Dussy

[Stefek]

Fände ich auch eine gute Idee.
Müßte machbar sein - allerdings müsste man beide Module anpassen.

Ich würde nicht gerne alle Droplets drin haben, die in denAdmin-Tools aktiv sind.
So müsste man einen zusatz Check machen können, ob die in die jeweiligen Drops in die Auswahlliste aufgenommen werden sollen oder nicht.

Gruß,
Stefek

[WebBird]

Um einfach mal wieder bei anderen zu "klauen"... (Allerdings dann wirklich erst für die nicht mehr ganz so nahe Zukunft.)

In PmWiki können Module - dort "Recipes" genannt, Addons laufen da unter "Cookbook" - CSS, JavaScript und ähnliches Geraffel in globalen Arrays "registrieren". Diese werden dann an den entsprechenden Platzhaltern im Template eingetragen.

Ich ärgere mich z. B. andauernd, daß ich keine CSS-Links für die Ausgabe im Header registrieren kann, sondern immer das komplette CSS im Body ausgeben muß. Das ist bei umfangreicherem CSS ziemlich kontraproduktiv.

Die register... Funktionen des WB suchen ja nur fest verdrahtete CSS oder JS Dateien. Wenn ich aber zusätzlich zur Laufzeit welche hinzufügen möchte (etwa bei Modulen, die mit "Themes" arbeiten), kann ich nur noch den Inhalt im Body ausgeben. Zumindest bei CSS. Das ist Murks. Die Funktionen sind im Ansatz gut gedacht, aber leider nicht bis zu Ende durchgedacht, wenn ich das mal so sagen darf. Ist nicht bös gemeint.

[thorn]

Hallo,

Ich ärgere mich z. B. andauernd, daß ich keine CSS-Links für die Ausgabe im Header registrieren kann, sondern immer das komplette CSS im Body ausgeben muß. Das ist bei umfangreicherem CSS ziemlich kontraproduktiv.

Mit Hilfe des Frontendfilters ließe sich das leicht realisieren (er bietet entsprechende Funktionen, und läßt sich auch ohne eine eigentliche Frontend-Funktion nutzen) ... nur wäre das ziemlicher overhead die ganze Seite durch den output-buffer zu jagen, nur um ein paar Skripte oder CSS in den Header zu packen.

Ich denke, was dir vorschwebt ist eine Funktion, die bei der Installation von Modulen (install.php/upgrade.php/uninstall.php) aufgerufen wird, und an die man Dateinamen übergibt die beim Seitenaufbau in den Head-Bereich importiert werden sollen (abhängig vom Modul).
register_file()
unregister_file()
oder so.

Das wäre echt sinnvoll.

Wenn man das vernünftig aufbaut, kann man darüber auch gleich sicherstellen, daß bestimmte Skripte nicht mehrfach geladen werden (jquery, growfields, ...)


thorn.

[WebBird]

Ich finde auch, daß der Frontendfilter eher was für den Notfall ist. Ich finde es ziemlich unsinnig, erst eine Seite generieren zu lassen, nur um sie dann hinterher erst von einem Filter total verbiegen zu lassen.

Ansonsten hast Du mich ganz richtig verstanden. In PmWiki "registriert" man einfach einen Key in einem Array und belegt den mit den Inhalten, die man braucht. Eine entsprechende Funktion, die gleich prüft, ob etwas schon enthalten ist, wäre natürlich wesentlich sinnvoller. (Sie kann z. B. auf sinnvolle Inhalte, Existenz von Dateien, mehrfach registrierte Inhalte usw. prüfen.)

Also zum Beispiel:

(Im Modul irgendwo...)

Code: [Select]

register_css( WB_URL.....'/blafasel.css' );

Natürlich gäbe es da noch andere Möglichkeiten, etwa register_header_link() für alle Arten von <link href> Markups.

Wie gesagt, der Ansatz ist ja da, nur leider mit fest verdrahteten Dateien. (backend.css und frontend.css)

[doc]

Hi,

stimme thorn zu. Der Outputfilter würde das ganze zwar einfach erlauben, ist aber nicht gerade die performanteste aller Lösungen.

Sinnvoll wäre auch, wenn man in den Modulen auswählen könnte, ob CSS oder JS Dateien für alle Seiten, oder nur bei bestimmten Seiten geladen werden sollen (z.B. nur für das Modul oder nur für Seiten mit bestimmter page_id). Eine sinnvolle Erweiterung wäre eine neue Funktion, welche es erlaubt, beliebigen Text/Code in den Head zu schreiben (z.B. zur Registrierung von PHP Variablen in JS wie z.B. WB_URL). Also sowas wie registerHead('xxxxx'); Das würde Template- oder Modulautoren wesentlich mehr Freiheiten geben.

Recht brauchbare Ansätze finden sich auch in anderen Open Source Projekten. Da hilft oft mal ein Blick über den Tellerrand hinaus, wie WebBird ja schon angemerkt hat.

Christian

[WebBird]

Sinnvoll wäre auch, wenn man in den Modulen auswählen könnte, ob CSS oder JS Dateien für alle Seiten, oder nur bei bestimmten Seiten geladen werden sollen.

Naja, wenn die Module ihre CSS- und sonstigen "Zubehör"-Dateien zur Laufzeit registrieren, werden sie ja automatisch nur auf den Seiten geladen, wo auch das Modul eingehängt ist. Das Registrieren sollte nicht statisch passieren, sondern wirklich zur Laufzeit. (Etwa view.php)

[Stefek]

Hallo Thorn,
Dein editierter Beitrag "Antowrt#3" hört sich gut an.

Doc und alle Coder.
Wie Ihr alle wisst, bin ich nicht so der Coder.
Habe mich in letzter Zeit auch umgeschaut, was es sonst so gibt (nicht CMS aber Webshops) und ich muss sagen, dass WebsiteBaker schon eine feine und elegante Sache ist.
Ideen die ich habe, sind meist Ideen von denen ich nicht weiß, wie schwer sie umzusetzen sind.

Schon oft habe ich es angedeutet, was ich gerne an zusätzlichen Feldern hätte, und zwar in den Einstellungen der Seiten (aka Seitenoptionen).
Die anderen will ich hier nicht weiter beschreiben sondern beim Thema bleiben.
Da habe ich nämlich eine Idee, die vielleicht gut, aber vielleicht auch zu einfach ist.

Ein Admin Tool, über das man bestimmte Skripte, CSS usw verlinkt und ihnen eine ID oder Namen gibt (Bezeichnung, whatever).
In den Einstellungen der einzelnen Seiten kann man dann über eine Mehrfachauswahl (oder checkbox) die Skripte auswählen, die man auf dieser bestimmten Seite mit laufen lassen will.

Neben Description und Keywords (ich schweife etwas ab jetzt), wäre noch ein zusätzliches Feld nett (Textarea, besser gesagt), wo man für jede Seite etwas reinschreiben kann (wo auch immer man den Platzhalter im Template platziert).
Praktisch wäre es für viele Zwecke. Zusätzlichen Footer, zusätzliches Was-auch-immer im <head/> Bereich.
Auch das könnte man dann locker verwenden, um die Pfade zu den js/css zu setzen.
Ist nicht für jeden User, ich weiß.
Aber die "Strickverein User" stellen sich solche Probleme auch selten.
Vielleicht wäre es auch gut, die Möglichkeit zu geben, mehrere von diesen dingern für die Seitenoptionen freizuschalten und sie dann mit [[boxID=1]], [[boxID=2]] oder was auch immer im Template aufzurufen.

Nur Ideen.
 

[doc]

Hi,

Postits benötigt z.B. eine Refresh Funktion auf allen Seiten, damit das ganze Sinn macht. Derzeit muss man das Template "händisch" bearbeiten. Geht zwar, schöner wäre es aber, wenn ich aus Post Its heraus sagen könnte lade die Postits CSS und JS Dateien für alle Seiten (werden ja eh gecacht). Wäre z.B. auch für Anynews wünschenswert. Für Code Snippets funktioniert CSS und JS Unterstützung derzeit gar nicht.

Wollte nur sagen, bevor man was "eigenes" strikt, sollte man ruhig mal schauen, wie das andere CMS Systeme so machen. Gutes Beispiel sind z.B. die WB-Droplets (von Ruud und pcwacht), die meines Wissens nach von ModX inspiriert wurden - zumindest gibt es dort Chunks mit der gleichen Funktionalität  

Gruss Christian

[WebBird]

Stefek, ich will nicht sagen, daß die Idee schlecht ist, aber sie überläßt natürlich die Entscheidung dem Admin. Ich finde, der sollte sowas nicht entscheiden müssen, jedenfalls nicht "im Alltag". Als Zusatzoption okay, aber eigentlich sollte solche Logik in den Modulen und im Core stecken, nicht im Kopf des Benutzers.

[thorn]

Hallo,

würde ich auch so sagen.
Der Modul-Programmierer weiß am besten, welche Skripte/CSS das Modul braucht.
Ich weiß nicht warum der Admin/User da dran was ändern sollte (er kann ja die frontend.css bearbeiten).

Das in der Laufzeit der Module (view.php) einbinden zu lassen wird aber nicht funktionieren:
Wenn die view.php der Module abgearbeitet werden, ist der Head schon lange fertig. Man müßte wieder mit output-buffern anfangen, um den Head nach der Abarbeitung der Module nochmal zu bearbeiten ...

Ich denke, man braucht eine Funktion, die bei der Erzeugung des Headers in der Datenbank nachsieht welche Module auf der Seite zum Einsatz kommen, dann die registrierten Dateien ermittelt, und diese in den Head mit einträgt.
Wobei ich mir das selbe auch fürs Backend wünschen würde. - Eigentlich da noch mehr als im Frontend...

Und um doppeltes Laden der gleichen Skripte (ggf auch noch in unterschiedlichen Versionen) zu vermeiden, sollte man da auch etwas vorsehen. Z.B. durch vereinheitlichten Kurznamen, und Version

register_frontendfi le(WB_URL.'/modules/test/js/script.js', 'jquery-growfield', '2.0');
... und anderes Modul ...
register_frontendfi le(WB_URL.'/modules/test/js/j-growfield_1.3_min.js', 'jquery-growfield', '1.3');


thorn.

[Stefek]

Hallo.
Ja, ihr wisst da sicher besser bescheid.

Stefek, ich will nicht sagen, daß die Idee schlecht ist, aber sie überläßt natürlich die Entscheidung dem Admin. Ich finde, der sollte sowas nicht entscheiden müssen, jedenfalls nicht "im Alltag". Als Zusatzoption okay, aber eigentlich sollte solche Logik in den Modulen und im Core stecken, nicht im Kopf des Benutzers.

Ja - nehm ich gerne als Zusatzoption.
Bitte behaltet das im Hinterkopf.

Gruß,
Stefek