Hallo Milo

Die Diskussion führen wir besser in unserer Muttersprache, damit wir nicht allzusehr Gefahr laufen, uns misszuverstehen.

Du bleibst in der Funktion und führst selbst beim erfolgreichen Auslesen der externen Ressource mit einer Methode, die nicht als Letzte notiert ist, den Rest der Funktion mit den restlichen Methoden aus und überschreibst dabei die bereits ermittelten Werte.

Nein, dies passiert nicht, da mit empty($content) geprüft wird, ob dies notwendig ist; beachte empty(false) liefert true.

Ich habe mir nochmal den Code, in dem Status, in dem er war, als ich ihn kommentierte, angeschaut. Dabei habe ich auch meinen Denkfehler erkannt. Ich beschreibe mal, wie ich den Code nun verstehe. Anmerkungen sind als Kommentare notiert. Ich beginne nach der Deklarierung der Funktion. Wir sind also schon drinnen.

// Initialisierung der Variable mit dem Standardwert FALSE
$content = false;
// Abarbeitung des curl-Zweiges
if (function_exists('curl_init')) {
    // ...
    // Wenn in curl ein Fehler aufgetreten ist, setze $content explizit auf FALSE
    if(curl_errno($ch)) 
        $content = false;
    }
// Nächster Schritt: file_get_contents, Prüfung auf den Wert von $content mit empty().
// Die Prüfung schließt FALSE mit ein, ist mMn aber nicht sehr intuitiv.
// Dieses Rückgabewerts von empty war ich mir auch nicht bewusst, daher mein gestriger Einwurf.
 
// Sollte der von ini_get zurückgegebene Wert nicht gegen einen Vorgabewert geprüft werden?
// Laut Doku werden boolesche Werte von ini_get folgend zurückgegeben. on = 1, off = 0 oder '' [1]
if (empty($content) && @file_get_contents(__FILE__) && ini_get('allow_url_fopen')) {
    $content = @file_get_contents($url);
    // $content enthält nun einen String oder FALSE
    }
// Nächster Schritt: fsockopen
// Wiederum erfolgt die Prüfung mit empty
if (empty($content)) {
    // ...
    // Ist die folgende Vermischung der Notationen in Bezug auf die Lesbarkeit des Codes sinnvoll?
    if (!$fp)
        // Setze $content im Fehlerfall explizit auf FALSE
        $content = false;
    else {
        // ...
    }
// Gib, wenn $content leer oder FALSE ist, FALSE zurück, sonst den Inhalt von $content
if (empty($content))
    return false;
return $content;

Mein Denkfehler war also die Unkenntnis der Tatsache, dass FALSE in der Funktion empty als leerer Wert einer Variable gilt. Daher ist mein Vorschlag, jeweils an den Enden der Methodenblöcke die Funktion mit return $content; zu verlassen, natürlich hinfällig. Dass das sowieso nur nach dem erfolgreichen laden der Daten erfolgen sollte, sei mal dahingestellt. Das würde zwar funktional das gleiche Ergebnis wie deine Lösung erzielen, aber um einiges umständlicher sein.

Ich habe es nun nach Deinen Vorschlag erweitert und überall ein return hinzugefügt.

Wie gesagt, mein Blödsinn.

In meiner Variante konnte, wenn bspw. curl zwar vorhanden ist aber aus irgendeinem Grund nicht geht, der nächste Zweig noch herhalten, dass geht jetzt nicht mehr.

Eine Prüfung auf Erfolg hätte vorher aber schon stattgefunden haben sollen.

Ich weiß nicht, wie das, gerade bei den beiden SQL-Dateien gemacht werden könnte.

Mit einer Datei: version.txt, wo die Version drin steht. Schließlich arbeitet die aktuelle Version ja auch mit $line = str_replace(' mlf2_', ' '.$_POST['table_prefix'], $line);. Warum also nicht noch einen Platzhalter nutzen für die aktuelle Release-Version?

Stimmt, eine Datei namens VERSION oder RELEASE, die neben README.md, LICENSE und CHANGELOG steht, macht den Kohl auch nicht mehr fett.

das uns beim erstellen eines Releases als Checkliste dienen soll.

Sehr gute Idee. Ich weiß ja noch nicht, wie Du die Releases baust. Macht das Git allein oder machst Du das klassisch von Hand?

Neenee, das passiert schon von Hand. Einen Release schnürt wohl kein Versionssystem von sich aus. Nicht bei Skripten und nicht bei Kompilaten.

Tschö, Auge

[1] siehe Doku ini_get, Anmerkungen