WebsiteBaker Support (2.8.x) > Diskussion über WB (closed)

Feature Request für kommende Versionen von WB CMS

<< < (5/8) > >>

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". :wink: Als Zusatzoption okay, aber eigentlich sollte solche Logik in den Modulen und im Core stecken, nicht im Kopf des Benutzers. :-D

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.



--- Quote from: WebBird on May 04, 2009, 07:27:45 PM ---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". :wink: Als Zusatzoption okay, aber eigentlich sollte solche Logik in den Modulen und im Core stecken, nicht im Kopf des Benutzers. :-D

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

Gruß,
Stefek

Navigation

[0] Message Index

[#] Next page

[*] Previous page