Templates in Wordpress

[BaBa]

Hallo allerseits,

Templates für Wordpress themes liegen m.W.n. immer als php-Dateien vor. Das bedeutet dann, dass html markup und php-Bausteine sich abwechseln, e.g.:

div class="site-info">
  <?php do_action( 'twentyfourteen_credits' ); ?>
  <a href="<?php echo esc_url( __( 'http://wordpress.org/', 'twentyfourteen' ) ); ?>"><?php printf( __( 'Proudly powered by %s', 'twentyfourteen' ), 'WordPress' ); ?></a>. Copyright © <?php echo date( 'Y' ); ?>  Your Company Inc.
</div><!-- .site-info -->

Kann mir jemand sagen, warum dies so ist? Ich persönliche finde es besser, wenn html-Templates auch html-Dateien sind. Dann fügt man Platzhalter ein und parsed das Template mittels php, um die Inhalte einzufügen. Die Vorteile: html bleibt html, ich kann in der IDE die Syntax besser highlighten, Verschachtelungen besser erkennen, das ganze schneller tippen und es ist allgemein übersichtlicher. Aber was ist der Nachteil? Performance? Wieso setzt also WP auf html-Templates mit so einem Kauderwelsch?

Cheers,
BaBa

[Sophie]

Hallo, dann verwende doch Smarty, dann hast du wieder alles schön getrennt.

[BaBa]

Hallo, dann verwende doch Smarty, dann hast du wieder alles schön getrennt.

Meine Frage war eher, warum dies getan wird.

Cheers,
BaBa

[dedlfix]

Tach!

Kann mir jemand sagen, warum dies so ist?

Weil es die PHP-Philosophie ist.

Ich persönliche finde es besser, wenn html-Templates auch html-Dateien sind.

HTML-Templates sind ein Gemisch aus HTML und Template-Syntax. Das ist im Grunde genommen nichts anderes als ein Gemisch aus HTML und PHP-Syntax.

Dann fügt man Platzhalter ein und parsed das Template mittels php, um die Inhalte einzufügen.

Oder der PHP-Parser parst es gleich selbst, ohne dass du zusätzlichen Code für einen Template-Parser schreiben/einbinden/laufenlassen musst.

Die Vorteile: html bleibt html, ich kann in der IDE die Syntax besser highlighten, Verschachtelungen besser erkennen, das ganze schneller tippen und es ist allgemein übersichtlicher.

Das HTML bleibt ja nicht HTML, wenn du es mit Template-Syntax versiehst. Außerdem würde ich die IDE wechseln, wenn sie nicht mit PHP umgehen kann.

Aber was ist der Nachteil? Performance? Wieso setzt also WP auf html-Templates mit so einem Kauderwelsch?

Weil es das kann. Und weil man dann nicht noch ein Template-System mitzupflegen und zu dokumentieren hat.

dedlfix.

[Gunnar Bittersmann]

@@BaBa

Wieso setzt also WP auf html-Templates mit so einem Kauderwelsch?

Weil Backend-Entwickler sich überhaupt nicht der Problematik bewusst sind, die es mit sich bringt, wenn man Markup mit PHP zusammenstückelt.

LLAP 🖖

[dedlfix]

Tach!

Wieso setzt also WP auf html-Templates mit so einem Kauderwelsch?

Weil Backend-Entwickler sich überhaupt nicht der Problematik bewusst sind, die es mit sich bringt, wenn man Markup mit PHP zusammenstückelt.

Und diese Problematik wäre welche?

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Weil Backend-Entwickler sich überhaupt nicht der Problematik bewusst sind, die es mit sich bringt, wenn man Markup mit PHP zusammenstückelt.

Und diese Problematik wäre welche?

Dass man sich, um Änderungen am Frontend zu berwerkstelligen, durch Backend-Code durchwühlen muss. Sucks. Big. Time.

Im Übrigen lässt solche von Backend-Entwicklern erstellter Code ofmals die vorhandene Ahnung von HTML erkennen: annähernd null. Folgen: nicht benutzbare Webanwendungen.^[1]

LLAP 🖖

---

1. Eine Webanwendung ist nicht benutzbar, wenn sie nicht von allen Nutzern verwendet werden kann. ↩︎

[dedlfix]

Tach!

Weil Backend-Entwickler sich überhaupt nicht der Problematik bewusst sind, die es mit sich bringt, wenn man Markup mit PHP zusammenstückelt.

Und diese Problematik wäre welche?

Dass man sich, um Änderungen am Frontend zu berwerkstelligen, durch Backend-Code durchwühlen muss. Sucks. Big. Time.

Template-Code im Backend ist auch Backend-Code. Ich sehe den Unterschied nicht, außer der verwendeten Syntax. Auch eine Template-Engine mit anderer Syntax als PHP stückelt das Markup zusammen.

Im Übrigen lässt solche von Backend-Entwicklern erstellter Code ofmals die vorhandene Ahnung von HTML erkennen: annähernd null. Folgen: nicht benutzbare Webanwendungen.[^1]

Aussagegehalt dieses Satzes: annähernd null.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Template-Code im Backend ist auch Backend-Code. Ich sehe den Unterschied nicht, außer der verwendeten Syntax. Auch eine Template-Engine mit anderer Syntax als PHP stückelt das Markup zusammen.

Ich habe nichts gegen PHP als Template-Engine:

<fieldset>
  <legend><?= $myRadioButtonsLegend ?></legend>
<? foreach ($myRadioButtons as $myRadioButton): ?>
  <label for="<?= $myRadioButton['id'] ?>"><?= $myRadioButton['label'] ?></label>
  <input type="radio" name="myRadioButton" id="<?= $myRadioButton['id'] ?>"/>
<? endforeach; ?>
</fieldset>

Gut, der eingangs gezeigte Code war auch fast so. Fast. <?php do_action( 'twentyfourteen_credits' ); ?> passt da nicht rein.

Im Übrigen lässt solche von Backend-Entwicklern erstellter Code ofmals die vorhandene Ahnung von HTML erkennen: annähernd null. Folgen: nicht benutzbare Webanwendungen.[^1]

Aussagegehalt dieses Satzes: annähernd null.

Heute ist Global Accessibility Awareness Day – das darfst du gern zum Anlass nehmen, über diesen Satz nachzudenken, bis sich dir dessen Aussagegehalt erschließt.

LLAP 🖖

[dedlfix]

Tach!

Im Übrigen lässt solche von Backend-Entwicklern erstellter Code ofmals die vorhandene Ahnung von HTML erkennen: annähernd null. Folgen: nicht benutzbare Webanwendungen.[^1]

Aussagegehalt dieses Satzes: annähernd null.

Heute ist Global Accessibility Awareness Day – das darfst du gern zum Anlass nehmen, über diesen Satz nachzudenken, bis sich dir dessen Aussagegehalt erschließt.

Erschließt sich mir trotzdem nicht. Ich sehe da nur eine gefühlte Statistikaussage in einer herablassenden Aussage über Backend-Entwickler - als ob alle Frontend-Entwickler annähernd hunderprozentig nutzbare Anwendungen zu schreiben in der Lage wären.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Erschließt sich mir trotzdem nicht.

Wenn man eine Backendentwickler-Tastatur hat (wie auf Folie 2 zu sehen), dann kommt halt Code raus wie auf Folie 7 zu sehen.

Ich sehe da nur eine gefühlte Statistikaussage in einer herablassenden Aussage über Backend-Entwickler

Das war eine Aussage darüber, was Backend-Entwickler üblicherweise nicht beherrschen: HTML. Das war nicht herablassend, sondern einfach nur feststellend. Ebenso wie die Aussage, dass ich von Datenbanken so gut wie keine Ahnung habe.

als ob alle Frontend-Entwickler annähernd hunderprozentig nutzbare Anwendungen zu schreiben in der Lage wären.

Das sollten sie sein. Wobei ich JavaScript-(Backend)-Programmierer nicht zu Frontend-Entwicklern zähle, auch wenn sie sich selbst so bezeichnen mögen.

LLAP 🖖

[dedlfix]

Tach!

Ich sehe da nur eine gefühlte Statistikaussage in einer herablassenden Aussage über Backend-Entwickler

Das war eine Aussage darüber, was Backend-Entwickler üblicherweise nicht beherrschen: HTML. Das war nicht herablassend, sondern einfach nur feststellend. Ebenso wie die Aussage, dass ich von Datenbanken so gut wie keine Ahnung habe.

Bei mir kam an, dass die Backender nicht die geringste Ahnung (in Worten: null) vom Frontend haben, sozusagen von HTML gehört haben, dass es das gibt, es aber noch nie gesehen haben. Es ist sicherlich besonders hilfreich beim Bemühen um bessere Frontends diejenigen, die sich mit beidem beschäftigen (müssen), derartig abzukanzeln. Nicht.

als ob alle Frontend-Entwickler annähernd hunderprozentig nutzbare Anwendungen zu schreiben in der Lage wären.

Das sollten sie sein. Wobei ich JavaScript-(Backend)-Programmierer nicht zu Frontend-Entwicklern zähle, auch wenn sie sich selbst so bezeichnen mögen.

Warum ziehst du überhaupt solche Zäune? Probier es doch zur Abwechslung mal mit Inklusion.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Bei mir kam an, dass die Backender nicht die geringste Ahnung (in Worten: null) vom Frontend haben

Dem ist auch oft so. Es sei denn, du bezeichnest <div><div>…</div></div> als „Ahnung von HTML“.

Und das gepaart mit dem Unwillen, sich mit HTML zu beschäfigen. „Wozu main, section usw.; mit div geht’s ja auch!“

Warum ziehst du überhaupt solche Zäune? Probier es doch zur Abwechslung mal mit Inklusion.

Dazu gehören zwei Seiten. Wenn derjenige auf der anderen Seite nicht gewillt ist, Verständnis für HTML aufzubringen, kann man nur sagen: Mach das Backend und lass die Finger vom Frontend.

Natürlich gibt es auch Backendentwickler, auf die das glücklicherweise so nicht zutrifft. Und man sollte versuchen, seine Backendentwickler so zu erziehen, dass es auf sie irgendwann nicht mehr zutrifft.

LLAP 🖖

[dedlfix]

Tach!

Bei mir kam an, dass die Backender nicht die geringste Ahnung (in Worten: null) vom Frontend haben

Dem ist auch oft so. Es sei denn, du bezeichnest <div><div>…</div></div> als „Ahnung von HTML“.

Ich bezeichne das als "wenig Ahnung von HTML", und ich beziehe das auf denjenigen, der das so fabriziert, aber ohne dass ich das auf Backend-Entwickler beziehe und damit einer ganzen Gruppe Kompetenzen abspreche.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Dem ist auch oft so. Es sei denn, du bezeichnest <div><div>…</div></div> als „Ahnung von HTML“.

Ich bezeichne das als "wenig Ahnung von HTML"

Für mich ist das so wenig, dass es schon zu nahe an null liegt, um sprachlich davon abgegrenzt zu werden.

und ich beziehe das auf denjenigen, der das so fabriziert, aber ohne dass ich das auf Backend-Entwickler beziehe

Dass das oftmals auch auf JavaScript-Programmierer zutrifft, hatte ich auch erwähnt.

und damit einer ganzen Gruppe Kompetenzen abspreche.

Was ich auch an keiner Stelle getan habe.

LLAP 🖖

[Klawischnigg]

Hi there,

Für mich ist das so wenig, dass es schon zu nahe an null liegt, um sprachlich davon abgegrenzt zu werden.

Und während andere mit dem wenigen Geld verdienen, bist Du mit Deiner sprachlichen Abgrenzung in Schönheit gestorben. RIP…