Beiträge von Synonym

Da ist das BSI schön langsam. Ist doch schon knapp eine Woche bekannt. Betroffen sind quasi keine aktuellen Distros. Nur in Sonderfällen, wenn was anderes benutzt wird, das darauf zurückgreift.

Hi, Danke Dir, auch wegen den Warnungen. Aber ich kann Dich beruhigen, SQL-Injections sind nicht möglich. Wie gesagt, das ist nur ein kleiner, relevanter Auszug. Die Daten sind alle mehrfach geprüft, werden vom Script selbst erzeugt und wenige Zeilen vor der jeweiligen Query überhaupt erst gesetzt. Mit dem Now und dem Cache hast Du recht. Mache ich normalerweise auch nicht so, sondern so wie Du. Ist hier aber egal, denn der Durchlauf ist eh nur einmal minütlich und da wäre es dann auch per PHP und direktem Date ohne Cache, da jede Minute eine neue Uhrzeit Der Vorteil so, es lässt sich leichter Debuggen, wenn man sich die Querys ausgeben lässt, dann steht da nämlich schlicht das Mysql-NOW und nicht irgendein Zeitstempel.

Datenbank, PHP, Webserver, alles, ist auf der gleichen Maschine. Da ist auch nur die eine Domain drauf.

Deine Mysql-Query scheint nicht ganz zu stimmen bzw. ist zu "neu". %Z kennt mein MariaDB nicht. Er gibt daher keinen Zeitzonennamen aus, sondern einfach "Z". %Z gibt es erst ab Version 11.3, ich habe hier 10.11, vorher 10.8

Aber ja, MariaDB ist korrekt, kennt den Offset von aktuell 2 Stunden.

Also wegen Brave. Da scheint es wohl auch andere zu betreffen.

https://community.brave.com/t/brave-browse…ell-help/541301

Und eben auch Youtube

https://community.brave.com/t/aggregate-to…tube/541251/176

Bei mir versucht, da geht alles. Version 1.64.116 auf Win10.

Na, das mit den Zeitzonen ist kein Problem, echt nicht. Das 13 und 14 Uhr war auch nur ein fiktiver Wert, der eigentlich so von allen genommen wird. Andere nehmen auch 10 und 14 Uhr oder so. Es geht da um An- und Abreisen. Im Grunde geht es hier nur um ein Datum, also z.B. "2024-04-04" und "2024-04-04"- Das hat halt eine Zeit dabei, damit klar wird, was davon die Abreise und was die Anreise ist. Abreise ist früher, Anreise später. Klar, es kann in ganz entfernten Ländern Probleme geben, das ist technisch möglich. Aber mit den Werten ist es so, dass 99,999999% aller Nutzer kein Problem haben, denn es wird sich durch die verschiedenen Zeitzonen kein Tag an sich ändern. Zielgruppe ist ja primär Europa bzw. eben was in den Zeitzonen -0500 bis +0500.

Wegen den anderen Dingen, da wo Zeiten benutzt werden, die sind nur in DE bzw. eben alle an einem Ort.

Code ist nun stark minimiert, aber nichts Besonderes.

$update_interval = 3600-10;

// -10 Sek, weil der Scriptdurchlauf ein paar Sekunden braucht und der Cron nur im Minutentakt läuft. Der Abstand ist also eine Stunde oder ein paar Sekunden weniger, aber niemals mehr. Würde sich sonst aufschaukeln und jede Stunde mehr werden. Scriptsurchlauf ist ca. 2-5 Sekunden.

$sql = 'SELECT x FROM y AS blki WHERE blki.aktiv = 1 AND blki.next_import < now() LIMIT 25';

// Next_import ist schon ein Wert in der DB, der als +1 Stunde gespeichert wird. Daher einfach der Vergleich, ob der gespeicherte Wert kleiner als der aktuelle Wert ist. Wenn ja, dann ist der Eintrag älter als eine Stunde.

Dann erfolgt die Verarbeitung der Daten, die von extern kamen. Haben aber mit den eigentlichen Zeiten nichts zu tun. Da kommt nur das mit An- und Abreise zu tragen bzw. werden die Daten aufbereitet.

$next_import = date('Y-m-d H:i:s', time()+$update_interval);

$sql = 'UPDATE y SET last_import = \''.$date_last_import.'\', error_count = 0';
if($date_last_modified !== false) $sql .= ', last_modified = \''.$date_last_modified.'\'';
$sql .= ', next_import = \''.$next_import.'\' WHERE uk_id = '.$import['uk_id'];

So, und da ist dann eigentlich auch das Problem. Nicht immer, aber manchmal. Genau suchen konnte ich noch nicht.

Wenn ich also einen Datensatz manuell in der DB eintrage, dann ist "next_import" z.B. aktuell "08:14:22", eben "jetzt" + eine Stunde Intervall. Das sollte dann ja die erste Query erfassen und abfragen. In einer Stunde ab jetzt würde der dann fällig und müsste selektiert werden. Ist aber eben nicht der Fall. Selektiert wird er quasi erst in 3 Stunden. Also die reguläre +1 Stunde und eben die +2 Stunden Sommerzeit.

Beim Update dann wird es wieder seltsam, denn dann geht das GMT / UTC-Spiel wohl umgedreht. Sprich. Wenn der dann endlich mal selectiert hat und dann am Ende das "next_import als neuen Wert in die DB schreibt (updatet), dann ist das keine GMT-Zeit mehr, sondern UTC. Der schreibt dann also kein "10:14:22" rein, was eben dann rechnerisch sein müsste, sondern dann UTC "08:14:22". Also jede Zeit dann entsprechend abzüglich Winter- oder Sommerzeit, rein UTC eben. Und beim nächsten Durchlauf wird dann sofort selectiert, weil "next_update" nicht mehr eine Stunde in der Zukunft ist. Steht dann ja "08:14" in der DB, obwohl in echt schon "10:14" ist.

Also völlig wirr. Erst wird der Zeit +2 Stunden Sommerzeit hinzugerechnet, beim ersten Durchlauf und dann bei jedem weiteren wird jeweils +2 Stunden abgezogen und in die DB geschrieben. Was dazu führt, dass eben der erste Import viel zu spät kommt und dann bei den folgenden keine Pause von einer Stunde. Sondern die gleichen immer wieder jede Minute kommen. Was sinnlos ist, denn es sind ja immer die selben, limitiert mit dem "Limit 25" in der Query. Eigentlich ist die Zeitsperre ja da, damit der an die 900 Importe pro Stunde fährt und dann eben, eine Stunde später, wieder alle durcharbeitet. Jeder Import soll einmal pro Stunde laufen.

Das funktioniert auch alles seit 15 Jahren. Nur eben nicht mehr richtig, seit dem Notumstieg auf einen neuen Server mit PHP 8.2

Das habe ich nun in der Ini gesetzt. Also PHP weiß das eigentlich schon.

Wenn ich mir die phpinfo nun ansehe, dann schaut die quasi so aus wie die von php 7.4, nur eben, dass ich nun bei Timezone einen Wert habe. Vorher und default ist ja "leer", also vorher "OS".

Ein "date_default_timezone_get()" liefert auch den korrekten Wert.

Das mit den Nutzern weltweit habe ich auch, aber ich mache es dennoch ohne Zeitzonen, denn es gibt in den wichtigen Bereichen nur zwei Zeiten. 13 und 14 Uhr. Da ist das quasi egal, wer in welcher Zeitzone ist. In den Berechnungen geht das in dem Fall auch nicht ein. Dieses 13 und 14 Uhr markiert quasi nur Ende und Start an einem Tag.

Bei PHP heißt es nur sinngemäß, dass man date / time als Funktion nicht mehr nutzen sollte oder die gm-Funktionen, sondern stattdessen die Date-Klasse nehmen soll und dort dann mit "DateTimeImmutable".

Der Rest, also Cache und so oder eben Interval-Abruf, der braucht nur einen bestimmten zeitlichen Abstand. Zeitzonen sind da auch egal. Also z.B. +1 Stunde eben, egal welche Zone. Das Problem ist ja da irgendwie, dass das Datum in der DB, also das, wie es in Deutsch sein sollte, nicht wirklich das ist, was ich errechne mit time() oder mktime() + 3600 oder date +1 Day. Wie gesagt, ich raffe es noch nicht ganz, es geht an vielen Stellen, aber an einigen nicht.

Lass mich ausholen.

Mein Server nutzt GMT, das ist korrekt. Er nutzt aber auch die Sommerzeit, also automatische Zeitumstellung.

Der Server ist also genauso wie jeder andere Server mit PHP 7.4 auch.

Nun mit PHP8 ist es aber so, dass der Wert "default timezone" eben leer ist. Gut, war er vorher auch, aber da hatte PHP dann ja automatisch den Wert vom OS genommen. Also entweder globale ini, oder user.ini oder eben OS. Letzteres ist nun nicht mehr der Fall. PHP nimmt als default, denn leer ist auch default, immer UTC.

In den meisten Fällen speichere ich die Daten einfach als Uhrzeit oder eben als Datetime in der DB, also als "07:47:56" oder eben als "2024-04-03 07:47:56". Also auch so wie immer. Zeitzonen werden nicht gespeichert, da für das Vorhaben nicht relevant.

Speichere ich hier z.B. bei PHPMyadmin einen neuen Datensatz, der now() als default hat auf einer Zelle oder eben "on Update", dann ist das die aktuelle Zeit, also "07:47:56". Steht so auch in der DB. Rufe ich das ab und gebe es mit PHP aus (date()-Funktionen), das steht das auch korrekt auf der Seite.

An manchen Stellen passiert es aber, da wurde ich noch nicht ganz schlau draus, dass PHP dann mit dem Datum rechnen muss und der Meinung ist, dieses 07:47:56 wäre UTC. In der Berechnung meint PHP dann also, das wäre 09:47:56.

Und da gibt es dann eben ganz simple Funktionen wie "wenn kleiner als "now()", dann mache X, ansonsten überspringe". Nachdem das aber eben in der Berechnung dann "09:47" ist, läuft er ins "überspringe".

Selbiges Verhalten auch mit File-Opreationen. Habe da einen normalen Cache, der auf Create-Time beruht. Älter als 90 Minuten, soll neu erstellt, ansonsten eben das Temp-File genommen werden. Auch da hackt es, denn irgendwie sind die Files alle "outdated", obwohl gerade erst neu angelegt.

Und, PHP8 war auch nicht ganz richtig. Wenn ich das richtig gelesen habe, gibt ja noch andere mit dem Problem, dann ist das wohl seit PHP 8.2 so.

Stelle ich den Server auf UTC um, dann arbeitet alles ganz normal. Das ist aber doof. Ich hätte gerne deutsche Zeiten in den Logs stehen etc und vor allem importiere ich auch viele Daten, die Zeiten enthalten und da steht auch keine Zeitzone dabei. Default ist da aber überall "Berlin".

Sei still! Das sag nicht nur ich, sondern auch die Nationale Stillkommission in Karlsruhe.

Mir gefällt das, denn ich habe seit der Serverumstellung und PHP 8 ein gewaltiges Zeitenproblem. Irgendwie macht die Datenbank Zulu, PHP eine Mischung aus Zulu und Zeitzone und PHPMA besteht auf "Sommerzeit". Super. Alles, was irgendwie regelmäßig stündlich stattfinden soll, geht nun nicht mehr, da die Zeiten nun 2 Stunden auseinander liegen.

Ich trage also einen neuen Datensatz in die DB ein, der erhält dann automatisch durch datetime() z.B. 08:03 als Zeitstempel. Das ist aber 08:03 Sommerzeit. PHP ruft dann ab und prüft, ob älter als eine Stunde. Jo, für PHP ist das 08:03 aber Zulu, also intern ist es da dann 10:03. Und nein, jetzt in Bezug auf die Zeit ist dann eben nicht eine Stunde. Sprich, das Script, das eigentlich um 09:03 wieder laufen müsste, läuft nicht, weil intern ist es ja 10:03. Verflucht noch mal. Hab da nun schon einiges geändert und angepasst, aber es will einfach nicht richtig.

Und ich frage mich wirklich, warum so eine Änderung an PHP 8 nicht im Changelog als Breaking-Changes hinterlegt ist.

Die "Default timezone" war in PHP immer die vom OS. Nun ist das nicht mehr so und default "UTC". Sämtliche date()- und time()-Funktionen liefern falsche Werte. Dann hab ich das schon manuell geändert auf "Default timezone = Europe/Berlin", was aber irgendwie auch nicht wirklich funktioniert, wie ich heute merken musste

Seltsam finde ich, dass es zwei Personen betrifft. Ansonsten hätte ich es auf Deinen Rechner oder die Webseite geschoben.

Selbst hatte ich so was aber auch schon, sogar mehrfach. Da ist der Firefox auch direkt eingefroren. Also erst die Meldung "Tab reagiert nicht... warten oder abbrechen" und dann komplett eingefroren, alle Tabs.

Da lag es an der Webseite.

Und bei einigen anderen, wo auch plötzlich einfrieren, aber alle Browser, lag es an Adsense.

Keine Ahnung. Da ist nur das übliche drauf. An geolocation liegt es auch nicht, denn auch Madrid oder Vilnius gehen hier.

P.s. mobile mit Samsung Internet geht auch

Geht hier in Brave, Chrome, Opera, Firefox, Edge problemlos. Ladezeit jeweils 1,6 bis 2 Sekunden. Das erste was kommt ist der Cookie-Hinweis, dann geht alles ganz normal weiter.

Brave ohne irgendwas, also so, wie er installiert wurde.

Ich kann Dir da uneingeschränkt zustimmen. Bei Wix stört mich vor allem der Name, aber das ist wohl so ein "deutsches" Ding. Ich habe viele Nutzer, die bei Wix oder Jimdo sind. Einige Seiten sehen aus wie aus den 90er Jahren, die anderen sind top-modern, wo selbst Wordpress und Co neidisch werden dürfte. Ich weiß bei den Leuten allerdings nicht, wie die an so ein Layout kommen, denn so altbackenes Zeug bieten die beiden Baukästen gar nicht an. Das muss man schon selbst so umbauen, dass es so wird.

Da ich eben auch viele Nutzer habe, die eine Webseite wollen oder eine haben, dann aber eher bei Beepworld und Co, empfehle ich denen immer Jimdo oder Wix. Bei Wix weiß ich es nicht, aber Jimdo war früher immer sehr sehr billig und hatte mit Abstand die beste Ausstattung. Da konnte keiner mithalten, kein T-Online, kein 1und1, kein Strato, kein anderer eben. Jimdo lag bei 60 Eur inkl. eigener Domain für 2 Jahre, also 30 Eur pro Jahr. IN den letzten Jahren haben die aber deutlich aufgeschlagen und liegen nun bei so 12 Eur im Monat. Oder eben, ohne eigene Domain und nicht "Pro", die Free-Version. Das Wichtigste hatte die auch alles drinnen.

Und ja, für kleine Seiten oder wirklich Anfänger sind beide wesentlich einfacher als z.B. ein Wordpress.

Hab vor drei Tagen erst eine Jimdo-Seite von einem Kunden in die Kündigung gebracht, wegen Aufgabe. Wenn man nicht wüsste, dass das eine Jimdo-Seite ist, würde man das nicht merken. Viel mehr könnte man mit WP da auch nicht machen, ohne alles manuell im Code zu machen.

Es laufen mehrere Updates gleichzeitig. Das in Deinem Link ist das Spam-Update. Es läuft aber auch das Core-Update und noch weitere. Die sind nun zwar alle "integriert" im "Core", aber dennoch einzeln für sich. Laut Google soll es das größte Update ever sein und in den Suchergebnissen sollen ca. 40% der Spamseiten oder Seiten mit nicht hilfreichen Inhalten oder nicht einmaligen Inhalten entfernt werden.

Mich erschreckt da mal wieder das "nicht einmalig", wenn ich daran denke, wie oft andere Inhalte kopieren und daraus was "eigenes" machen.

Das Core-Update dauert ca. 4-5 Wochen, das reine Spam-Update ca. 2 Wochen.

• Name: Google März 2024 Broad Core Update
• Gestartet: 5. März 2024 um etwa 12 Uhr ET
• Rollout: Es wird ca. einen Monat dauern, bis das Update vollständig ausgerollt ist - während des Rollouts werden zahlreiche Änderungen an zahlreichen Core-Systemen vorgenommen
• Ziele: Es betrifft alle Arten von Inhalten
• Strafe: Es handelt sich nicht um eine Bestrafung, sondern um die Förderung und Belohnung guter Webseiten
• Global: Es handelt sich um ein globales Update, das alle Regionen in allen Sprachen betrifft.
• Auswirkung: Laut Google wird es zu einer 40-prozentigen Reduzierung von minderwertigen, unoriginellen und wenig hilfreichen Inhalten in den Suchergebnissen führen.
• Entdecken: Die Core-Updates wirken sich auf Google Discover und andere Funktionen aus, außerdem auf Feature Snippets und mehr.
• Wiederherstellen: Wenn Sie davon betroffen sind, müssen Sie Ihre Inhalte überprüfen und sehen, ob Sie mit den Empfehlungen von Google zum Core-Update besser werden können.
• Auffrischungen: Google wird diesen Algorithmus in regelmäßigen Abständen auffrischen, aber diese Aktualisierungen in Zukunft nicht mehr kommunizieren.

https://developers.google.com/search/blog/20…e-spam-policies

https://status.search.google.com/incidents/1jW2F89qC2NxJBWGiKxE

Ja keine Ahnung. Hier ging Fb. War da an die 3 Stunden alle 5 Minuten drinnen. Ging Problemlos. Vpn hingegen nicht, die hälfte der Server nicht erreichbar mit Warnung, dass protokolle getestet werden und das 1 bis 2 minuten dauern würde. Ging aber auch nach 10 min nicht und dann trennung. Hatte da an die 400 Server durch, brauchte immer eine neue Ip.

Also ging, zwei drei wechsel gingen, dann 10 nicht, dann wieder ein paar, etliche wieder nicht etc.

Und wie ist es mit Service und Erreichbarkeit? Wenn ich bei meiner Volksbank anrufe, dann habe ich einen Mitarbeiter aus der Filiale am Telefon. Probleme in der Regel binnen 2 bis 5 Minuten gelöst. Rufe ich bei meiner Direktbank an, dann habe ich ein Callcenter dran und einen Mitarbeiter, der keine Ahnung hat und erst an die Zentrale weiterleiten muss. Problemlösung meist 2 bis 7 Tage.

Geht hier problemlos. Norhin hatte aber NordVnp Probleme.

Habe es mit allen möglichen Dingen versucht, schon gestern Abend. Erst vernünftig mit einem Betrag -> Kreditkarte. Ok, wäre es PayPal gewesen, hätte ich was bezahlt. Kreditkarte hab ich nicht. Dann mit "nichts" -> Kreditkarte und mit 0 Eur ebenfalls Kreditkarte.

Und jetzt gerade, lässt er "nichts" gar nicht mehr zu. 0 geht noch und anderer Betrag. Dann kommt aber automatisch, wenn man 0 einträgt. Und danach wieder Kreditkarte.

Auch wenn ich eine 0 eintrage, will er eine Kreditkartennummer haben. Keine Ahnung wie es bei Dir ist, das kommt hier aber immer.

Nur mit Kreditkarte 😥

Das ist eine gute Frage. Mein "ist durchaus verbreitet" bezog sich auf CatCats Aussage "Roboto zählt auch zu den nicht wirklich verbreiteten Fonts". Deinem Post stimme ich völlig zu. sehe ich nämlich genauso. Würde die Seite nicht flackern, würde man den Unterschied nicht erkennen.

Ich selbst hatte ja früher viel mit Webfonts gearbeitet, also mit Fonts, die aussehen wie Tahoma, Arial oder Verdana, denn die Systemschriften waren zu unterschiedlich bei den Browsern. Da gab es aber auch noch nicht so viele Möglichkeiten mit CSS und Tabellen, die mit Windows optimal passten, waren mit iOS eine Katastrophe. Das hat sich ja alles geändert und die "neuen" Systemschriften ähneln sich sehr. Daher nutze ich auch seit zig Jahren keine Web-Fonts mehr, gibt einfach keinen Grund.

Ja, das geht. Local verwenden, wenn verfügbar, ansonsten laden. Das ist da in dem Template aber nicht integriert Da gibt es nur laden per src url() und wenn nicht möglich, dann Fallback auf Systemschrift. Was Du meinst und eben auch richtig wäre, wäre ein src local().

Bei dem ganzen Zeug verstehe ich die CMS nicht. Warum machen die überhaupt so einen Unfug? Schriften ok, das mag man noch verstehen, wobei auch nicht wirklich, aber mit den ganzen Symbolen? Das Dreieck da im ToTop kann man mit 5 Zeilen CSS-Code erstellen. Schaut fast identisch aus. Andere laden zig verschiedene Versionen der Font-Awesome-Schrift für unterschiedliche Dinge. Manche nur eine extra Version für das Icon vom Hamburger Menü? Oder ein Icon vom "Inhaltsverzeichnis", damit sich das dann dreht, wenn man es aufklappt. Das geht alles mit CSS pure.

Irgendwie habe ich das Gefühl, die ganzen Entwickler arbeiten nach dem Motto: Neues Template oder Addon oder Modul? Erst mal Schriften einbinden, ob ich die brauche egal, die müssen zuerst rein.

Irgendwie bauen die alle immer falsch rum auf. Das sollte so wenig sein wie möglich und dann erweitert, wenn benötigt. Auch CSS allgemein. Warum werden da teils 6000 bis 7000 CSS-Klassen ausgeliefert, wenn 98% davon auf der Webseite gar nicht benutzt werden? Geht das nicht modular? Also nur das zusammenbauen, was die Seite auch wirklich benutzt? Sollte ein CMS doch eigentlich können, ist ja schließlich selbst modular und weiß eigentlich, was wo benutzt wird.