Warum ist Deserialize in einer anderen Deserialize-Funktion im WordPress-Kern verschachtelt?

Lesezeit: 2 Minuten

Ich habe den WordPress-Kern durchsucht und diese Funktion gefunden:

function unserialize ( $data ) {
    return unserialize( $data );
}

Zunächst einmal verstehe ich nicht einmal, warum Deserialize definiert wurde, da es sich um eine native PHP-Funktion handelt. Zweitens, was in aller Welt geht hier vor, da es rekursiv definiert ist, ohne dass eine Bedingung zum Stoppen der unendlichen Rekursion besteht?

Wirf mir einen Knochen. Ich bin Neuling in diesem Zeug.

  • Ist diese Funktion innerhalb einer Klasse oder eigenständig?

    – Mike Brant

    4. Oktober 2012 um 16:55 Uhr

  • Das muss eine Methodendefinition in einer Klasse sein.

    – NullUserException

    4. Oktober 2012 um 16:55 Uhr


  • Mein Standard-Snarky-Kommentar ist, dass Sie nicht hinterfragen sollten, wie Wordperss funktioniert. Auf dieser Straße liegt der Wahnsinn.

    – Markus B

    4. Oktober 2012 um 16:56 Uhr

  • Meine Vermutung ist, dass die Methode das Ergebnis der nativen PHP-Funktion zurückgeben würde, anstatt sich selbst rekursiv aufzurufen

    – AlexP

    4. Oktober 2012 um 16:58 Uhr


Benutzer-Avatar
NullUserException

Das muss die Methodendefinition in einer Klasse sein, zB:

class SomeClass
{
    function unserialize($data) 
    { 
        return unserialize($data);
    }

    // ...
}

Andernfalls erhalten Sie einen schwerwiegenden Fehler, der besagt, dass Sie keine Neudeklaration durchführen können unserialize().

Alles, was es tut, ist ein hinzuzufügen unserialize() Methode zu einer Klasse. Diese Methode ruft dann die native unserialize() Funktion in PHP. Scheint ziemlich albern, aber andererseits habe ich nicht WordPress geschrieben.


Ich glaube, ich habe die fragliche Methode gefunden: wp-includes/rss.php (Zeile 783). Und es ist in der Tat eine Methode der RSSCache Klasse.

Ich nehme an, es ist möglich, dass sie in Zukunft ihre eigene Serialisierungsroutine und/oder eine Unterklasse von schreiben möchten RSSCache hat sein eigenes serialize() und unserialize().

  • Der Plan für eine zukünftige benutzerdefinierte Serialisierung ist wahrscheinlich das wahrscheinlichste Szenario. Es ist laut Trac seit dem 19. Dezember 2004 dort und war in der ursprünglichen Hinzufügung der Datei enthalten. (Wieder laut Trac) Die Begründung könnte im Sand der Zeit verloren gehen.

    – EPB

    4. Oktober 2012 um 18:10 Uhr


  • Danke Leute. Diejenigen von Ihnen, die die Klassendefinition erraten haben, hatten Recht. Ich habe es nicht bemerkt, aber es gibt den Beginn einer Klassendefinition mehrere Zeilen oberhalb des Funktionscodes für die Deserialisierung. Dies ist also eine Klassenmethode, die zum Aufrufen der nativen Funktion verwendet wird. Vielen Dank!

    – JamesHoux

    4. Oktober 2012 um 18:13 Uhr

NullUserException hat es richtig. Soweit eine Erklärung geht, hier ist mein bester Schuss.

Nehmen wir zum Beispiel an, eines Tages beschließt PHP, die Deserialize-Funktion abzulehnen. Plötzlich müssen Sie überall, wo Sie “unserialize()” in Ihrem Code finden, einen neuen Funktionsnamen ändern und möglicherweise etwas umschreiben. Wenn Sie jedoch eine eigene Funktion verwenden, wie es WordPress tut, müssen Sie nur einmal Ihre Version der Deserialize-Funktion ändern und nicht überall, wo sie verwendet wird.

  • Also haben sie alle nativen PHP-Funktionen umgeschrieben? 🙂

    – Tarek

    4. Oktober 2012 um 17:03 Uhr

  • Sie müssen auch alle anderen PHP-Funktionen vergessen haben!

    – AlexP

    4. Oktober 2012 um 17:03 Uhr

1250920cookie-checkWarum ist Deserialize in einer anderen Deserialize-Funktion im WordPress-Kern verschachtelt?

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy