Du müsstest es genau anders herum machen, nämlich deine Funktion vorher implementieren. Beispiel md5:
Ja, "ich" kann es so machen. Für mich hab ichs auch ersatzlos auf die hash()-Funktion umgeschrieben, weil die gibt es seit 5.1.2 und da der Rest wenigstens 7.4 braucht, scheint mir das kein Problem zu sein. Aber ich meine ja nicht meinen Code, sondern irgendwelche Erweiterungen, die in anderer Software zum Einsatz kommen und vielleicht (gut) gepflegt werden.
Hallo,
Ich hätte eine Frage: Wie ist das bei PHP mit den deprecate-Vorschlägen? Gibt es da irgendwie vorher eine Diskussion mit anderen Entwicklern in einem Slack oder vergleichbar oder schreibt derjenige seinen Vorschlag mitsamt den Überlegungen einfach in eine Datei und dann wird zu gegebener Zeit abgestimmt?
Ich habe vorher auch mit anderen Leuten darüber gesprochen, aber grundsätzlich läuft das bei dem Bulk-Deprecation RFC wie bei allen RFCs: Leute sind their own itch am scratchen. Beim Bulk-Deprecation-RFC sind einfach nur deshalb mehrere Sachen in einen RFC kombiniert, weil es die Diskussion auf der Liste und den eigentlichen Voting-Prozess vereinfacht. Jeder Eintrag ist „standalone“ und hat auch seinen eigenen Autor.
Da ihr ja auch md5 und sha1 auf der Abschussliste hattet, wäre es nicht auch irgendwie sinnvoll, wenn man PHP sagen könnte "ja ich weiß, dass Funktion whatever() deprecated ist, aber bitte wirf keine Warnung, weil buchstäblich eine Zeile tiefer implementiere ich meine Lösung, die du stattdessen verwendest, falls sie wirklich rausfällt"? Und die eigene Implementierung umklammert man mit einem if(!function_exists('whatever')) oder sowas?
Du kannst @md5() benutzen, um den Fehler zu unterdrücken, aber das sollte nur die Notlösung sein. Wenn Funktionalität deprecated ist, dann typischerweise, weil die latent kaputt ist oder weil es eine bessere Lösung gibt. Sachen werden auch erst dann deprecated, wenn es eine bessere Alternative gibt. In dem Fall von md5() kannst du einfach komplett auf hash() umstellen, ohne Fallunterscheidung. Im Falle von DOMDocument::$config kannst du einfach den Code entfernen (weil immer null), im Falle von dba_key_split(false) gilt „lass das“.
Die Formulierung „ihr habt“ ist übrigens so richtig präzise (weil siehe oben). Das ist ein „Tim hat“ und andere Leute stimmen zu (oder dagegen).
Oder bei einer solchen Deklaration automatisch die eigene Implementierung verwenden. Dann könnte die Implementierung in einem Debug-System meckern, und zwar auch schon, bevor die Funktion tatsächlich entfernt wird. Aber für den Endanwender bleibt das error-log vom Webserver "relevanter", weil man nicht von ner Million Deprecated-Meldungen erschlagen wird, wenn man eigentlich nen Parse-Error sucht.
Du kannst für Production einfach error_reporting=E_ALL&~E_DEPRECATED konfigurieren. Oder die E_DEPRECATED-Meldungen in eine andere Logdatei umleiten. Die Funktionalität ist schon da, sie muss nur benutzt werden.
weil die gibt es seit 5.1.2 und da der Rest wenigstens 7.4 braucht
Kleine Korrektur: Erst ab PHP 7.4 ist ext/hash garantiert verfügbar. Vorher konnte man das noch abschalten (bzw. musste es anschalten). Aber von Seiten PHP ist 7.4 eh EOL.
Hallo,
ich hab da gerade auch noch einmal auf der Mailingliste im Voting-Thread geantwortet und ich glaube diese Zitat meiner selbst fasst die Gesamtsituation gut zusammen:
Looking back at my own code, I'm seeing places where using SHA-1 is not
strictly insecure, but where a stronger hash function nevertheless would
have been more appropriate, if only to simplify code audits. I just used
sha1(), because it was temptingly convenient compared to hash('sha256', …).
Es werfe den ersten Stein, wer von sich selbst sagen kann, dass er jedes Mal wenn er sha1() schreibt darüber nachdenkt, ob nicht was anderes besser wäre 
OK, das ist interessant, mal so zu hören, wie es abläuft.
Die Formulierung „ihr habt“ ist übrigens so richtig präzise (weil siehe oben). Das ist ein „Tim hat“ und andere Leute stimmen zu (oder dagegen).
Ja gut, nun konnte ich den Inhalt deiner Antwort noch nicht kennen, bevor du sie abgeschickt hast, ne? ;–)
Du kannst @md5() benutzen, um den Fehler zu unterdrücken
Du kannst für Production einfach error_reporting=E_ALL&~E_DEPRECATED konfigurieren
Ja, "ich" kann das. Aber wenn Menschen angekrochen kommen mit so tollen Fehlerbeschreibungen wie "das geht nicht", dann könnte man sich zuweilen schon mal ein Log wünschen, das sich auf Wesentliches beschränkt. Also auch retrospektiv. Weil ist wie beim Auto: Auf der Straße klapperts, in der Werkstatt alles supi. 
Erst ab PHP 7.4 ist ext/hash garantiert verfügbar
Minor details. 
Aber von Seiten PHP ist 7.4 eh EOL.
Ja, aber.
(Aber: Ich werde nicht absichtlich irgendwas einbauen, das 8.x *braucht*, nur um künstlich die Systemanforderungen hochzuschrauben)
Wann WSC 6.1 Beta 1 
Bestimmt übermorgen.
Bestimmt zeitnah
Boomer so:
Als erstes steht die Alpha 1 auf woltlab.com auf der Liste. Diese war für Anfang der Woche geplant, aber daraus wurde auf Grund von Krankheit leider nichts. Nächste Woche ist auch noch eine Woche! 
Oh, super (der erste Teil)
Dann noch gute Besserung!
Wir sind hier im Smalltalk Thema
Smalltalk heißt, dass es hier nicht um WoltLab-Themen geht. Smalltalk heißt nicht, dass man in einer bestehenden Diskussion völlig am Thema vorbeireden und unsachlich werden muss. Und das wurdest du: „Deine Seite tut einem weh“ ist keine Art, wie man konstruktiv Feedback an seine Mitmenschen gibt, völlig unabhängig davon, in welchem Forenbereich wir uns befinden.
Es tut übrigens nicht weh, es einfach aufgrund der durchaus berechtigten Kritik mittig auszurichten:
Es ist nicht besser, nur weil es dir besser gefällt. Das ist jetzt kein Blog mit nur einer Handvoll Besuchern pro Tag, ganz im Gegenteil. Tatsächlich ist in das Design das Feedback von knapp 130 regelmäßigen Lesern eingeflossen, die damals an einer umfangreichen Befragung teilgenommen hatten. Und in den knapp neun Jahren (!) seit dem bist du die erste Person (!) überhaupt, die das als Feedback gibt. Nimm es mir nicht übel, wenn mich das nicht dazu veranlasst, diese Änderung vorzunehmen, auch wenn es „nicht weh tut“. Das heißt sicher nicht, dass es jeder so besser findet. Aber es ist nicht objektiv besser, es zu zentrieren. Für eine Änderung braucht es schon ein bisschen mehr als eine einzige Einzelmeinung in neun Jahren und das auch nur von jemandem mit einem ungewöhnlichen Monitor-Setup, wie es definitiv nicht repräsentativ für die Leser der Seite ist.
Wenn du weiteres Feedback hast mir das konstruktiv mitteilen möchtest, steht dir mein Postfach offen. In diesem Thema hatte ich jedenfalls nicht nach Feedback zum Design gefragt, vor allem da solche Design-Besprechungen in Richtung Projekt-Werbung gehen und das absolut nicht meine Absicht war. Ich wollte eine inhaltliche Antwort auf die geäußerten Bedenken eines Nutzers zu einem bestimmten Thema geben und ich kann natürlich schlecht meinen kompletten Artikel, der aus 3.000 Wörtern besteht, hier als Forenbeitrag einfügen. Da war der Link das einzige sinnvolle Mittel.
Als erstes steht die Alpha 1 auf woltlab.com auf der Liste. Diese war für Anfang der Woche geplant, aber daraus wurde auf Grund von Krankheit leider nichts. Nächste Woche ist auch noch eine Woche!
Ich dachte ihr wart auf Malle - Urlaub.
Gute Besserung! Werd schnell wieder fit, der Rest kann warten.
DO NOT TRUST
Vertrauen ist das eine, aber es spricht doch nichts dagegen, es dennoch mit auszuliefern, oder? ;–)
Es ist gut, dass ich meine Backups auf einem externen S3-Server speichere
Ich denke auch gerade drüber nach, meine Backups zusätzlich in einer Cloud zu speichern, aber wohin packt man ein 8 TB großes verschlüsseltes Archiv?
In eine Hetzner Storage Box. Also da habe ich zumindest mein NAS Offsite Backup, weil alle S3 kompatiblen Anbieter mir zu teuer waren
Backblaze
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
