Author Topic: <body id="var"> (Read 15469 times)

evaki · « **on:** December 25, 2018, 04:03:40 PM »

Für's neue Jahr...

Im Zusammenhang mit SASS, das ich bisher selbst noch nie genutzt habe, worum ich mich aber nun wg. eines Anwenders kümmern soll, tauchten nicht nur dynamisches CSS auf, sondern nun auch entsprechende Elemente, hier nun body.

Die Möglichkeit "body id" vielfältig nutzen zu können, hängt auch vom jeweils verwendeten CMS ab.
Dynamische body ID's lassen sich auch in WB nutzen, m.W. aber nicht ganz so dynamisch wie es möglich wäre -wenn ich nichts übersehen habe.

Im vorliegenden Falle gehts darum ausgewählte Seiten gestalterisch (per CSS) einer bestimmten Gruppe zuzuordnen. Das kann also ab (von, bis) einer bestimmten Unterebene (SM2), in Abhängigkeit von Seiten (pageID), oder z.B. von Verzeichnissen (z.B. /media/xy...) geschehen. Sogar globalBlocks sind inbegriffen. Sowas ist dann mehr oder minder im Template fest verdrahtet, evtl. dann auch in wechselnden sekundären Templates. (Ausgenommen sind hierbei die Anteile aus Modulen oder aus WYSIWYG)

Per bodyID's ließe sich derartiges dynamisch gestalten.
Will man html nicht anrühren, können es auch entsprechende Platzhalter im Template sein, die genauso für andere andere Funktionen herhalten können. Gut, somit ist man beim Thema CMS-Scriptsprachen.

Gibts für sowas ne OpenSource Schriptsprache (muß ja nicht t_y_p_o3script "ausarten), die sich in WB implementieren ließe?

MfG. Evaki

Gast · « **Reply #1 on:** December 26, 2018, 01:41:26 PM »

Möglichkeiten gäbe es schon genug, allerdings fliegen die nicht automatisch in das jeweils aktive Frontend-Template und selbst, wenn das so wäre, findet sich ganz schnell jemand, dem diese Lösung nicht gefällt, weil er dafür bereits eigene Sachen integriert hat.
Einfachste und zugleich sicherste Möglichkeit für ein <body id="page"> wäre die Nutzung der Page-ID mit einem Bezeichner XY, z.B.

Code: [Select]

<body id="page<?php echo PAGE_ID; ?>">
Analog gilt das dann auch für einzelne Blöcke, z.b,

Code: [Select]

<div id="main<?php echo PAGE_ID; ?>" class="main-content">
oder über die Section-ID

Code: [Select]

<div id="main<?php echo SECTION_ID; ?>" class="main-content">
all das setzt aber voraus, das der Benutzer die Werkzeuge zum Erstellen von LESS und SASS bedienen kann und über das benötigte Wissen verfügt. Am Ende habe ich auch nur eine komplierte CSS-Datei, die es einzubinden gilt

evaki · « **Reply #2 on:** December 26, 2018, 02:20:34 PM »

Jo, so is dat.
Wobei ich dummerweise versäumt habe, ausdrücklich auf eine frei konfigurierbare Gruppenzuordnung als Wunsch zu verweisen, also die schon jetzt genannten Möglichkeiten bzw. Zuweisungen wahrzunehmen, aber diese dann auch einer wählbaren Gruppe zuordnen zu können, resp. in einer Gruppe die Möglichkeiten zusammenzufassen, und damit den Interpreter seine Arbeit machen zu lassen. Natürlich entsteht hierdurch nur eine entsprechende CSS bzw. mehrere. Wer sich für sowas entscheidet, stößt halt bei der Gestaltung und Bedienung an Grenzen, die er überwinden möchte.
Wer sich anno-dazumal mit ZEN-Garden beschäftigt hat, kennt halt die strikte Trennung von CSS und HTML-Struktur.

Apropos SASS. In der letzten Woche stieß ich bei einem Anwender auf einen Stolperstein:

Code: [Select]

imgresponsive.css
.responsive100 {
  width: 100%;
  height: auto;
}
.responsive90 {
  width: 90%;
  height: auto;
}
.responsive75 {
  width: 75%;
  height: auto;
}
usw.

Das läßt sich eleganter lösen, als den zigsten Zettel mit Optionen dazuzubacken

Da die meisten meiner Anwender beim selben Hoster sind, sind Python und Ruby schon im "zweitkleinsten" Paket drin. Schön, wenn man auch mal mit Erfahrungen der eigenen Anwendern bereichert wird.

Die Benutzer selbst kommen mit SASS bei sowas übrigens nicht in Berührung. Das ist die Sache des Templateerstellers, in Absprache mit dem Admin, so daß die Schreiber nur die Möglichkeiten offeriert bekommen (Optionen bei den einzubindenden Objekten).
MfG. Evaki

Gast · « **Reply #3 on:** December 26, 2018, 03:49:03 PM »

warum sagst du nicht in einfachen, klaren Worten, was du möchtest?

Und wenn du noch ein praktisches Beispiel dazu packst, versteht es der Rest auch

Es ist wohl so, das LESS/SASS nur von einer ganz, ganz kleinen Gruppe von WB-Nutzern eingesetzt wird, i.d.R. von Leute, die damit auch berufsmäßig arbeiten. Wenn nicht gerade über ein Freies Template kopiert, dann kaum vom allgemeinen User.
Für mich gesprochen, sehe ich da kein Problem, beide Methoden mit dem aktuellen WB zu verwenden. Was mir der Core nicht liefert, z.b. die angesprochene Gruppenzuordnung (sofern ich dich da richtig verstehe), kann ich mir auch selbst bauen, in dem ich z.b. diverse Page-ID's in einem Array zusammenfasse und darüber eine Klasse oder ID setze.
Ich könnte auch den Parent abfragen und so alle Childs gruppieren oder, oder, oder.....
Und ob ich nachher eine eher private Klasse für mich und mein SASS draus mache oder eine, die ich in z.b. Bootstrap oder W3CSS etc verwenden kann, bleibt meiner Fantasie überlassen.

Sicherlich wäre es einfacher, wenn ich eine Gruppe XY per Seiteneinstellung wählen könnte, allerdings kenn ich auf Anhieb auch kein CMS, das solch Gruppierung ermöglicht. WB hat seit einigen Jahren die bislang unbedienten Datenbank-Felder custom1 und custom2 in der pages-Tabelle, die man über ein kleines AdminTool bedienen könnte. AdminTool hieße aber: Seiteneinstellungen verlassen und in eine Übersicht wechseln. Dank der neuen helpers-Funktionen ist solch Übersicht mit Einstellmöglichkeit en schnell gemacht. Das Auslesen geht dann aber wieder nur individuell.
Wie gesagt, ich persönlich gehe von einem sehr kleinen Anwenderkreis aus, ein, zwei Prozent vielleicht und da stellt sich die Frage, ob ich das CMS für die Allgemeinheit aufblähen muß?
Interessanter wäre für mich da eher die Frage, ob es nicht grundsätzlich möglich sein könnte, mich mittels Addon z.b. in die Page-Settings einzuklinken. Da sehe ich z.b. in Wordpress teils recht gute Lösungen. Ein Plugin wie solch Gruppierungsmöglich keit hat ein Basis-Settings (z.b. das Anlegen von Gruppen unter AdminTools) und würde sich dann an die vorhandenen Pagesettings anhängen, ein nächstes Addon dann wieder darunter. Solch Vorgehen wäre technisch kein Problem und mit der anstehenden Umstellung auf Twig muß eh alles einmal durch gearbeitet werden, aber es bedarf eben eines grundlegenden Konzepts und einiger Regeln.

Aber auch dann, wenn all die Fantasie-Möglichkeiten vorhanden sind, braucht es am Ende jemanden, der das vernünftig nutzt. Wenn ich z.b. in WP sehe, das ich für manche CSS-Klassen 50 Einträge habe, weil jedes Addon da ein paar Klassen hinzufügt, bin ich eher dagegen und ziehe die Einzelprogrammierun g vor, bei der ich auslese, was ich brauche.

evaki · « **Reply #4 on:** December 26, 2018, 03:56:31 PM »

Ja, manchmal mache ich es "Euch" nicht einfach.
Ist aber auch schwierig, wenn man etwas aus dem Anwenderkreis mitgeteilt bekommt, mit dem man ja bisher keinen Kontakt, und auch keine Praxis hatte, also selbst (doof wie Schwarzbrot) mit was Neuem bzw Unbekanntem konfrontiert wird.
>>"Sicherlich wäre es einfacher, wenn ich eine Gruppe XY per Seiteneinstellung wählen könnte"
>>"mich mittels Addon z.b. in die Page-Settings einzuklinken."
Gut zu wissen, daß ich mich nicht komplett auf Abwegen befand.
Schauen wir mal, was sich im neuen Jahr noch so an Ideen aus dem Sandkasten schaufeln läßt.
MfG. Evaki
p.s. Einen schönen Restfeiertag wünsch ich noch

Gast · « **Reply #5 on:** December 26, 2018, 04:34:56 PM »

was heißt "euch"?

ich bin kleiner, popliger Anwender und trage auch nur ein paar Ideen aufs "Papier". Entscheiden müssen das andere.
Mein Vorteil ist halt, das ich mir mein Kram selbst erstellen kann und nicht darauf angewiesen bin, ob und wann WB mir ein Werkzeug in die Hand gibt

evaki · « **Reply #6 on:** December 30, 2018, 02:36:44 PM »

Hast Du 'ne Ahnung vom Zusammenspiel WB>wysiwyg>Bildeigenschaften Styles bzw. Formatvorlagenklass en und 'ner eingesetzten Präprozessorsprache, oder 'nen Tip, wo man sich das evtl. anschauen kann? Also wie, wann und wo was übergeben und abgearbeitet wird. So jaaaaaanz pragmatisch und so...

So etwas "altbackenes" wie'n Flußdiagramm, dem ich auf Hardwarebene mal ganz nahe stand, habe ich bei OS-CMS bisher noch nicht entdeckt (aber auch noch nicht gezielt gesucht). Außer mal vor zig Jahren bei unserem ehemaligen Admin, der eines für's "UR"-WB (2.5/2.6 oder so) besaß. Ob das von ihm war -hab' keine Ahnung.

Entwicklerkommentar ist auch gern' gesehen, wenns die Zeit zuläßt.

MfG. Evaki

evaki · « **Reply #7 on:** December 30, 2018, 03:50:24 PM »

Noch vergessen.
SCSS wird konkret genutzt bzw. soll genutzt werden, da
1.) auch ein Compiler in PHP existiert, und
2.) nicht wenige Projekte mit SCSS arbeiten, wie Frameworks, w3layouts, Mobirise...

Wo ich auch noch nicht gelandet bin, ist die Verwendung in/mit Modulen.
Hier ist es aber nur die eigene Neugierde, und nicht die Anfrage des Anwenders, die mich im Moment beim Thema hält.
MfG. Evaki

Gast · « **Reply #8 on:** December 30, 2018, 07:05:02 PM »

Grundsätzlich und überall so, unabhängig vom System, das dahinter steckt: man schickt einen Code XY an den Browser und dieser setzt der Reihe nach um, was er bekommen hat.
In WB und auch den meisten Systemen, die ich so kenne, wird zuerst das Basis-Gerüst eingelesen, also das aktive Template. Diese index.php bindet dann, abhängig vom Benutzer, das CSS usw ein, das in dieser index.php definiert wurde. Steht das Grundgerüst, werden die auf dieser Seite aktiven Sectionen eingelesen. Für jede dieser Sectionen werden dann(wenn vorhanden) die frontend.css bzw frontend_user.css eingebunden. Alles zusammen wird in einen Buffer gepackt und durchläuft den OutputFilter. Hier werden, wenn definiert, Inhalte entsprechend geändert, z.b. das Aufbereiten von WbLinks, das Ersetzen einer Mailadresse, das Ändern von absoluten in relative Links (wenn eingestellt) usw. Ist der OutputFilter fertig, wird alles zusammen an den Browser gesendet und in HTML dargestellt.

Ob du jetzt im Template oder in den betreffenden frontend.css per @import scss/sass-Dateien einbindest oder hier bereits eine fertig compilierte css-Datei verwendest, ist nicht von Belang, auch nicht, ob das alles in einer Datei liegt oder zig mal verschachtelt ist. Am Ende hast du eine CSS-Klasse und (wenn alles gut geht

) eine passende Definitionen in einer scss- oder css-Datei.
Das Problem ist wohl eher, wie man zu einem solch passenden, funktionierenden Code gelangt. Hier braucht es gute Editoren und Validatoren und natürlich entsprechende Kenntnisse.

evaki · « **Reply #9 on:** December 30, 2018, 07:21:52 PM »

Wenn ich die Hierarchie richtig deute, wäre ein "Einhaken" auf der Ebene Outputfilter sinnvoll, da dann der Compiler die entsprechenden SCSS-Variablen "bearbeiten" könnte, womit die Ausgabe von Media Queries, CSS und z.B. Variablen in Elementen (wie z.B. im Topic body id) fertiggestellt würde ? ? ?

MfG. Evaki

evaki · « **Reply #10 on:** December 31, 2018, 10:53:43 AM »

Stichwort einhaken.
Wie ist da die Hierarchie (Queue/Buffer)? Gibts da irgendwo nen Hook? War ja mal im Gespräch, wenn ich recht erinnere.
Mal verkürzt gefragt, das ganze Template in 'nen Buffer, den abholen, bearbeiten und wieder raus damit, geht?
MfG. Evaki

Gast · « **Reply #11 on:** December 31, 2018, 12:22:10 PM »

Einer von uns beiden versteht hier wohl nicht richtig

Beispiel body id
ein paar Methoden: entweder (wie in meiner ersten Antwort schon beschrieben) durch Ausgabe einer fixen PHP-Definition, z.b die Page-ID oder das Ergebnis solcher Aufbereitung (z.b. der Return einer Switch-Anweisung) oder der Replace einer PHP-Funktion (Zeile holen, Content einfügen, Zeile wieder zurück schreiben)
Das alles funktionier heute schon, ohne Hook, ohne Outputfilter - und SCSS läuft das genauso automatisch

evaki · « **Reply #12 on:** December 31, 2018, 01:21:14 PM »

Naja, es waren letztlich zwei Fragen und somit auch Möglichkeiten.
Du hast sie ja beantwortet

Wie das nun praktisch (in WB umgesetzt) aussieht, wird mir mein Anwender wohl irgendwann mal zeigen müssen. An den örtlichen Servern kanns nicht scheitern, außer wir zerhacken uns gerade mal wieder das lokale Netz

Dank und Gruß, Evaki.

News

Support WebsiteBaker

Author Topic: <body id="var"> (Read 15469 times)

evaki

<body id="var">

Gast

Re: <body id="var">

evaki

Re: <body id="var">

Gast

Re: <body id="var">

evaki

Re: <body id="var">

Gast

Re: <body id="var">

evaki

Re: <body id="var">

evaki

Re: <body id="var">

Gast

Re: <body id="var">

evaki

Re: <body id="var">

evaki

Re: <body id="var">

Gast

Re: <body id="var">

evaki

Re: <body id="var">