Geburtstags Widget Portal

Hi Rene,

ich war gerade auf Deiner Webseite und "Kate" steht immer noch drin, obwohl jetzt ein neuer Tag ist. Das Widget auf dem Portal greift nur die Geburtstagsliste vom Index ab und die tuts eigentlich seit 2009 fehlerfrei in allen CF3 Foren. Ich tippe also eher auf ein Datenbank oder Cacheproblem. Gerade weil offenbar "Kate" irgendwie stecken geblieben ist. Versuche mal den Cacheordner per FTP zu leeren und mache mal über phpMyAdmin ein "OPTIMIZE" auf Deine Datenbank.

Und wenn es immer nur Kate ist schau mal was dort als Geburtstag eingestellt ist, vielleicht ist dort ein Datenfehler in der DB.

LG,
Chris

Hallo René,

rein technisch kann so ein Phänomen eigentlich nicht auftreten, daher tippe ich, wenn Cache löschen nichts bringt wirklich auf einen Fehler in der Datenbank oder etwas, was nachträglich zum Paket ggf. an den Geburtstagen geändert wurde. Im Standard CF3 ist so eine Dopplung bislang noch nirgendwo ersichtlich gewesen. Hier mit der selben Version und deutlich mehr Daten in der Geburtstagsliste sind auch keine Doppler zu sehen, also ein Datums-Fehler kann es eigentlich auch nicht sein.

Vielleicht mal als kleiner Einblick wie das mit den Geburtstagen technisch realisiert ist:
Mit einem Query auf die Benutzertabelle werden die Felder für Benutzer-ID, Benutzername, Benutzerfarbe und Geburtstag abgerufen. Allerdings nur Werte, die Größer oder Kleiner dem UNIX Timestamp 0 sind (0 ist reserviert für "keinen Geburtstag eintragen" - wenn jemand genau zu Unix Timestamp Beginn 0 Geburtstag hat wird der auf 1 gesetzt (1 Sekunde merkt ja keiner)).

Mit diesem MySQL Query wird ein einziger Benutzer also zwingend nur einmal an den Code weitergegeben, da wirklich nur die Usertabelle abgefragt wird und nicht z.B. durch ein LEFT JOIN ein Verknüpfungsfehler auftreten kann (oder Tabelle 2 mehr Daten liefert und dann den Userwert mehrfach verknüpft).

Die zurückgegebenen Werte werden auf Tag und Monat umgerechnet und in einer Cachedatei gespeichert. Jeder Tag bekommt im Grunde ein Array mit dem/den Usern die an diesem Tag geburtstag haben. Da hier aber die Rückgabe der DB benutzt wird im Zeitrahmen der Geburtstagsvorschau müsste eben eigentlich von der Usertabelle pro User auch definitiv immer nur ein Wert vorhanden sein. Entsprechend sofern die Rückgabe der Datenbank so läuft, wie sie sollte, müsstest Du in der "BIRTHDAY_CACHE" Cachedatei auch definitiv jeden Benutzer nur 1x sehen. Ich gehe aber davon aus, dass sicherlich dort schon doppelte drinstehen (kannst Du das mal checken?). Das Widget bzw. auch der Index (die benutzen die selbe Funktion von $Cache->get_birthdays()) geben dann eigentlich nur noch aus, was dort drinsteht.


Lange Rede kurzer Sinn:
Da der Cache offenbar in Ordnung ist kann es nur noch die Usertable sein. Hast Du neuerdings mal einen Serverumzug oder ähnliches gehabt, bei dem die Datenbank kopiert oder verschoben wurde? Du müsstest da wirklich mal ein REPAIR und OPTIMIZE machen. Die meisten Provider bieten das komfortabel via phpMyAdmin an. Da müsstest Du lediglich alle DB Tabellen markieren und unten im Dropdown entsprechend "Reparieren" oder "Optimieren" wählen. Da die Usertabelle auf der Benutzer-ID einen PRIMARY hat kann jede Nummer eigentlich nur einmal drinstehen, sprich, jeder Benutzerwert (inklusive dem Feld für den Geburtstag) wird explizit nur 1x da sein.


Das einzige was Du auch noch machen kannst ist mal in der Konfiguration mit dem Vorschau-Wert herumzuspielen. Was passiert wenn Du das mal auf 1 Tag setzt, was passiert, wenn Du es auf 5 Tage setzt? - Und welchen Geburtstagswert haben die "steckengebliebenen" User in der DB (also sprich: Steht im Profil auch die Jahreszahl und ein Gültiges Datum?)? Vielleicht ist dort der Wert des Feldes durch irgend etwas nicht gespeichert worden? Oder greift eventuell ein Drittanbieterplugin auf Geburtstage zu?


Man könnte natürlich einfach auf die Ausgabeschleife ein array_unique setzen damit doppelte UIDs rausgeworfen werden, klar, aber da rein technisch von der DB nur ein Wert pro User kommen dürfte ist es natürlich wichtiger die Ursache zu finden - gerade eben bei so etwas sensiblem wie die Nutzertabelle sollte da jeder DB Fehler definitiv ausgeschlossen sein!


LG,
Chris


PS: Ich hab mich auch mal Sicherheitshalber durch ein paar Kundenforen geklickt wo ich weiß, dass das Portal installiert ist, da sieht die Geburstagsliste auch überall korrekt aus.

Hi René,

danke für die PM ich konnte das bei Dir nun vor Ort einmal nachstellen und darauf wäre ich hier im Support wirklich nicht gekommen: Die User, die bei Dir doppelt gezeigt wurden hatten ihren Geburtstag genau am Zeitumstellungstag.

Aufgrund der Tatsache, dass für neuere PHP5 Versionen explizit das setzen der Zeitzone hinzugefügt wurde (date_default_timezone_set) haben wir bei nicht auf reine UTC gesetzten Servern das Problem, dass die Zeitrechnung relativ zur Zeitumstellung ausgeführt wird. Bislang ist das Phänomen nie aufgetreten, weil nicht die Server-Timezone gesetzt wurde sondern einfach nur "stur" UTC.


Das Problem, dass dabei entstehen kann ist ganz und gar ungefährlich aber löst dieses Phänomen mit den Doppelten Namen aus: Die Geburtstagsvorschau geht normalerweise hin, nimmt vom aktuellen Tag den Timestamp von der Mitternacht und rechnet dann immer einen Tag drauf - allerdings aus UNIX Timestamp sicht. Die User der Vorschau werden dann entsprechend des errechneten Tages (Monat_Tag) ausgegeben.


Nun passierte folgendes:
Das Script kam am 26.10. um 0 Uhr an, wie es sein sollte und rechnete wieder die Sekundenzahl (Timestamp) für einen Tag darauf, weil die Geburtstagsvorschau eben noch einen Tag mehr brauchte.
Nun landete er aber nicht am 27.10. um 0 Uhr wie eigentlich sondern der Server bzw. die time-funktionen bemerkten, dass der neue Wert NACH der Zeitumstellung liegt und antwortete mit 26.10. 23:00 Uhr.

Da muss man auch erstmal drauf kommen. Das heißt die Geburtstagsvorschau hatte in diesem Fall einen Tag weniger als eingestellt und dafür einen Tag doppelt ausgegeben.


Ich habe jetzt einen kleinen Workaround erarbeitet, der schnell einzupflegen ist und das Problem künftig vermeiden wird. Da es sich nur um ein Darstellungsfehler handelt, der ohnehin ab Sonntag nicht mehr spruchreif ist bis nächstes Jahr hat das Zeit bis zum nächsten regulären Updatezyklus aber wer es jetzt schon korrigieren möchte findet hier eine ganz kleine Codeanpassung:
topic.php?t=17507
(Bei Dir habe ich das jetzt nur im Portal Widget gemacht, im Index hast Du es deaktiviert aber Du bekommst das mit dem nächsten Update dann ja eh automatisch mit. Nach Sonntag haben wir das Problem eh mind. 1 Jahr vom Tisch Die nächste Zeitumstellung geht eine Stunde nach vorne, das macht eh keine Probleme)

Ich habe es hier auch schon mal eingebaut, damit ich bis zum nächsten Update beobachten kann ob damit alles läuft wie es soll. Die Änderung bezieht sich auf die Statistik im Index von CF3 Foren sowie auf alle, die das Portal Widget als Plugin benutzen.


Die Vor-Ort-Kontrolle bei Dir war damit auch kostenlos, weil es ein Phänomen aufgedeckt hat das mit dem unveränderten Script auftreten kann und nichts war, was jetzt explizit nur bei Dir vorkommen kann.


LG,
Chris

Nichts zu danken!

Und was heißt blöde? Das wärst Du ja so oder so nicht gewesen! Es war ja direkt eindeutig, dass die Namen Doppelt kamen und auch bei der zunächst vermuteten DB Problematik (so ein Phänomen hatte ich auch mal wo, durch ein interner Umzug bei einem Hoster auf einen anderen Server waren die DBs sozusagen "verschmolzen" und einige Duplikate drin, was nur mit einem Repair zu lösen war) wäre das durchaus auch eine komplexere Sache gewesen wenn man nicht ständig damit zu tun hat.


LG und ein schönes Wochenende,
Chris