Beiträge von flotte

  • Seite erstellen DSGVO-Konform, hosten über jur. Pers im Ausland - Sinn/Unsinn?

    Zitat

    in der Regel darf man in einer Wohnung kein Gewerbe betreiben. Weder in der berüchtigten Garage noch bei der Mutter in der Küche.


    Also so kann man das nicht sagen. Da muss man schon viel konkreter werden und nach den Details schauen. Als Websitebetreiber (und darum geht es hier ja) nutzt Du i.d.R. einen Schreibtisch und einen PC mit Internetanschluss. Diese Art der gewerblicher Tätigkeit hat normalerweise keine Außenwirkung, nimmt wenig Platz in einer Wohnung ein und kann so gut wie immer problemlos erfolgen. Auch eine Zustimmung des Vermieters, falls es eine Mietwohnung ist, kann in den meisten Fällen problemlos eingefordert werden. Das nur dazu...

    Den rechtlichen Rahmen einer privaten Website richtig und rechtsicher abzustecken sollte eigentlich kein großes Problem sein. Da gibt es doch massenhaft Vorlagen, Beispiele, Tutorials etc.pp. Und ja, das Impressum mit Adressangabe muss nun mal sein. Bei gewerblichen Seiten ist es natürlich komplexer, aber auch das ist stark abhängig vom Inhalt der Seite, bzw. den zugrunde liegenden Gewerbe. Auf gar keinen Fall kann man das hier auch nur ansatzweise beantworten - zu viele Faktoren. abhändig vom Geschäft- spielen da rein. Und eine konkrete Rechtsberatung ist hier nicht erlaubt.

    Wenn tatsächlich über die Verlegung des Wohnsitzes oder des Betriebsstäte ins Ausland nachgedacht wird, dann wird es dem Opener wohl nicht nur um eine simple kleine Website gehen :-)

  • Problem beim Hochladen einer PDF-Datei mit 23 MB

    Zitat von Kurt Singer

    Links sind das Web. Ohne Links kann das Web ja nicht existieren. Was also ist der Sinn dahinter, der sich mir nicht erschließt?


    Ich hatte nur erklärt was es ist. Das war ja die Frage.

    Der Sinn ist eine ganz andere Frage. Darüber kann man sicher streiten. Es gibt sicher Szenarien, wo das sinnvoll ist - z.B. auch bei anderen Dateitypen (z.B. PDF). Wenn man bespielsweise Bildrechte gekauft hat und sicher gehen will, das die eigenen Links zu den Bildern nur auf der eigenen Seiten angezeigt werden können. Wie gesagt schützt das nicht vor Screenshots oder Downloads, aber die direkte Verbindung zur eigenen Seite wird eben blockiert. Das kann durchaus rechtlich von Bedeutung sein. Das muss jeder selbst entscheiden.

  • gzip compression automatisch ?

    Der Link mit der Seite wo es nicht klappt wäre intertessanter.
    Die angegeben Seite lädt bei mir in ca. 2 sec. Das ist OK. Ich denke nicht das sich dein Ranking signifiknat ändert, wenn sich dies ein paar Millisekunden ändert. Auch eine https-Verbindung würde das Ranking (theoretisch) verbessern auch wenn das auf so einen Seite witzlos ist, aber die Ladezeit immer spürbar verlängern. Tja...
    Der wichtigste Aspekt für ein gutes Ranking ist nach wie vor guter platzierter Content, Content, Content und eine gute (echte) Vernetzung im Netz. Finger weg von gekauften Backlinks oder "Besuchergeneratoren".

  • gzip compression automatisch ?

    Ich vermute der Server komprimiert automatisch. Das wäre auf jeden Fall die Methode die vorzuziehen ist, statt auf PHP-Ebene.
    Es ist denkbar das einige Dateiendungen aus Kompatibilitätsgründen ausgeschlossen werden. Ist oft bei .js-Dateien sinnvoll. Möglicherweise stört sich Google dran. Aber man muss die Google-Tests auch nicht immer als das maß aller Dinge interpretieren.
    Zeig doch mal die Seite, damit man mal eine subjektive Bewertung des Speeds machen kann. Das geht mit den Entwicklertools in den Browsers doch wunderbar. Dort kannst Du auch erkennen, welche Objekte komprimiert geladen werden.

  • Wordpress ist seit 2, 3 Tagen langsam und bringt HTTP500 Fehler

    Datenbank mir 420 MB sind kein Problem.
    Ist der MYSQL-Server auf Deinem Host oder extern?
    Was zeigen die Logs?
    Webserver: Hat sich an den Zugriffen auf das Web etwas geändert? Oft laufen Bruteforce-Attacken auf das Login.
    Kernel.log: Auffälligkeiten?
    Was zeigt der Netzwerktraffic? Gibt es Angriffe?
    Ist Dein Wordpress das einzigste Web? Vielleicht kommt die Last ganz woanders her?

    Ursachen für hohen Load gibt es vieles. Offenbar hast Du aber einen eigenen root-Server. Das sollte vorraussetzen, das die zumindestens mit den üblichen Analysetools und Logs umgehen können solltest.

    Viele Hoster mit Billig-root-Servern bieten haben oft nur Desktop-Hardware, inbesondere bei Festplatten und bei der CPU. Dann ist schnell Schluss mit guter Performance wenn man etwas massiver zugegriffen wird.

  • Umlaut Problem - Ausgabe Datenbank

    Unter Umständen nur schwer lösbar, wie bereits gesagt. Es gibt kein Patentrezept.
    Du musst das Problem einkreisen. Ist die Ausgabe der Seite überall in uft8 oder anders?
    Prüfe alle Dateien die editiert wurde, ob diese noch in utf8 codiert sind (nutze Editoren wie Notpad++, keinesfalls den Windows-Default-Notpad)
    Betrifft das nur die Permalinks? Wenn ja, was passiert wenn die manuell angepasst werden, usw....
    Vorsicht von wilden Umcodierungsaktionen von Massendaten. Möglicherweise ist das bereits geschehen, weil Du schon einige Anleitungen befolgt hast.
    Auf dem Testserver sollte aber noch alles "original" sein. Ich würde daher mit dem Testserver weiterarbeiten und versuchen dort das Problem einzukreisen.

  • Duplikation von einer WP-Installation

    Du kannst auch ein WordPress ganz "traditionell" umziehen und ein kleines Zusatzscript nutzen, welches dann die Domain in der Datenbank ändert.
    Vorteil ist, das kein zusätzliches Plugin installiert/deinstalliert werden muss und das ganze ggf. etwas kontrollierter abläuft. Das kleine Bereinigungsscript wird nach dem Datenumzug von Dateien und MySQL-Dump und der Anpassung der wp-config.php auf einfach den neuen Server kopiert und einmal ausgeführt, dann gelöscht.
    Grundsätzliche Vorgehensweise kann man hier nachlesen.

  • Cache

    für eine gute Performance ist die Grundvorraussetzung erst einmal ein schneller nicht überbuchter Server - mit sehr schneller Datenbankanbindung. Eine serverseitige Komprimierung woe mod_deflate ist auch sehr zu empfehlen und ebenso bereits serverseitig vorhandene Cache-Funktionen (OP-Cache).
    Inwieweit dann noch ein auf PHP basierte Cache-Technik weitere Vorteile bringen kann, ist pauschal nicht zu beantworten. Das hängt vom Server und dem Umfang des WordPress und dem Traffic auf der Website ab. Es gibt durchaus das Szenario das ein solcher Cache genau das Gegenteil bewirkt, weil dafür ja auch CPU-Rescoucen benötigt werden, weil u.U. extrem viele Cache-Dateien gemanaged werden müssen, weil das php-memory-Limit nicht reicht, weil doppelte Komprimierung kontraproduktiv ist usw. usf.

  • Umlaut Problem - Ausgabe Datenbank

    Ist die erneute Übernahme der Seite vom Testserver zum Produktivserver noch möglich? Funktioniert alles auf dem Testserver wirklich einwandfrei?

    Ich frage deshalb, weil sich solche Problem unter Umständen nur sehr schwer lösen lassen -wenn erst einmal ein Gemisch unterschiedlicher Codierungen entstanden ist.

    Falls eine erneute Übernahme möglich ist, liegt die Ursache des Problems vermutlich bei unterschiedlichen MySQL-Versionen - ganz eventuell auch den PHP- oder Webservereinstellungen oder Dateien die im Zuge des Umzuges editiert wurden.

  • Datenbank Backup

    Ja mysqldumper ist ein gutes Tool. Hier geht es aber nur um das einmalige Einlesen eines Dumps, da würde ich nun nicht direkt ein neues Script installieren /solsche Tools muss man gut schützen, updaten oder wieder entfernen. Einfach auf dem alten Server nicht die ganze DB exportieren, sondern den Dump unterteilen in einzelne Tabellengruppen und jeweils entsprechend kleinere Dumps erzeugen... Sollte doch nur ein Aufwand weniger Minuten sein.

  • Server Hack Problem

    Das Umziehen der Seite auf einen neuen Server sorgt nur dafür das der dorige Account auch gehackt wird und Du ggf. sogar anderes gefährdest. Das ist grob fahrlässig.
    Im Fall eines Hacks muss Du SOFORT den Zugriff auf die Seite sperren (.htaccess-Passwortschutz und FTP etc. entfernen ggf. neu setzen).
    Dann mit Hilfe der Logs und den (hoffentlich noch unveränderten Dateien/Datumsstempeln) den Hack untersuchen. Das ist nicht so trivial und erfordert Übung und einige gute Hilfsmitteln, um Logs und Dateien sinnvoll zu durchforsten. Such Dir einen Dienstleister der das macht, wenn Du hier unsicher bist - du wirst den Hack sonst nicht los.
    Wenn der Hack ermittelt wurde und auch der konkrete Zeitpunkt feststeht, kann man schauen welches Deiner Backups passt und dieses nutzen - dann Lücke schließen.
    Gibt es keine Langzeitbackup, also kein Backup zeitlich vor dem Hack, wird es deutlich schwerer, denn in jeder einzelnen Datei können Backdoors sein. Fast unmöglich dies wirklich sauber zu bereinigen.

  • Datenbank Backup

    Wenn die Dumpdatei zu groß ist dann splitte sie mit einem Editor auf und importieren blockweise. Sieh Dir den Dump genau an splitte an pasender Stelle, nicht mitten in einem Statement. Nutze aber einen uft8-fähigen Editir wie Notpad++, nicht den Standard-Notpad des Windows!
    Alternativ den Dump bei der Erzeugung schon kleiner machen. ALso blockweise die Tabellen dumpen.