Theme Funktion für Rotation in einer View

Der Einzeiler ist schon recht cool (nur mehr als 365 Mitglieder dürfen es nicht werden :-)). Und die Problematik mit sich ändernden Mitgliederzahlen.

Ich könnte mir eine Lösung mit einem Random-Sort im View vorstellen. Das hängt natürlich davon ab, wie fixiert man auf die Lösung mit exakt einem Tag ist.

Ganz ohne irgendwelche programmatischen Klimmzüge sollte es so gehen, dass man einen View mit einem Element und zufälliger Reihenfolge (Sort) macht (das ist dann der "Hero of the day"). Und diesen View bindet man dann im View-Header des Views aller Mitglieder ein. Man kann im View ja auch ein zeitbasiertes Caching einstellen, so dass sich auch die Dauer von 1 Tag realisieren lassen sollte. Es wird dann aber vermutlich nicht exakt um 0.00 wechseln.

Da hat man dann den Promi aber auch im View für alle Mitglieder, was vielleicht auch nicht gewünscht ist.

Programmatisch könnte ich mir vorstellen einen Custom Views Sort handler zu bauen, der das bewerkstelligt. Das ist aber vermutlich nicht ganz einfach.

Eine eher etwas weniger aufwändige programmatische (dafür aber mehr hardcodierte) Lösung (im Prinzip ähnlich der aktuellen Lösung) könnte sein, sich irgendwo in den View einzuhooken (z. B.pre_render oder auch woanders) und dann die Ergebnisse umzusortieren und den z. B. per php-Zufall ausgewählten User nach oben zu schieben. Hier ist Paging ggf. ein Problem falls das im View verwendet wird.

Bei den letzten beiden Varianten hat man nicht das Problem mit dem doppelten Vorkommen des "Hero of the day".

Was ich nicht verstehe ist das hier:

Hallo Stefan,
Vielen Dank für's Mitdenken. ;-)
Mehr als 356 Mitglieder werden es nie werden, weil sie auch noch auf Kategorien aufgeteilt sind.
Da besteht keine Gefahr. Es ist auch kein Paging eingestellt, weil es eigentlich nie mehr als 50 sind.
Huch, das wäre ja kompletter Alptraum.

Der "Hero of the day" wäre auch meine Lieblingslösung und durch einen einfachen Random Sort in der View simpel realisierbar.
Aber es ist tatsächlich die Rotation oder wie es der Kunden nennt: Das Paternoster-Prinzip gewünscht.

Das funktioniert halt so, dass heute das Mitglied mit L vorne ist, dahinter kommen alle von M-Z und dann noch die von A-K.
Das meinte ich mit

Und morgen ist dann der zweite mit Buchstabe L oder dem nächsten Buchstaben oben und wer heute ganz oben ist, ist morgen der letzte.

Das mit dem Cache auf einen Tag wäre ja schön und gut. Aber es ist gar kein Caching eingestellt im Drupal 7.
Das ist, was mich so irre macht. Dennoch ist ein Effekt zu sehen, wenn ich den Drupal Cache leere.
Server-Cache gibt es natürlich auch noch und dann noch der Browser-Cache, den ich immer wieder vergesse, weil ich ihn grundsätzlich ausgestellt habe.

Vermutlich werde ich einen Hook auf die View im Modul statt im Theme probieren.
Evt. bringt das ja was.
Vorher werde ich aber noch mal den "Hero of the day" ansprechen und schmackhaft machen.
Das klingt so nett. Ich brauche nur noch eine weibliche Form davon, weil es auch Listen nur mit Frauen gibt. ;-)

Ja stimmt, das mit dem separaten View im Header beim "Hero of the day" ist ja Käse, ist ja gar nicht nötig beim Random Sort. Da habe ich es mal wieder kompliziert gemacht als es ist ...

Okay, Paternoster-Prinzip also. Das hört sich auch gut an. Ist aber auch kompliziert. Irgendwie gefällt es mir. Ich denke nochmal drüber nach.

Ja mit gefällts auch. Ich habe dem Kunden versprochen, ich halte den Ball flach beim Aufwand, weil ich es so interessant finde.
Aber ich habe auch keine Garantie gegeben, dass es eine Lösung gibt.

Hi Montviso,

Wenn diese View nicht gecached wird könnte das einen erheblichen Impact auf die Performance der Seite haben.
Schau mal hier:
https://docs.acquia.com/resource/caching/views/
und hier:
https://www.drupal.org/project/views_custom_cache

Aber eben, das wäre mit Vorsicht zu geniessen...

MfG

Robert

Hm, Robert, ich versteh nicht genau, worauf Du raus willst.
Die View ist momentan nicht gecached, die Performance ist akzeptabel, weil es ja nur wenige Einträge sind.

Das auftretende Cache-Problem entsteht also eher nicht in der View.

Hast du schon mal nach dem Leeren des Cache die Cache Tabellen beobachtet, um zu sehen, wo und woher genau Cache-Einträge generiert werden?

@Montviso

Wie lange ein Query dauert hängt nicht davon ab wieviele Einträge es sind, sonder wie komplex er ist.
Wenn mehrere User gleichzeitig auf diese View zugreifen und die jedesmal einen Query mit zig Joins
ausführen muss(anstatt aus dem Cache), dann hat das ganz sicher Einfluss auf die Performance.

Sonderlich komplex ist der Join nicht.

Und ja, es mag Einfluss haben.
Aber wenn der Cache eingestellt ist, dann klappt es sicher nicht mehr mit dem Paternoster.
Und solange der Kunde den haben will, ist Cache für ihn an der Stelle kein Thema.

Die Frage ist ja eher, was überhaupt gecached wird, wenn gar kein Drupal Cache eingestellt ist.

Das mit den Cache-Tabellen beobachten, was schmittrich vorschlägt, werde ich auf jeden Fall mal machen.

@Montviso

ich würde sagen das grob geschätzt ein halbes dutzend oder mehr verschiedene
Caches involviert sind, je nachdem was installiert und konfiguriert ist.
Aber grds. werden in Views SQL Queries und Results aus Perfomancegründen gecached.

LG

Robert

Ja, das muss ich mir mal näher ansehen, welche Chaces da anspringen - auch wenn kein Drupal Cache aktiviert ist.

https://www.drupal.org/project/views_random_seed kann da möglicherweise auch interessant sein.

Danke, Marco, das liest sich interessant.
Muss ich mich näher mit beschäftigen.