Do you see what I see?

[Old Boy]

...
Wenn wir aber nun so viel Stoff in die conf.template_default.inc.php schieben (siehe auch container/row- Gruppierungen), wäre es durchaus wünschenswert, diese Datei vorm versehentlichen Überschrieben werden zu schützen ...

Mein Subversion Programm (Cornerstone) kümmert sich Gott sei Dank rührend um solche Probleme und versucht die neue Version mit der vorhandenen (manipulierten) Version abzugleichen.
Habe ich in der Vorversion aber Änderungen vorgenommen, die sich vom Programm nicht "hinfumeln" lassen, so bekomme ich eine Konflikt Meldung.
Die alte, die modifizierte (so weit wie möglich) und die neueste Version bleiben parallel gesichert, sodass mir nix unter den Tisch fallen und ich mich "von Hand" um den Abgleich kümmern kann.

Vielleicht kann das euere Subversion App ja auch ... wenn man die richtige Einstellungen wählt?

[Oliver Georgi]

Noch mal nachgefragt ... nicht am Ende

Nö, braucht nicht

[Oliver Georgi]

Und bitte noch mal testen. Habe es so verändert, dass die benutzerdefinierten Felder nun ausschließlich an das Template gebunden sind.
https://github.com/slackero/phpwcms/com ... b08776effa

Des Weiteren mehr Optionen:
https://github.com/slackero/phpwcms/com ... 7cf299R444

[Old Boy]

Ich habe jetzt noch mal getestet...

conf.template_default.inc.php:

Code: Select all

	'tabs_custom_fields' => array(
		// Enable and customise, to enable additional tab input fields:
		/* */
		'fieldgroup1'  => array(
			'legend'   => 'Field group name 1',
		//  'template' => 'default',        // bind the fieldgroup to a specific template, or default
			'template' => 'TEST-tabs.tmpl', // bind the fieldgroup to a specific template, or default
			'fields'   => array(
				'fieldname1' => array('legend' => 'Schriftfarbe',     'type' => 'str',      'render' => 'html', 'maxlength' => 100), // [TAB_FIELDNAME1]{TAB_FIELDNAME1}[/TAB_FIELDNAME1]
				'fieldname2' => array('legend' => 'Hintergrundfarbe', 'type' => 'str',      'render' => 'html', 'maxlength' => 100), // [TAB_FIELDNAME2]{TAB_FIELDNAME2}[/TAB_FIELDNAME2]
				'fieldname3' => array('legend' => 'Feld 3',           'type' => 'textarea', 'render' => '',     'rows' => 5),        // [TAB_FIELDNAME3]{TAB_FIELDNAME3}[/TAB_FIELDNAME3]
			)
		)
		/* */
	)

TEMPLATE:

Code: Select all

<!--TABS_ENTRY_START//-->
	<dt>{TABTITLE}</dt>
	[TABCONTENT]<dd>
		[TABHEADLINE]<h3>{TABHEADLINE}</h3>[/TABHEADLINE]
		[TABTEXT]<div style="[TAB_FIELDNAME1]color:{TAB_FIELDNAME1};[/TAB_FIELDNAME1][TAB_FIELDNAME2]background:{TAB_FIELDNAME2}; padding:10px 10px 5px;[/TAB_FIELDNAME2]">{TABTEXT}</div>[/TABTEXT]
		[TABLINK]<p class="more"><a href="{TABLINK}"{TARGET}>@@read more@@</a></p>[/TABLINK]
		
		[TAB_FIELDNAME1]<p>Schriftfarbe: {TAB_FIELDNAME1}</p>[/TAB_FIELDNAME1]
		[TAB_FIELDNAME2]<p>Hintergrund : {TAB_FIELDNAME2}</p>[/TAB_FIELDNAME2]
		[TAB_FIELDNAME3]Feld 3 : {TAB_FIELDNAME3}[/TAB_FIELDNAME3]
	</dd>[/TABCONTENT]
<!--TABS_ENTRY_END//-->

Die Custom Feldeinträge wegen einwandfrei übernommen, wenn sie vorhanden sind:
http://bootstrap.pepes-sandbox.de/cp-tabs.html

Wenn ich allerdings bei Feld 3 keinen Ertrag mache, wird nicht wie erwartet kein Eintrag generiert,
sondern die komplette Zeile dargestellt (siehe Register #2):

Code: Select all

[TAB_FIELDNAME3]Feld 3 : {TAB_FIELDNAME3}[/TAB_FIELDNAME3]

Entweder ich übersehe etwas, oder mache etwas falsch... aber was?

[Oliver Georgi]

erledigt, man sollte das Ergebnis auch einer Variablen zuweisen
https://github.com/slackero/phpwcms/com ... 4ddd5ef4b1

[Uwe367]

Hab gerade ne frische Installation der letzten Version von Github auf meinem Localhost installiert und erhalte im CP selbst, wie im Screenshot gezeigt, eine Notice.
Diese wird aber nur ausgegeben wenn KEIN Customfeld angelegt ist. Aktiviere ich die Beispielfelder in conf.template_default.inc.php, wird die Notice nicht ausgegeben.

[Oliver Georgi]

Gefixt, jo so ist das — jetzt Sonntags-Rad-Training.

[Uwe367]

... jetzt Sonntags-Rad-Training.

Have fun

[update]

Selbstdefinierbare BE-Ein/Ausgabefelder =>
Der Traum eines jeden CPs.
Ich sag nur: YEAH! RESPECT! HATS OFF!

[Uwe367]

Selbstdefinierbare BE-Ein/Ausgabefelder =>
Der Traum eines jeden CPs.
Ich sag nur: YEAH! RESPECT! HATS OFF!

Joar.... damit könnte man, wenn ich das richtig sehe, beispielsweise die Data-Attribute eines Sliders aus dem BE steuern ohne das eigentliche Template auch nur antasten zu müßen.
Aber Oliver wollte uns ja noch ein Beispiel zeigen wie er die Customfields "mißbraucht" und darauf bin ich gespannt

[Old Boy]

Ich habe den Biathlon Massenstart genutzt und parallel ein paar weitere Experimente mit den neuen Features gemacht:
http://bootstrap.pepes-sandbox.de/conte ... -preview=1

Mein Ergebnis in einem Wort zusammengefasst: GENIAL!

Nicht nur, dass man die eingetragenen Werte zur Anzeige nutzen kann, nein natürlich auch zur Beeinflussung der Formatierung des ContentParts selber.
Aber es lassen sich auch die Eingabe-Felder nutzen um z.B. Elemente per SHOW_CONTENT einzufügen und garantiert auch eigene CustomBlocks zur Anzeige "einzuschleusen" (muss ich noch testen).

Damit bietet phpwcms bisher nahezu ungeahnte Möglichkeiten bei der Erstellung von Templates. Was bisher nur mit den EFFECT-Schaltern des CP Bilder spezial möglich war, wurde hier nun deutlich erweitert.
Dazu noch die Anzeige einer templateabhängigen Beschreibung des Eingabefeldes im Backend, was dem Editor ein super Hilfe sein wird, braucht er doch nicht mehr grübeln ob und wofür den das Eingabefeld nun eigentlich verwendet wird.
Auch die Möglichkeit, unterschiedliche Effekt bei verschiedenen Templates vom gleichen CP-Typ zu realisieren ist grossartig!

Wenn ich mich auch wiederhole, aber es muss raus: Einfach GENIAL!

Bleibt zu hoffen, das dieses technische Feature auch bei anderen ContentParts realisiert wird... die Vorsilbe [TAB_XXXXX] lässt darauf für die Zukunft hoffen!

Damit könnte man die CMS-Welt aus den Angeln heben! Archimedes würde sich freuen!

[update]

Archimedes würde sich freuen!

Nicht nur der!

[Oliver Georgi]

Jetzt sollte es bug-freier sein: https://github.com/slackero/phpwcms/com ... 3f06aa307f

Hatte doch noch einige Sachen drin, die nicht sauber liefen. Und als Schmankerl zum 4. Advent noch einen Feldtyp "option" integriert. Damit ist das jetzt erst mal eine Basis, die das Gros abdecken dürfte. Weitere Feldtypen (select, int, image, wysiwyg …) können immer noch integriert werden. Dann müsste das alles nur noch in einen eigenen Content Part gegossen werden. Über Konfigurierbarkeit im Backend sinniere ich erst mal nicht, Ziel ist eher, etwas auf Projektebene initial vorzubereiten, sodass für den Kunden am Ende projektspezifisch die passenden Eingabemasken zur Verfügung stehen und mehr nicht.

[update]

Code: Select all

      'fieldgroup1'  => array(
         'legend'   => 'Field group name thisone',
        'template' => 'thisone',        // bind the fieldgroup to a specific template, or default
      // stuff

und dann

Code: Select all

      'fieldgroup2'  => array(
         'legend'   => 'Field group name anotherone',
        'template' => anotherone',        // bind the fieldgroup to a specific template, or default
      // another stuff

Richtig?

[Old Boy]

Irgendwie schwebt mir seit einigen Minuten eine Idee im Kopf herum:

Mit diesem neuen Feature sollte sich doch ggf. auch ein OnePager realisieren lassen ... irgendwie

Ich werde den Massenstart der Biathlon-Damen mal nutzen und darüber nachdenken.
Vielleicht lassen sich die Registerbezeichnungen für das Generieren der Navigation nutzen?

- Die TABS nur für Struktur/Grundaufbau des OnePagers.
- Die eigentlichen Inhalte der einzelnen Sections liegen jeweils in eigenen CustomBlocks...
- Schalter haben wir ja jetzt genug, um "irgendwas" damit zu steuern.

Ja und das Umsortieren der einzelnen Sections ist dann ja durch Verschieben auch leicht realierbar ...
mmmhhh, mal sehen!