Beiträge von Hecke29

    Das sollte eigentlich mit dem WP-Installtool automatisch gemacht werden. Seltsam ist ja, dass das Tool sagt, dass schon eine Config vorhanden ist, obwohl du meintest die Stammverzeichnisse bereits separiert zu haben.

    Ich würde mal das Stammverzeichnis der zweiten Domain leeren und das Ganze dann nochmal versuchen.

    Ja zu finden ist halt nichts.

    Ich bin mir zwar sicher, dass es berücksichtigt wurde, aber der guten Ordnung halber möchte ich erwähnen, dass Kernel-Meldungen bei Debian standardmäßig, sofern ich mich richtig entsinne, in /var/log/kern.log landen. Dort habe ich auch schon einmal "last hope"-Meldungen/Infos zu Kernel-Panics gefunden.


    Auch könnte /var/log/debug vielleicht hilfreich sein.


    Einen schönen Start euch allen in das neue Jahr 2018.

    Man kann eigentlich alle Coins, die aktuell eine relevante Marktkapitalisierung aufweisen, gar nicht oder bestenfalls sehr, sehr unwahrscheinlich per CPU minen.

    Von daher stellt sich die Frage nach der Wirtschaftlichkeit in der Regel gar nicht...


    Bei Bitcoin und Etherium weiß ich, dass CPU-Mining in der Praxis unmöglich ist.


    Du kannst natürlich anfangen "Sparten"-Coins per CPU zu minen und hoffen, dass die mal was Wert werden; aber da ist dann die Rentabilität nicht messbar.

    Aus nachvollziehbaren Sicherheitsgründen ist ein Zugriff auf die Backups eingehend per FTP nicht möglich.
    Standardmäßig speichert Plesk die Backups auf dem Server irgendwo unter unter /var/lib/psa/dumps o.ä. ab, worauf man wahrscheinlich per Webhosting-SSH-Zugang keinen Zugriff haben dürfte.


    Jetzt weiß ich nicht, ob es vielleicht über die Plesk-API möglich ist ein Backup herunterzuladen (immerhin kann man es ja im Panel selbst downloaden). Das wäre meiner Einschätzung nach der einzige Weg ein Backup "abzuholen" ohne Serverzugriff zu haben.

    Das Fehlerbild ist seltsam...


    Also. Was ja von der Anwendung richtig wäre, wäre zum UTC-Timestamp des Termins (Datum um 0 Uhr GMT) -1800 Sekunden zu addieren (negative Zahl dazu addieren = Subtraktion). Dann hat man 23:30 GMT und 00:30 GMT+1.

    Aber scheinbar schlägt das (auf dem netcup-Hosting) fehl, wenn die zu addierende Zahl negativ ist.


    Welche PHP-Version nutzt du?

    Probiert ihr hier mal weiter rum, ich durchsuche mal den Quellcode :D

    Hallo Hecke29,


    das hört sich gefährlich an. Kann du das auch in Altdeutsch übersetzten, ich gehöre zur Generation von Konrad Zuse. ;) Ist wie gesagt alles Standard Contao 4.4.

    Moin,


    das ist eine nur lesende Aktion, die anzeigt wie die Tabelle definiert ist. Ich wollte herausfinden von welchem Datentyp die Spalte startTime ist. Scheint aber ein unsigned int zu sein.

    Ich habe dann den Timestamp für 00:30 (UTC+1) direkt in die Datenbank eingegeben.

    Werden Termine, die du über Contao einstellst (z.B: um 03:00 Uhr GMT+1) nach dem Speichern in Contao für die richtige Zeit angezeigt (Datum + Uhrzeit) und was steht bei startTime für den neuen Termin dann in der Datenbank? Ein UNIX-Timestamp für den Tag 02 Uhr (GMT)?

    Das wird mit dem WCP vermutlich nicht möglich sein, da für die automatische Validierung der Domaininhaberschaft (das was bei Ausstellung eines SSL-Zertifikats passiert) die DNS-Einträge der Domain schon auf das neue Webhosting zeigen müssten (also die Domain schon umgezogen sein müsste...)


    Die technische Möglichkeit wäre (weiß aber nicht ob das im WCP geht) das SSL-Zertifikat (und private Key?) herunterzuladen und im neuen Webhosting hochzuladen...

    Da ich nicht weiß wie technisch bewandert du bist:

    Die Fehlermeldung kommt von der Datenbank und sagt aus, dass der Wert -1800 nicht gespeichert werden kann, weil er außerhalb der zugelassenen Werte liegt.

    Wenn du weißt wie du einen SQL-Query auf deine Datenbank feuerst, zeig uns mal bitte den Output von DESCRIBE tl_calendar_events;

    Wahrscheinlich ist das Feld unsigned.


    Was aber viel wahrscheinlicher die Ursache ist, ist dass hier programmatisch gepfuscht wurde. 1800 sind nämlich zufällig 30 Minuten in Sekunden. Vermutlich errechnet die Software welche Uhrzeit in UTC die Uhrzeit 00:30 Uhr von Berlin (derzeit UTC+1) ist. Das ist nämlich 23:30 Uhr vom Vortag und zufälligerweise sind das genau -1800 Sekunden Differenz bis 0 Uhr des ausgewählten Tages.

    Damit kann die Software wohl nicht umgehen. Sie müsste jetzt ja nicht -1800 speichern, sondern den vorherigen Tag auswählen und dort (86400-1800=84600) eintragen (das wäre 23:30 Uhr). Dein Termin findet in UTC nämlich um 23:30 Uhr am Vortag statt.


    Ich weiß das hilft dir nur bedingt weiter... Aber mit der Fehleranalyse kannst du das Problem entweder selber im Quellcode fixen oder musst dich an den Hersteller der Software wenden.