Haupttemplate nicht in DB speichern sondern in Datei

[update]

Frage nach mehreren Varianten

Danke, jawoll!

[Old Boy]

Nur maintext hat am Ende Relevanz. Die anderen Felder aggregieren nur und brauchen nicht gefüllt zu werden — abgesehen von errortext, das einen Fallback darstellt.

Grundsätzlich natürlich "JA" ...

Aber ich würde jetzt natürlich gerne auch meine Customblock-Einträge "injizieren"!
OK, da nur der Versuch klug macht..
habe ich also fix mal folgende Erweiterung für meinen CustomBlock "ALPHA" versucht:

Code: Select all

...
if (!empty($block['customblock_ALPHA'])) { dumpVar($block['customblock_ALPHA']); }
$block['customblock_ALPHA']  = file_get_contents(PHPWCMS_TEMPLATE.'/inc_script/template/phpwcms-ALPHA.tmpl');
...

Ohne dass ich in der Vorlage irgend etwas in die CustomBlock Bereiche schreibe (und nur dann!) wird der HTML-Code aus der Datei gezogen und eingefügt!
BINGO!
Das funktioniert ja wunderbar und ich bin dem lange erhofften TemplateTransporter ein winziges Stückchen näher gerückt

Fehlt mir nur eine ERLEICHTERUNG bei dem kompletten Experiment!
Auf die eben beschriebene Weise muss ich für jeden CustomBlock eine eigene Datei ansprechen, das geht natürlich, ist aber mehr als suboptimal

Meine GROSSE FRAGE:

Wie müsste ich meine Initialisierungsdatei abändern, wenn ich nun alle meine CustumBlocks samt Haupttemplate etc. in nur einer Datei verwalten wollte.
Irgendwie wären dann die einzelnen benannten Blöcke mit START und END zu markieren und anschliessend selektiv auszulesen und an die passende Stelle im Haupttemplate zu "beamen" ...

Meine grobe IDEE:

Dateiinhalt von .../template/inc_script/template/phpwcms-vorlage_001.tmpl

<!--HTMLHEAD_START-->
... Hier kommt der HTML-Code rein ...
<!--HTMLHEAD_END-->

<!--MAINTEXT_START-->
... Hier kommt der HTML-Code rein ...
<!--MAINTEXT_END-->

<!--CUSTOMBLOCK_MEIN_ERSTER_START-->
... Hier kommt der HTML-Code rein ...
<!--CUSTOMBLOCK_MEIN_ERSTER_END-->

<!--CUSTOMBLOCK_SCHNEEWITTCHEN_START-->
... Hier kommt der HTML-Code rein ...
<!--CUSTOMBLOCK_SCHNEEWITTCHEN_END-->

... usw. mit weiteren CustomBlocks ...

<!--ERRORTEXT_START-->
... Hier kommt der HTML-Code rein ...
<!--ERRORTEXT_END-->

Also das wäre dann doch - zumindest für die Entwicklungsphase - eine tolle Sache...
und für den schnellen Austausch von Layouts mit Dritten natürlich ganz besonders



EPILOG:
Freunde, wenn ich vor 10 Jahren gewusst hätte, was ich heute alles NICHT WEISS ...
ich hätte mich garantiert in die php-Programmierung gestürzt, 100%ig

[update]

Jetzt wird's spannend

[Old Boy]

Du sagst es!!!

Ich halte auch schon seit ca. 1 Stunde den Atem an

[Uwe367]

Thema Templatetransporter....
Die erste Frage wäre.....Wie sollte der denn in der Theorie aussehen bzw. was sollte der können?

Ist theoretisch keine grpße Sache. Das Haupttemplate wird in der DB in einer Tabelle gespeichert. Also muß der "Transporter" in der DB die entsprechende Tabelle prüfen ob diese leer ist oder bereits einen Inhalt hat. Ist sie leer, könnte das Script den Inhalt aus einer, z.B. Textdatei, auslesen, in einer Variablen speichern und dann in die DB schreiben und somit würde das ganze dann auch unter Vorlage --> Haupt sichtbar werden denn beim Aufruf im BE wird dieser Inhalt aus der DB gezogen. Ist bereits Inhalt in der Tabelle vorhanden so müßte dieser entfernt werden und der neue Inhalt eingeschrieben werden.
Kann ich mir das so in etwa vorstellen oder habt ihr andere Vorstellungen?

[Oliver Georgi]

Template muss anders funktionieren und bezüglich der Anlage nicht mehr über Datenbank. Prinzip wie z.B. bei Wordpress. Jedes Template bekommt einen eigenen Ordner. Parallel dazu gibt es ein Default Template, das immer dann herangezogen wird, wenn das Custom keine Entsprechung aufweist, wie jetzt auch schon.

Code: Select all

templates/lib/vendor
templates/default/
templates/custom1/
…

[Uwe367]

Danke Oliver.
Mit WP kenne ich mich nicht aus da ich noch nie damit gearbeitet habe, aber deiner Beschreibung nach dürfte dies das gleiche Prinzip sein nach dem Modified Shop arbeitet und mit dem habe ich schon oft gearbeitet. Dieser beherbergt ein zentrales Templateverzeichnis wo alle Templates in eigenen Verzeichnissen abgelegt werden und im BE kann man mittels Dropdown das Template auswählen welches man nutzen möchte. Denke das ist so die grobe Richtung...

[update]

bezüglich der Anlage nicht mehr über Datenbank

Es wird dann - analog zu den Modulen - der Templateordner geprüft und

im BE kann man mittels Dropdown das Template auswählen

Dass das dann nicht mehr in der DB hinterlegt ist, könnte für das unkomplizierte Verteilen von Templates echt ein Ding sein.
Es würde dann zusätzlich jeweils ein css-, image-, script- und sonstwas-Vereichnis geben, um so ein Templatepäckchen einfach in den Templateordner zu werfen und es dann als Auswahl zur Verfügung zu haben.
Alles andere wäre dann wieder Styling wie gehabt...

[Uwe367]

Es würde dann zusätzlich jeweils ein css-, image-, script- und sonstwas-Vereichnis geben, um so ein Templatepäckchen einfach in den Templateordner zu werfen und es dann als Auswahl zur Verfügung zu haben.
Alles andere wäre dann wieder Styling wie gehabt...

Zieh dir mal aus Jux ein Installationspaket von Modified. So ähnlich wie du beschrieben hast ist das aufgebaut und ja, man schmeißt das gesamte Templatepäckchen mit einer eigenen Bezeichnung (z.B.mein_template) in den zentralen Ordner und schon kann man es auswählen und damit arbeiten. Wäre sicher auch für die Weitergabe von Templates sehr vorteilhaft.. eine .zip Datei und fertig

[Old Boy]

Ich glaube, jeder von uns weiss in etwa, wie es "prinzipiell gehen könnte"!

Es würde aber wirklich NUR Sinn machen, wenn so ein System in phpwcms (ggf. als nachladbares MODUL?) verankert wäre
und
der Aufbau so eines Template-Ordners samt Unterordner/Dateinamen etc. für "(nahezu) alle Zukunft" vorgegeben wäre.

Wobei wir wohl wieder bei der hilfreichen "Unterstützung" von Oliver G. und seiner knappen Zeit wären.
Denn wenn von ihm nicht zumindest sichergestellt ist, dass so eine Ladestruktur und Routine längerfristig beibehalten wird, macht's wohl keinen Sinn.

Die spontane kurze Antwort von Oliver zur Vorgehensweise... lässt mich allerdings insgeheim hoffen

Ich würde fast meinen Kopf wetten, das so eine Erweiterung des von uns so geliebten phpwcms einen mächtigen Aufschwung bringen würde.
Denn das grösste Problem jedes Anfängers eines CMS ist - neben des Installationsvorgangs - doch:
Wie kriege ich meine neues System jetzt einigermassen HÜBSCH und VORZEIGBAR???

So ein "TEMPLATE_TRANSPORTER" wäre garantiert ein mächtiger Schritt in diese Richtung!
Selbst ohne CUSTOM_TEMPLATE wäre ja schon eine "ON-BOARD" default-Variante mit mehr als der jetzigen "Hello World" Optik, eine Verbesserung um 99%.

Ich bin weiter überzeugt, dass so ein System unserem guten Oliver keinen latenten Kunden wegnehmen würde, sondern eher der Wunsch nach "Mehr personalisierten Optionen" grösser würde, wenn mehr Installationen online wären.

Vielleicht, Oliver, wäre ja auch für dich, so ein System durchaus vorteilhaft, wenn es für Kundenaufträge darum geht, aus deiner "Bauelemente-Kiste" schneller eine Neuinstallation zusammenzustellen und anschliessend "nur noch den Feinschliff" vorzunehmen zu müssen?

Ich erwarte jetzt und hier keine Antwort, aber vielleicht findest du ja doch mal etwas Zeit, darüber nachzudenken...
Und wenn er dann käme, der "TEMPLATE_TRANSPORTER"?
Nicht nur ich würde mich riesig darüber freuen ... und gerne Templates incl. CustomBlocks etc. beisteuern!

[update]

Ich bin sicher, dass es Oliver auch jetzt schon nicht an Aufträgen mangelt
Dennoch gebe ich Dir ansonsten Recht.

[Old Boy]

Ich bin sicher, dass es Oliver auch jetzt schon nicht an Aufträgen mangelt
Dennoch gebe ich Dir ansonsten Recht.

Ich bin was die Olivers "Auftragssituation" angeht, ja auch deiner Meinung/Vermutung,
aber dieser Aspekt könnte der einzige sein, der dagegen spräche

[update]

Ganz so trivial ist das dann aber doch nicht: Wie wäre dann die Verwaltung von ContentPart-Templates zu gestalten? Vielleicht heißen die dann MySpecialTemplate_...tmpl und werden in der Ausgabe beim Einsatz von "MySpecialTemplate" gefiltert? Ja, so könnte das gehen...

[Uwe367]

Ich denke daß die Ladestruktur dabei das kleinste Problem ist, denn was wird denn im Template unter Hauptvorlage geladen? Die jquery Bibliokthek. Ok.. wenn man mit Customblocks arbeiten möchte wird das ganze schon wieder etwas schwieriger aber ne eierlegende Wollmilchsau gibts nunmal nicht und ob man will oder nicht.. Individualität erfordert numal "Handarbeit".
Als zentrales Templateverzeichnis könnte man doch schon /template nehmen und das was transportiert wird, darauf abstimmen. Sollte sich die Struktur mal ändern, so wäre das ruckzuck mit ein paar anderen Pfadangaben angepaßt.
Wenn wir das Grundgerüst eines Transporters mal ans laufen bekämen, sei es nun als Modul oder, in der Alphaphase, erstmal auch nur als autarkes Script, so wäre schon ein großer Schritt gemacht denn wenns mal klappt und wir das OG übergeben wäre er sicherlich nicht abgeneigt das gerne aus den weiter oben genannten Gründen und auch aus Gründen der Bedienfreundlichkeit in den Core oder als Modul fest zu integrieren und somit würde auch die Attraktivität erheblich steigen.

Über den Transport von CP Templates würde ich mir momentan noch keine Gedanken machen denn wir sollten erst schauen daß wir das mal für das Haupttemplate hinbekommen. Wenn das mal klappt ist das anpassen für die CP Templates wahrscheinlich nur noch ein Klacks.

[Oliver Georgi]

Das Thema ist sehr trivial, und nur eine Fingerübung. Es ist kein Modul, sondern integraler Bestandteil. Die Basis ist ja längstens im System vorhanden.