[solved]Template: div aus block "left" wird nicht ausgegeben

[santscho]

Der div "leftcontent" hat einen farbigen Hintergrund. Der Div soll nur erscheinen falls auch content dafür vorhanden ist. Das funktioniert mit meinen in Vorlage und Template definierten "custom blocks"
wunderbar. Jedoch im Block "left" nicht.

TEMPLATE
Im Template:

Code: Select all

{LEFT}

Im Block (left):

Code: Select all

<div class="leftcontent rounded">{LEFT}</div>

Im Frontend wird nur der eigentliche Content dargestellt. Der umschliessende DIV container fehlt.

[juergen]

Huhu

Seit wann kann man denn Leerzeichen für Container verwenden ? *staun*

[update]

Du meinst div class="leftcontent rounded"?
bei class kannst Du doch 500 diverse classes aneinanderreihen (mit Leerzeichen getrennt), oder mehr oder weniger... und dann in verschiedenen Kombinationen ansprechn zB... (oder auch alle auf einmal oder nur eine...

[santscho]

Yup. So ist es. Sehr hilfreich wenn alle Container mit Class rounded runde Ecken haben soll.

Keine Idee was der Verusacher meines Problems sein könnte? Egal was sich im Left-Feld befindet, nichts wird im FE gerendert. Verwende neuste DEV von phpwcms.

[update]

Dass das mit den CUSTOM_BLOCKS geht, ist klar - ging das aber schon mal irgendwann mit den Standard-Ersetzern (nie probiert)?

[santscho]

Hmmmm... gute Frage. Muss es wohl... ansonsten ist ja das Feld "links" im Template für die Katz. Ich probier das mal in einem Template einer anderen Website aus... gebe dann Feedback.

[santscho]

....Ne, funktioniert auch bei älteren Installationen nicht. Komisch... da verwendet man phpwcms seit 2004 und dann... 2011 möchte man offensichtlich zum ersten Mal dieses Feature im Standard-Links-Feld anwenden und... geht gar nicht. phpwcms ist immer für eine Überraschung gut. Licht ins Dunkle kann vielleicht OG bringen. Das Zusatzfeld wäre also für nichts zu gebrauchen.

[update]

<-- me too
Dann bleibt wohl nur der Weg über ein CUSTOM_BLOCK_TEIL (erstmal)

[santscho]

Nicht so tragisch, aber je mehr Custom Blocks, desto verwirrender für den "Web-Editor in Future". Werde dann wohl ein DIN-A3 mit einer Layout-Beschreibung und allen Custom-Blocks ausdrucken und laminieren

[update]

Gar nicht so verkehrt! Die Idee hatte ich auch schon mal, dann aber wieder verworfen, weil ich mich dann selber nicht mehr auskannte

[pepe]

Du hast doch selber im Layout angehakt, dass du dein Template NUR aus dem HAUPTbereich der Templateabteilung generieren lassen willst! Was willst du dann in den vorhandenen anderen Feldern, die benötigst du doch nur, für das "alte" Tabellenlayout!

ich habe ausser CONTENT schon länger NUR noch CustomBlocks im EInsatz... dass kannst du dann in der bevorzugten Sprache der Editoren generieren, hast die Reihenfolge in der Backendanzeige im Griff, wenn du dich an die Benennung in ALPABETISCHER Reihenfolge hältst (etwas knobeln muss man allerdings, damit das lückenlos klappt)

Aber selbst CONTENT brauchst du NICHT unbedingt... wenn du das Artikeltemplate entsprechend anpasst...


Wichtigste Grundregel bei der Verwendung von verschachtelten Customblocks:

CBs (Y) können nur dann in andere CBs (X) eingesetzt werden, wenn die Zielbereiche (X) im Layout VOR den einzusetzenden CBs (Y) angeordnet wurden!!!

Die Anzeige in der Artikelinfo erfolgt allerdings ALPHABETISCH !!!

[santscho]

Danke Pepe für die Enthüllung des Geheimnis. Alles klar
Verschachtel wird zum Glück nix. Habe bereits alle Bereiche im Template auf CB^s umgestellt.

[update]

Aber selbst CONTENT brauchst du NICHT unbedingt... wenn du das Artikeltemplate entsprechend anpasst...

Da machen wir gelegentlich noch mal ne Schulung, gelle?

[pepe]

Mensch claus, alter (phpwcms)Sack,

das sagst ausgerechnet DU ???

In CMS-Insiderkreisen nennt man dich den "Einstein von phpwcms" und dann so ein Ansinnen

[flip-flop]

Um Inhalt aus HEADER / LEFT / FOOTER / RIGHT darzustellen in der Templateeinstellung "Haupt" kann dieses Script verwendet werden.
Allerdings wird hier der Inhalt aus den Vorlagefelder HEADER / LEFT / FOOTER / RIGHT immer dargestellt, egal ob ein CP dort etwas hineinschreibt oder nicht.

Hier eine Lösung analog zu den Custom Blocks zu finden ist nicht einfach, da es keine Möglichkeit gibt genau zu dem Zeitpunkt der Abarbeitung einzugreifen.
In /frontend_init/ sind die Inhalte von {HEADER} {LEFT} usw. noch nicht geparst.
In /frontend_render/ jedoch schon fertig gerendert. Zwischen diesen beiden Phasen ist es nicht möglich einzugreifen.

Allerdings würde das mit einer Kombination aus einem frontend_init- und frontend_render-Script funktionieren um die selbe Funktionalität wie die CustomBlöcke zu erreichen.
Ausgehend von dem Script in wiki:
1. frontend_init:
Um den Inhalt der Blöcke wird ein Tag gesetzt, z.B.

Code: Select all

'<!-- %FOOTER% -->'.$block['footertext'].'<!-- %/FOOTER% -->'

2. frontend_render:
Hier werden die TAGs im fertig gerenderten Content gesucht und der Inhalt ausgelesen.

Code: Select all

preg_match('/\<!-- %FOOTER% --\>(.*?)\<!-- %\/FOOTER% --\>/is',$content['all'],$match);

3. nun muss der ausgelesene Inhalt mit dem Inhaltsteil aus der Vorlage FOOTER verglichen werden um festzustellen ob überhaupt neuer Inhalt im TAG {FOOTER} existiert (Hat ein CP dort hineingeschrieben?).

Code: Select all

if (isset($match['1']) AND ((strlen($match['1'])) <= strlen($block['footertext'])) ) {

Ist diese Bedingung erfüllt, wurde nichts hineingeschrieben und der gesamte Teil kann gelöscht werden.

Code: Select all

$content['all'] = preg_replace('/\<!-- %FOOTER% --\>(.*?)\<!-- %\/FOOTER% --\>/is','<!-- nothing -->',$content['all']);

Das wäre im Groben der Ablauf so einer Konstruktion. Unter Punkt 3. sollten beim Längenvergleich noch Dinge beachtet werden wie z.b. die Eigenlänge des TAGs {FOOTER}, da dieser TAG nach dem Rendern nicht mehr vorhanden ist.

Einfache wäre es natürlich wenn Oliver diese Funktionalität entsprechend den Custom Blöcken fest einbauen würde.

Knut