Beiträge von Putzlowitsch

  • Komprimierung aktivieren

    Zitat von Gerd-E.

    ...

    ganz unten ist es zu finden, gzip und deflate sind da.

    ...

    Wo ist ganz unten was da?
    Du meinst jetzt aber nicht das HTTP_ACCEPT_ENCODING-Feld, oder?
    Das ist nur aus dem Request-Header und teilt dem Sever mit, welche Encodings Dein Browser verarbeiten kann.

    Und das die geladenen Apache-Module nicht angezeigt werden liegt einfach daran, daß PHP als CGI/FastCGI und nicht als Modul läuft.

    Letztendlich kann hier wohl nur der Webhoster weiterhelfen.

    Gruß
    Ingo

  • Bestehende Website zu Wordpress umziehen

    Vielleicht noch ein kleiner Hinweis für den Umzug zu All-Inkl. Da gibt es bei den Tools im KAS einen Punkt "Account-Übertragung".

    Das sieht mir nach eine brauchbaren Lösung aus, um größere Datenmengen (z.B. viele Bilder) vom Server des bisherigen Hosters zu All-Inkl zu holen. Die Datenbank kann man so wohl auch übertragen, falls der alte Hoster externe Zugriffe auf die Datenbank erlaubt. Das geht bei 1&1 allerdings nicht.

    Ich habe es selbst noch nicht probiert, aber es wäre einen Versuch wert, würde ich sagen.

    Gruß
    Ingo

  • Problem in uploads mit verkorksten Umlauten

    Ja, das sieht gut aus. phpMyAdmin wir das entsptrechend der Kodierung in der Datenbank richtig ausgeben. Das es bei der anderen Tabelle (FTP-Daten) "unleserlich" ausgegeben wird, ist aber auch richtig. Wir wollten ja sehen, wie die Dateien tatsächlich auf dem auf dem Server abgelegt sind.

    Nur Piwik sollte sich auf eine einheitliche Darstellung/Kodierung festlegen, nicht mal so und mal so.

    Gruß
    Ingo

  • Logo nach der Holzhammermethode aufrufen

    Also Buchstaben in Groß-/Kleinschreibung, Ziffern und viele Sonderzeichen, wie z.B. der Klammeraffe (das @-Zeichen) stellen kein Problem dar. Diese Zeichen gehören zum ASCII-Zeichensatz und werden auf praktisch allen Systemen immer gleich codiert. Problematisch sind nur Zeichen, die eine spezielle Bedeutung im Umfeld der Benutzung haben.

    Bei den Umlauten ist es wichtig, daß diese immer in derselben Codierung verwendet werden. Also wenn die Datei als UTF-8 (das ist bei WP heute der Standard) hochgeladen wurden, müssen sie entsprechend codiert auch in Links verwendet werden. Wenn man das beachtet, sollten halbewegs moderne Betriebssysteme und Browser damit keine Probleme haben. Auch für die Suchmaschinen-Bots stellt das kein Problem dar.

    Gruß
    Ingo

  • Problem in uploads mit verkorksten Umlauten

    Zitat von Melewo

    Ist es das was man sieht, wenn man sich per FTP einloggt und die Verzeichnisse öffnet?
    Meine liegen in Verzeichnissen und nicht in Tabellen....

    Warum soll es denn keine FTP-Ansicht sein? Wenn da etwas mit Dateirechten steht, würde ich das schon annehmen. Die Tabelle ist ja nur eine Darstellungsform.

    Ich habe schon mehrere Dateien mit Umlauten per Wordpress hochgeladen und die waren auf dem Server immer als UTF-8 codiert. Warum soll das bei hydro anders sein? Alles andere würde gar nicht funktionieren und zudem zeigt Piwik das ja auch manchmal genau so an. Obwohl, daß ist auch eine Tabelle. Da könnne wir nicht wirklich wissen, wie die Daten letztendlich in der Datenbank abgelegt sind. :)

    Gruß
    Ingo

  • Schlecht gewälter Domainname

    Und besonders intessiert sich Google immer noch für Links, auch wenn sich da über die Jahre viel geändert hat und der Trend im Moment zum Linkabbau geht. Ab der follow-Link aus einen gut besuchten Forum ist durchaus noch was wert. Gute Links sind sogar soviel wert, das Leute mit dem Linkaufbau Geld verdienen.

    Wichtig ist nur, daß man beim Linkbuilding nicht mit der Tür ins Haus fällt, also einfach erstmal ein paar harmlose Artikel z.B. in einem Forum schreibt und dann erst im dritten oder siebten Beitrag den Link als Beispiel unterbringt. Außerdem ist Freitag Nachmittag oder Abend ein guter Zeitpunkt, um solche Forenlinks aufzubauen, weil sich am Wochende die Moderatoren nicht so sehr um das Forum kümmern und der Link so eine gute Chance hat, unentdeckt zu bleiben.

    Gruß
    Ingo

  • Problem in uploads mit verkorksten Umlauten

    Zitat von Melewo

    Weil es mir gerade noch einfällt. Schaue doch einmal nach, wie Deine Bilder auf dem Server im Upload-Verzeichnis abgespeichert werden...

    Wie es auf dem Server steht, hat hydro doch gleich ganz oben geschrieben (die erste Tabelle). Das ist mit zwei Zeichen als UTF8 kodiert. Für den Aufruf selbst muß es dann natürlich entsprechend URL-kodiert sein (mit %-Zeichen). Das funktioniert ja auch.

    Piwik muß halt nur einfach die UTF8-Codes richtig behandeln, dann klappts auch mit der Statistik.

    Sehr lustige Sachen kommen bei Umlauten übrigens bei 1&1-WebAnalytics raus. Da werden Strings einfach getrennt und ich wundere mich, mit was für komischen Suchanfragen die Leute meine Seiten finden :)
    http://schnurpsel.de/11-webanalytic…he-doerfer-884/

    Gruß
    Ingo

  • Bestehende Website zu Wordpress umziehen

    @alexandros

    Gut, der alte Smart L Tarif ist nicht wirklich für Wordpress geeignet, besonders wegen des geringen Speicherlimits von nur 30M. Den hatte ich auch mal, mittlerweile bin ich in den Basic-Tarif gewechselt. Da ist im übrigen eine Domain im Preis enthalten. So mußt Du nur zwei Zusatzdomains á 0,99 Euro bezahlen. Macht zusammen also knapp 9 Euro im Monat. Der nutzbare PHP-Speicher wäre dann übrigens ca. 55M. Ist zwar auch nicht die Welt, aber man kann damit auskommen.

    Die Gesamtbewertung dieser Speedtests setzt sich ja aus vielen Teilwerten zusammen. Insofern bedeutet ein schlechter Gesamtwert nicht unbedingt, daß der Webhoster schlecht ist. Man kann da auch viel selbst verbocken. Bei einer meiner Seiten hat mich z.B. das Verkleinern von Bildern per HTML bzw. CSS runtergerissen. Dafür kann ich ja schlecht den Webhoster verantwortlich machen.

    Wo wir schon bei allgemeinen Werten sind, der Blog von r23 hat im YSlow Grade genau wie Deine Seite nur 74% und damit eine C-Einstufung. :)

    Gruß
    Ingo

  • Riesen Problem ( durch Sprachdateien?)

    Genau das meine ich ja. Das Javascript kann bestenfalls überprüfen, welchen Statuscode das PHP-Skript zurückgibt. Deshalb wird dann einfach beim Statuscode ungleich 200 dieser allgemeine HTTP-Fehler angezeigt.

    Anders wäre es, wenn das PHP-Skript mit "200 OK" zurückkommt. Dann könnte man im JavaScript auch den Inhalt auswerten, wenn der vom PHP-Skript z.B. einfach als Plain-Text ausgegeben wird. Oder meinetwegen als JSON.

    Bei einem Speicherfehler bricht das PHP-Skript aber ab, bevor dieser eigentliche Status zurück gegeben wird und so kann das JavaScript den Fehler nicht präzisieren.

    Wie auch immer, das Problem des TE dürfte PHP-Speichermangel sein.

    Gruß
    Ingo

  • Riesen Problem ( durch Sprachdateien?)

    Melewo

    Ich verstehe jetzt nicht so ganz, oder besser gesagt gar nicht, was Du mir mit dem Beispiel sagen willst.

    Ich meinte eigentlich nur, daß ja das Upload-JavaScript das eigentliche PHP-Uploadskript aufruft und falls dieses, aus welchen Gründen auch immer, mit einem Statuscode ungleich 200 beendet wird, das einfach als HTTP-Fehler meldet. Mehr nicht.

    Gruß
    Ingo

  • Bestehende Website zu Wordpress umziehen

    Fakt ist, daß man bei 1&1 die PHP-Version konfigurieren kann, einschließlich PHP 5.4. und 5.5:
    http://goo.gl/8SoJrc
    Bei Neukunden ist PHP 5.4 die Standardeinstellung.

    Fakt ist auch, daß man bei 1&1 die Logfiles in Echtzeit im eigenen Webspace bereitgestellt bekommt. Sowas gibts noch nicht mal bei den weiter oben erwähnten Anbietern Host-Europe und All-Inkl. Da hat man erst ab Mitternacht des folgendes Tages darauf Zugriff (All-Inkl) oder muß sie kompliziert im Kundenmenü runterladen (Host-Europe).

    Aber das nur nebenbei. :)

    Warum sollte beim Shared Webhosting der Kunde eine Firewall bekommen? Die läuft auf dem Server im Hintergrund und gut ist, was hat der Kunde damit zu tun?

    Gruß
    Ingo

  • Riesen Problem ( durch Sprachdateien?)

    Ich vermute mal, daß das einfach ein allgemeine Fehlermeldung ist.

    Der Multi-Uploader läuft ja mittels JavaScript und ruft das eigentliche PHP-Upload-Skript im Hintergrund auf. Tritt nun so ein Speicherproblem auf, wird das PHP-Upload-Skript z.B. mit einem HTTP-500 Statuscode beendet, was das JavaScript dann einfach als HTTP-Fehler meldet.

    Oder anders gesagt, daß PHP-Upload-Skript kommt gar nicht mehr dazu, etwas Sinnvolles als Antwort an das JavaScript zurück zu geben, weil es bereits vorher wegen des Speichermangels abgebrochen wird.

    Diese Probleme hatte ich früher besonders bei 1&1, wo der Speicher mit ca. 30M ja lange Zeit sehr knapp bemessen war. Ich meine mich zu erinnern, daß da auch einfach ein HTTP-Error angezeigt wurden bzw. der Uploader gar nichts gemeldet hat und im Status "Wird verarbeitet..." stehen geblieben ist.

    Gruß
    Ingo

  • Riesen Problem ( durch Sprachdateien?)

    Da laut TE die Bilder ja hochgeladen werden, wird es wohl nichts mit dem Upload selbst zu tun haben.
    Es dürfte eher beim nachgeschalteten Erstellen der Thumbnails und Bilder in anderen Größen klemmen. Das hängt in der Regel mit dem PHP-Speicherlimit zusammen. Das deaktivieren von Plugins bzw. der Verzicht auf die deutschen Sprachdateien spart natürlich Speicher ein, so daß es dann wieder funktioniert.

    Apokh
    Wer ist denn Dein Webhoster und welches Hostingpaket hast Du dort?

    Gruß
    Ingo

  • Logo nach der Holzhammermethode aufrufen

    Zitat von SirEctor

    ...
    Sonderzeichen sind in Dateinamen nicht erlaubt. Am Besten Du gewöhnst Dir auch Kleinschreibung an, was Dateien angeht.

    Gibt es da ein Gesetz, welches die Verwendung von Sonderzeichen (und Großbuchstaben) verbietet und wenn ja, kann man das irgedwo nachlesen?

    Ich verwende gelegentlich Umlaute in den Dateinamen meiner Uploads und hatte damit noch keine Probleme. Wir haben 2014 und das Internet hat sich in den letzten 20 Jahren schon ein bißchen weiterentwickelt. :)

    Gruß
    Ingo