Beiträge von KB19

  • Webhosting - PLESK-Backup wiederherstellen - Timeout beim Hochladen ...

    Über den externen Backupspeicher (FTP) würde es wahrscheinlich klappen, da gibt es dann nämlich sogar so einen Link: "In Serverspeicher kopieren"

    Also vielleicht könnte man da tricksen: Den Remote-FTP-Speicher in Plesk für irgendeinen Unterordner mit eigenen FTP-Zugangsdaten konfigurieren, die Datei dorthin hochladen und nachher schauen, ob sie in Plesk auftaucht. Das sollte klappen.

  • Das längste Thema

    whoami0501 Du hast den doppelten Pfad ja auch nochmals hardcoded in SCRIPT_NAME stehen?

    Allgemein ist Alias bei Nginx oftmals eine schlechte (weil verbuggte) Idee. Mit Symlinks arbeitet man da meistens viel bequemer. Beim Debuggen von Pfadangaben hilft es oft auch, einfach mal mit return/echo Statements und cURL zu arbeiten. Manchmal macht es dann schnell "klick" im Hirn.

  • Das längste Thema

    Irgendwie ein seltsames Gefühl, wenn man sich mal durch dieses Wikipedia-Diskussions-Archiv wühlt. ?(

    Egal ob das mehrheitlich Trolle sind oder ernst zu nehmende Fälle. Mir war nicht bewusst, dass man sich mit so etwas bei Wikipedia auseinandersetzen muss.

  • Das längste Thema

    Zitat von perryflynn

    Das ist ja bescheuert... Also werd ich den Nick hier noch nicht komplett los... :(

    Externer Inhalt youtube.com
    Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklären Sie sich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.

    *duckundwegrenn*

  • gzip via cronjob erzeugt leere Dateien - kein Fehler bei manueller Ausführung

    STDERR umleiten: 2> /path/to/file

    STDERR und STDOUT umleiten: &> /path/to/file

    Wie führst Du diese Befehle überhaupt aus? Stehen die in einem eigenen Script inkl. Shebang (z.B. /bin/bash) oder tippst Du die direkt ein? Letzteres könnte die Probleme als Cronjob nämlich durchaus erklären.

    Bei einem Bashscript könntest Du nach der Shebang auch mal so etwas einfügen, das zeigt gerne mal Fehler auf, die man sonst übersieht: set -euf -o pipefail

  • Das längste Thema

    Ich frage mich gerade, ob die Adressen unter a1.at vielleicht teilweise nur intern angeschrieben werden können. Das würde den Fehler eventuell erklären. Aber ich habe explizit diese Adresse bekommen und nichts von a1.net.

  • Das längste Thema

    Zitat von Hecke29

    Oder der "neuste" Schrei:

    Code
    $_GET['foobar'] = (string)$_GET['foobar'] ?? '';

    Stimmt, da war war. Danke für den Hinweis! Dein Beispiel erzeugt aber leider das:

    PHP Notice: Undefined variable/index: […]

    Entfernt man das (string), klappt es wie gewünscht. Als Workaround darfst Du nur das Ergebnis casten:

    $foobar = (string) ($foobar ?? '');

    So sieht es immer noch recht sauber aus und ist deutlich kürzer, als mein ursprüngliches Beispiel.

    Zitat von mainziman

    […]

    im Falle wenn Du statt '' wirklich NULL verwendest, ist es sogar sinnlos,

    denn wie Du ja sagtest GET/POST Arrayelemente sind garantiert Strings und unset bzw. das explizite setzen auf NULL

    machen bei isset keinen Unterschied =O

    Aktiviere mal Exceptions und erhöhe das Errorreporting. Ein Zugriff auf nicht existierende Variablen oder Arrayelemente ist Pfusch und mMn für noch viel mehr Bugs verantwortlich. Solche Fehler gehören keinesfalls unterdrückt. Dass isset() auch NULL als nicht gesetzt betrachtet, hat andere Gründe und damit genau genommen nichts zu tun.

    Aber immerhin sind wir uns durchaus einig, dass bei PHP einiges Murks ist. Dazu gibt es tatsächlich nichts mehr hinzuzufügen ^^

    Zitat von mainziman

    nebenbei: macht man das auch nicht; es würde auch keiner in C auf die Idee kommen argc bzw. argv zu ändern;

    Das war ein Beispiel. Ich gehe schon davon aus, dass man dort gleich eine Variable füllt. Hätte ich das nicht gemacht, kommst Du sonst wieder mit dem nachfolgenden Argument… ;)

    Zitat von mainziman

    weil dass ich nach dieser "Unprüfung" das $_GET["var"]  konsequent nirgends mehr verwendet wird,

    glaub'ich nicht, dazu kenn ich meine Pappenheimer nur zu gut;

  • Das längste Thema

    Ähm, ok… :/

    Code
    $ dig mx a1.at +short
10 a1-at.mail.protection.outlook.com.

    Dann halt nicht… ?(

    Code
    host a1-at.mail.protection.outlook.com[104.47.13.36] said: Recipient address rejected: Access denied. AS(201806281) [HE1EUR04FT028.eop-eur04.prod.protection.outlook.com]

    (Betrifft übrigens mal keine netcup IP.)

  • Das längste Thema

    Zitat von mainziman

    interessant ist der Fall in dem tatsächlich ausschließlich Ziffern in $_GET["var"] vorkommen;

    f. den Fall, dass hier PHP meint¹, dass dies ein Integer ist, passiert mit === eher ein Murx als was sinnvolles;

    Das passiert aber nicht, da die GET/POST Arrayelemente garantiert Strings oder ein Array aus Strings sind. Bzw. wären wir da genau bei jenem Punkt, den ich angesprochen habe: Explizit casten rettet einem manchmal den Arsch! :)

    $_GET['foobar'] = isset($_GET['foobar']) ? (string) $_GET['foobar'] : ''; // Wobei ich persönlich lieber NULL statt einem leeren String verwende.

    Die schwache Typisierung bei PHP ist Fluch und Segen zugleich. Ich persönlich sehe sie mittlerweile fast nur noch als großen Fehler. Denn letzten Endes wird es dadurch leichter, dass man gravierende Bugs einbaut. Aber PHP ist dennoch auf einem guten Weg, an vielen Stellen besser zu werden. Damit steigt allerdings die Einstiegshürde.

  • Das längste Thema

    Zitat von mainziman

    ich hoff ja doch dass preg_replace einen String und keinen Scheibenkleister als Rückgabe-Typ hat;^^

    Du hast das Problem mit der schwachen Typisierung bei PHP offenbar nicht verstanden.

    Nein, ich erkläre es Dir an dieser Stelle nicht. Dafür ist mir meine Zeit zu schade. Und JA, um es vorwegzunehmen, PHP ist manchmal so richtig grauslich. Wer auf Nummer sicher gehen will, arbeitet in PHP wenigstens annähernd typsicher, wobei an === und dem expliziten casten von Variablen (besonders Usereingaben in GET/POST, das könnten Arrays sein!) kein Weg vorbei führt.

    Wobei, wenn ich darüber nachdenken, passt Dein Code eh so richtig ins typische PHP-Konzept. :D