You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Wir verwenden auf unserer Instanz ein eigenes Theme. Da die Templates bspw. keine Conditionals erlauben (#172), habe ich das Plugin Rendering "deaktiviert" in dem ich die Templates einfach leer gelassen habe. Alles weitere läuft über Filter und Zugriff auf die internen Funktionen des Plugins. Darin liegt das Problem, dass bei manchen Updates dadurch natürlich auch in meinem Code Anpassungen notwendig sind.
Ich weiß, es ist vermutlich die absolute Ausnahme der Nutzung, wünschenswert wäre aber eine "stabile" Schnittstelle zum Plugin über die man die Daten abrufen kann. Wie hier eine gute Lösung aussieht bin ich mir aber selber nicht ganz sicher. Vielleicht bin ich aber auch vollkommen auf dem Holzweg wie ich das bisher löse, vielleicht gibt's dafür bereits ein bessere Lösung? Dann würde hierfür auch einfach eine Doku reichen.
Ich sehe auch intern im Plugin das Bedürfnis, mehr über die Templates bzw. den Formatter abzufeiern, weil dort das Abfragen und Anzeigen von Inhalten bereits gelöst ist. Es gibt bisher tatsächlich keine stablie Schnittstelle von außerhalb des Plugins, weil sowieso immer alles in Bewegung ist. Da wollte ich nichts davon unnötig in Stein meißeln, da wie du schon sagst, die Nachfrage gering war.
Für die Templates allerdings wäre es möglich, eine globale Funktion (z. B. einsatzverwaltung_render_template()) bereitzustellen. Diese wäre aktuell nur ein Alias für Formatter::formatIncidentData(), bliebe dann aber auch nach einem Rewrite des Formatters – der im Zuge der Conditionals sicher nötg wird – gleich. Damit entfällt der direkte Zugriff auf die interne Klasse.
Ließe sich alles mit dieser globalen Funktion + Conditionals in Templates lösen oder müsstest du noch andere interne Klassen ansprechen?
P.S.: Als Workaround müsste es derzeit schon funktionieren, mit dem Filter pre_option_{$option} (konkret pre_option_einsatzverwaltung_reporttemplate) ein eigenes Template zu injizieren, und dann über den Aufruf von the_content() das Plugin den Rest erledigen zu lassen. Damit könnte das Theme das Template diktieren, allerdings eben nur dieses eine pro Seite.
Wir verwenden auf unserer Instanz ein eigenes Theme. Da die Templates bspw. keine Conditionals erlauben (#172), habe ich das Plugin Rendering "deaktiviert" in dem ich die Templates einfach leer gelassen habe. Alles weitere läuft über Filter und Zugriff auf die internen Funktionen des Plugins. Darin liegt das Problem, dass bei manchen Updates dadurch natürlich auch in meinem Code Anpassungen notwendig sind.
Ich weiß, es ist vermutlich die absolute Ausnahme der Nutzung, wünschenswert wäre aber eine "stabile" Schnittstelle zum Plugin über die man die Daten abrufen kann. Wie hier eine gute Lösung aussieht bin ich mir aber selber nicht ganz sicher. Vielleicht bin ich aber auch vollkommen auf dem Holzweg wie ich das bisher löse, vielleicht gibt's dafür bereits ein bessere Lösung? Dann würde hierfür auch einfach eine Doku reichen.
Ein anderer spannender Ansätze könnte die Ermöglichung zum Überschreiben von Views sein mit Theme Files. Vielleicht wäre auch sowas denkbar?
https://theeventscalendar.com/knowledgebase/k/customizing-template-files-2/
TLDR; Ich würde Templates gerne in PHP schreiben können und mit meinem Theme bundlen.
The text was updated successfully, but these errors were encountered: