2k11 und Kommentare vom Autor

[MarioH]

Ich weiß gerade nicht, ob das erst seit dem Update auf 1.7-rc so ist, aber ich glaube schon.

Bisher hatten Kommentare von mir selbst (also Name des Autors = Name des Kommentators) immer die div-Klasse serendipity_comment_author_self, jetzt nicht mehr. Ich habe auch nochmal die aktuelle 2k11 aus github gezogen.

Woran kann das liegen?

Gruß
Mario

[yellowled]

Bisher hatten Kommentare von mir selbst (also Name des Autors = Name des Kommentators) immer die div-Klasse serendipity_comment_author_self, jetzt nicht mehr. Ich habe auch nochmal die aktuelle 2k11 aus github gezogen.

Woran kann das liegen?

Hervorragende Frage, denn: An der comments.tpl bzw. genauer an dem dafür zuständigen Abschnitt hat sich seit dem initialen commit nichts geändert. Wenn Du Dir aber sicher bist, dass das noch vor 1, 2 Versionen (von 2k11) funktioniert hat, muss es irgendetwas™ mit Smarty 3 zu tun haben.

Ich wüsste aber nicht, was. Dazu müsste Timbalu was sagen.

YL

[Timbalu]

wieso sollte Smarty3 an html klassen herumspielen? Dafür gibt es keinen Grund.

[MarioH]

Guten Morgen,

der betreffende Codeteil lautet ja:

Code: Select all

<article id="c{$comment.id}" class="serendipity_comment{if $entry.author == $comment.author} serendipity_comment_
author_self{/if} {cycle values="odd,even"} {if $comment.depth > 8}commentlevel-9{else}commentlevel-{$comment.dept
h}{/if}">

Kann es eventuell ein Problem mit den Variablen sein. Werden die vielleicht nicht mehr wie bisher versorgt?

Nur mal so ins Blaue gedacht.

Gruß
Mario

[Timbalu]

komischer Umbruch...

mir fällt da ansonsten nur das hier ein http://board.s9y.org/viewtopic.php?f=2&t=13593
lies das mal bis zum "bitteren" Ende...

[garvinhicking]

Hi!

Nur als Idee - evtl ist tatsächlich {$entry} nicht mehr in der comments.tpl gesetzt? Bei Smarty2 waren immer alle Variablen des vorigen einbindenden TPLs (entries.tpl) auch in dem "Kindtemplate" (comments.tpl) vorhanden. Evtl hat sich das in Smarty3 geändert wenn man $entry nicht explizit einbindet?

Das wäre problematisch, denn dann könnte es tendentiell jede Menge Variablen geben die dann nicht mehr belegt sind.

Mir fehlt heute leider die Zeit das zu testen. Ihr könntet einfach mal in der comments.tpl die {$entry.author} und {$comment.author} einfach ausgeben, dann sieht man ja ob die unterschiedlich oder nicht belegt sind!?

Grüße,
Garvin

[Timbalu]

hmm, das wäre ja wenn tatsächlich soetwas wie die neue Vererbung in Smarty3 benutzt wäre... aber das haben wir doch (noch) nicht...!?

[MarioH]

Wenn ich das so "hart" codiere:

Code: Select all

<article id="c{$comment.id}" class="serendipity_comment{if $comment.author == 'Mario Hommel'} serendipity_comment_author_self{/if} {cycle values="odd,even"} {if $comment.depth > 8}commentlevel-9{else}commentlevel-{$comment.depth}{/if}">

dann funktioniert die Zuweisung der Klasse. Also scheint es tatsächlich an der Variablenvererbung zu liegen?

Nachtrag: Ich habe jetzt auch mal "entry.author" im Kommentar ausgegeben, ist tatsächlich leer.


Gruß
Mario

[Timbalu]

$comment.author ist bereits da.

Code: Select all

{foreach from=$entries item="dategroup"}
    {foreach from=$dategroup.entries item="entry"}
		{$entry.author} und {$comment.author}
	{/foreach}
{/foreach}

Die $entry.author muss in der comments.tpl erst ausgewrungen werden (siehe oben) oder in der entries.tpl, innerhalb des foreach blocks der item="entry" setzt, als

Code: Select all

{assign var="entryauthor" value=$entry.author scope="parent"}

der comment.tpl bekannt gemacht werden, da scheinbar die entries.tpl in der Verarbeitungshierarchie von Smarty kurzerhand als ein Kind von comments.tpl definiert wird. Dann ist {$entryauthor} auch erhältlich.
Die Abfrage müsste dann ungefähr soetwas sein

Code: Select all

{if ($entry.author OR $entryauthor) == $comment.author}

Das ist bemerkenswert....

[garvinhicking]

Grrr. Das ist echt kacke, da müssen wir den RC2 dann noch länger delayen und eigentlich ALLE .tpl Dateien durchgehen und schauen, wo in einer .tpl auf die Werte einer anderen .tpl zugegriffen werden, was in Smarty2 ging aber nicht mehr in Smarty3.

Puh. Keine Ahnung wann ich dazu Zeit habe...aber potentiell bringt das noch viel mehr Probleme als nur dieser eine der jetzt auffiel.

Grüße,
Garvin

[garvinhicking]

Spontan gefundene andere Beispiele:

trackbacks.tpl - $entry.is_entry_owner
comments.tpl - $entry.is_entry_owner, $entry.allow_comments,

[Timbalu]

Kannst du nicht mal Rodney anzwitschern, ob er einen internen Kniff kennt, wie dieses scoping eventuell ausgeschaltet wird oder auf den Stand von S2 zurückkehrt, wenn kein explizites smarty template inheritance verwendet wird?
Oder wir brauchen soetwas

Code: Select all

$smarty->display('extends:entries.tpl|comments.tpl|someother.tpl'); 

...

[Timbalu]

Spontan gefundene andere Beispiele:

trackbacks.tpl - $entry.is_entry_owner
comments.tpl - $entry.is_entry_owner, $entry.allow_comments,

Müßten sich, ebenso wie für die comments.tpl, mit

Code: Select all

{assign var="entry" value=$entry scope="parent"}

(zur Not auch scope=root)
in der entries.tpl abdecken lassen. Dann steht das $entry array komplett zur Verfügung und muss nur in der entries.tpl so assigned werden. Die alten Zugriffe per $entry.author und $entry.is_entry_owner etc. in den anderen template Dateien sollten damit funktionieren.

Mario, kannst du das mal für die trackback abchecken?

[yellowled]

Das ist echt kacke, da müssen wir den RC2 dann noch länger delayen und eigentlich ALLE .tpl Dateien durchgehen und schauen, wo in einer .tpl auf die Werte einer anderen .tpl zugegriffen werden, was in Smarty2 ging aber nicht mehr in Smarty3.

So richtig gangbar ist das doch eigentlich auch nicht.

Es wäre machbar für .tpl-Dateien im Kern und mit dem Kern ausgelieferte Templates und smartifizierte Plugins, aber auch da kommt doch wieder das Problem mit Templates auf Spartacus und Custom-Zeug, auf das wir keinen Zugriff haben. Letzteres ist zwar irgendwo das Problem des Autors, aber die Spartacus-Templates werden ja nicht mal halbautomagisch aktualisiert …

Da muss es doch irgendeinen „Schalter“ in Smarty 3 geben.

YL

[Timbalu]

Rein theoretisch sollte es nur da vorkommen, wo irgendwelche {serendipity_print* hooks definiert werden, oder? Dies würde auch erklären, warum zB die comments.tpl als scope=parent angesehen wird. Und wirklich effektiv würde es dann nur die entries.tpl mit dem genannten

Code: Select all

{assign var="entry" value=$entry scope=parent}

betreffen, da die sidebar.tpl keine parent variablen benutzt.
In 2k11 wären das:

Code: Select all

 /.../git-master/templates/2k11/entries.tpl (2 hits)
	Line 84:             {serendipity_printTrackbacks entry=$entry.id}
	Line 98:             {serendipity_printComments entry=$entry.id mode=$entry.viewmode}
 /.../git-master/templates/2k11/index.tpl (2 hits)
	Line 79:             {serendipity_printSidebar side="left"}
	Line 85:             {serendipity_printSidebar side="right"}

Damit sollte an sich schon alles erledigt sein.
Die Frage ist: Was macht ein {assign var="entry" value=$entry scope="parent"} in einer Smarty2 Installation, alles richtig, gar nichts, oder meldet es vielleicht sogar einen Fehler? Denn sonst müssten wir noch zusätzlich einen smarty switch verbauen der nur in Smarty3 environments aktiv wird.

Sollte ich damit richtig liegen, ist der Aufwand gering und ein konkreter Hinweis an alle Upgrader sollte genügen, um der geänderten Sachlage Herr zu werden.
Smarty3 ist nämlich durchaus ein echter Fortschritt, auch wenn ein paar liebgewonnene Dinge flöten gehen.