DIY - Template-Konfiguration selbstgemacht

[frase]

Um die Template-Konfiguration von hier mit einer aktuellen XH-Version zu testen, habe ich mir diesen Branch geschnappt und ihn in XH 1.7.5 manuell "gemerged". Bei dieser Gelegenheit habe ich XH auch gleich noch fit für PHP 8.1.1 gemacht (mithilfe des Masters auf Github), damit man auch damit testen kann ohne Debug-Meldungen zu erhalten.
Sehr gerne hätte ich auch gleich noch das abgetrennte Adminmenü eingearbeitet (von diesem Branch) - daran bin ich aber gescheitert.
Hier müsste wahrscheinlich unser cmb mal ran (den ich insgeheim cho nenne = XH "Chief Happiness Officer").

Demo & Download

Es gibt sehr viel dazu zu sagen, ich habe einige Erfahrungen angesammelt. Damit warte ich aber noch, bis ihr das angeschaut und getestet habt, worum ich euch bitte! (Optik ist Nebensache - Technik zählt)
Ich denke, diese Möglichkeit bringt CMSimple_XH wieder näher an Gegenwart und Zukunft - und vielleicht werden bisherige Skeptiker oder auch neue XH-Benutzer das alles genau so gut finden, wie ich. Vielleicht.

[olape]

Um die Template-Konfiguration von hier mit einer aktuellen XH-Version zu testen, habe ich mir diesen Branch geschnappt und ihn in XH 1.7.5 manuell "gemerged".

Ah, jetzt ist wieder einer soweit, dass er die Geduld verliert

Toll, dass du dir die Arbeit gemacht hast.
Das mit der Templatekonfiguration werde ich mir ansehen. Obwohl ich als Nicht-Template-Designer wohl wenig dazu werde sagen können.

Bei dieser Gelegenheit habe ich XH auch gleich noch fit für PHP 8.1.1 gemacht (mithilfe des Masters auf Github),

Gibt es da schon einen vollständig kompatiblen Master?

Sehr gerne hätte ich auch gleich noch das abgetrennte Adminmenü eingearbeitet (von diesem Branch)

Oje, da müssen wir erst mal jemand finden, der noch weiss, was wir damals ausgekaspert haben.
Ich kann mich noch an scmerzende Finger erinnern. Die Diskussion dazu füllt 47 Seiten in diesem Forum.

[frase]

Das mit der Templatekonfiguration werde ich mir ansehen. Obwohl ich als Nicht-Template-Designer wohl wenig dazu werde sagen können.

Das ist natürlich für Template-Gestalter auch interessant (mehr Aufwand) - aber viel wichtiger ist die Beurteilung aus Anwendersicht!
Es ist immer noch oberstes Ziel, XH anwenderfreundlicher und noch simpler zu machen.

Gibt es da schon einen vollständig kompatiblen Master?

Weiß nicht. Ich habe mich darauf beschränkt die 4 Deprecated-Meldungen zu beseitigen (mit #[\ReturnTypeWillChange]).

Oje, da müssen wir erst mal jemand finden, der noch weiss, was wir damals ausgekaspert haben.

Na ja, das kann man gut sehen, wenn man deinen Branch "standalone" ausprobiert.
Ich find's richtig gut.
Dumm nur, dass es kaum jemand kennt.
Es müsste mal mit der neuesten XH-Version zusammengeführt, und dann bekannter gemacht werden.
Nach meiner Meinung bringen beide erwähnten Branches richtig viele Vorteile für die Anwender.

Ich kann mich noch an scmerzende Finger erinnern. Die Diskussion dazu füllt 47 Seiten in diesem Forum.

Ja, viel Hirnschmalz und viel Zeit steckt in diesen Dingen - und dann liegen sie jahrelang ungenutz herum.
Da muss es doch was geben ... ?!

[olape]

So, ich habe die hier unpassende Diskussion mal verschoben, um diesen Thread etwas übersichtlicher zu halten. Vielleicht sollten wir uns alle in Zukunft etwas mehr darum bemühen, die einzelnen Threads übersichtlich und passend zu Thema zu halten.

---------------------------------------------------------------------

Das war nun, wenn ich mich täusche, meine erste richtige Begegnung mit einem konfigurierbarem Template.
Und ich bin begeistert. Das ist sicher eine ganze Menge Mehrarbeit für die Designer, aber als Anwender kann ich es gar nicht besser haben.
Ich würde mir wünschen, dass wir das schnellstmöglich mit übernehmen. Ob im Core oder als zusätzliches Plugin??? Ich denke, angelehnt an die Konfiguration der Plugins, wäre auch das im Core schon ganz gut aufgehoben.

- Was braucht es dazu? Natürlich nachher auch Templates, die das unterstützen.

- Was mir fehlt? Ich kann die Menüpunkte zur Konfiguration derzeit nur über das DropDown-Menü erreichen. Hier fehlt noch das (Kopf)Menü wie bei den Plugins.

- und man könnte generell die Code- und Stylesheet-Ansicht über den Menüpunkt Template abwickeln (egal ob konfigurierbar oder nicht) und und dafür Stylesheet aus dem Menü in erster Ebene entfernen.

- Was gut wäre? Eine Erweiterung für die Formularfelder, in dieser Demo vor allem für die Farbe (also Colorpicker)

[frase]

Das war nun, wenn ich mich täusche, meine erste richtige Begegnung mit einem konfigurierbarem Template.
Und ich bin begeistert.

Du bist der Erste, nach 4 Jahren "gut abhängen".

Das ist sicher eine ganze Menge Mehrarbeit für die Designer, aber als Anwender kann ich es gar nicht besser haben.
Ich würde mir wünschen, dass wir das schnellstmöglich mit übernehmen. Ob im Core oder als zusätzliches Plugin??? Ich denke, angelehnt an die Konfiguration der Plugins, wäre auch das im Core schon ganz gut aufgehoben.

Ja, es ist erheblich mehr Aufwand für denjenigen, der das Template baut.
Die Vorteile für den Anwender liegen aber klar auf der Hand.
Ich bin fest davon überzeugt, dass der Core der richtige Platz dafür ist - zumal (ich betone es nochmal): alte Templates, ohne Konfiguration, funktionieren genau so weiter, wie bisher.
Und auch noch wichtig:
Nicht jedes neue Template muss eine Konfiguration haben. Das muss nach "Sinnhaftigkeit" entschieden werden.

- Was mir fehlt? Ich kann die Menüpunkte zur Konfiguration derzeit nur über das DropDown-Menü erreichen. Hier fehlt noch das (Kopf)Menü wie bei den Plugins.

- und man könnte generell die Code- und Stylesheet-Ansicht über den Menüpunkt Template abwickeln (egal ob konfigurierbar oder nicht) und und dafür Stylesheet aus dem Menü in erster Ebene entfernen.

Darüber könnte man reden.
Wahrscheinlich wird dann die Änderung im Core erheblich aufwendiger als jetzt.
Falls doch: Dann wünschte ich mir auch noch eine Seite "Template-Info", wo man Erkärungen usw unterbringen könnte.
Aber, der jetztige Vorschlag ist auch schon gut.

- Was gut wäre? Eine Erweiterung für die Formularfelder, in dieser Demo vor allem für die Farbe (also Colorpicker)

Wenn er denn Hex-Werte lieferte, dann wäre das für das Demo-Template sehr gut!

[olape]

(ich betone es nochmal): alte Templates, ohne Konfiguration, funktionieren genau so weiter, wie bisher.
Und auch noch wichtig:
Nicht jedes neue Template muss eine Konfiguration haben. Das muss nach "Sinnhaftigkeit" entschieden werden.

Und genau das würde es sogar für eine 1.7.6 möglich machen. Ich wäre dafür.
Allerdings habe ich mir die notwendigen Änderungen auch noch nicht angesehen. Kann also nicht abschätzen, wie aufwendig das ist.

[frase]

Allerdings habe ich mir die notwendigen Änderungen auch noch nicht angesehen. Kann also nicht abschätzen, wie aufwendig das ist.

Es ist überschaubar.
Wenn ich (ich!) das händisch geschafft habe ...

[frase]

Wer hat denn diese tolle Abstimmung hier eingebracht?
(erster Beitrag im Thread)
Habe sie nur zufällig entdeckt!
Wusste gar nicht, dass sowas in diesem Forum geht.
Sehr gut! Und so schön demokratisch

[olape]

Wer hat denn diese tolle Abstimmung hier eingebracht?

Kann man doch nutzen, wenn es da ist.

[lck]

Tja, jetzt gibt es hier schon eine Abstimmung zur Core-Integration, obwohl grundlegende Fragen noch gar nicht geklärt sind. Das heißt, das Ergebnis steht eigentlich schon fest.

Ich habe langsam das Gefühl, wir machen uns da eventuell unnötige Arbeit, zumindest was die Mehrsprachigkeit von Templates angeht. Aber auch zu konfigurablen Templates gibt es ja fast keine Rückmeldungen/Meinungen. Wird das alles gar nicht benötigt?

Wenn nicht, dann könnte ich mir einiges an Arbeit sparen. Wäre schön, wenn das mal geklärt würde.

Die Core-Integration wäre mindestens ebenso mächtig und sinnvoll, wie ein Plugin.

Das ist eben noch die Frage!

Und diese finde ich sehr sehr wichtig.
 

Ich bin fest davon überzeugt, dass der Core der richtige Platz dafür ist - zumal (ich betone es nochmal): alte Templates, ohne Konfiguration, funktionieren genau so weiter, wie bisher.

Woher hast du die Erkenntnis zu den Templates, hast du alle meine Templates mit Sprachdateien bereits getestet? Ich nicht, nur zwei und da gibt es dann im Backend schon mal "Warnings". Da müsste dann wieder nachgebessert werden. Nicht wirklich allzu tragisch, wer sich da etwas auskennt, aber deine Aussage ist nicht richtig.


Zurück zu deiner Demo.
Es werden keine neuen Sprachdateien aus der default.php erstellt, wenn man andere Sprachen als de oder en anlegt.