Wenn du hinter deine Blogadresse /wp-admin dranhängst, kannst du dich einloggen.
Beiträge von Fred Ataire
-
-
Die Themes entpackst du und lädst sie per FTP in den Theme-Ordner deines WordPress-Blogs.
-
Alles klar, das wars. Danke für die Bestätigung meines Verdachts!
Jetzt müsste ich bloß noch wissen, weshalb meine Sidebar nicht übernommen wird - aber die Lösung finde ich sicher in einem anderen Thread. ;-)
-
Ziehe mein Blog gerade mal probeweise auf einen neuen Webspace um.
(Klasse funktioniert hat übrigens die eingebaute Export/Import-Funktion: In meinem Blog auf altem Webspace stehen in der MySQL-Datenbank lauter Sonderzeichen statt Umlaute und scharfem S und so, werden im Browser aber komischerweise korrekt angezeigt. Nach Export und Import in den neuen Blog stehen in der neuen MySQL-Datenbank wieder korrekte Umlaute. Nur mal so als Tipp für zwischendurch für doppelt und dreifach kodierte Umlaute in der MySQL-Datebank, die sich auch durch Tools wie DUK von mysqldumper.de nicht reparieren lassen.)
Mein eigentliches Problem: Mein Theme lässt sich nicht aktivieren. Es handelt sich um eine von mir verschlimmbesserte Version des berühmten MistyLook-Themes in der vorletzten Version. Ich kriege zwar eine Preview des Themes angezeigt, aber nicht im schwarzen Rahmen mit der Option "Aktiviere Blabla" oben rechts sondern als Vollbild ohne Möglichkeit der Aktivierung. Wo könnte denn da der Hase im Pfeffer liegen? Ich habe irgendwo einen Framebreaker eingebaut (wenn ich bloss noch wüsste, wo...) - könnte das der Grund sein?
-
Vielen Dank für den Hinweis! Bin ich mittlerweile auch schon drauf gestoßen. Jetzt weiß ich zumindest, dass meine Umlaute doppelt und dreifach falsch kodiert sind und da im Grunde nichts mehr zu retten ist. Das Tool DUK vom MySQLDumper-Programmierer findet in meiner Sonderzeichen-Wüste nämlich keine falsch kodierten Umlaute.
-
Hallo,
das ist keine UTF Codierung.
Ich vermute, das kam von einer Übernahme, wie z.b von einem Serverwechsel resp. MSQL Import.
Darum wie Daniel vorgeschlagen hat, machst Du es zukünftig mit msqldumper, wirklich ein super Programm!
Moin, Ivan, das ist mir jetzt ein Stück weit zu hoch: Macht es einen Unterschied, ob ich die MySQL-Tabellen mit phpMyAdmin oder mit MySQLDumper ex- und importiere?Auslöser der ganzen Misere war vermutlich ein Ex- und Import über die entsprechenden Funktionen, die in WordPress eingebaut sind. Meine Frage ist jetzt, ob und wie ich das Unlaute-Kuddelmuddel gelöst kriege:
Mit MySQLDumper exportieren, in einem Texteditor die Sonderzeichen mit den entsprechenden Umlauten ersetzen und dann mit MySQLDumper wieder importieren? Das wäre ja fast zu einfach. :?
-
Okay, prima, danke für die Klarstellung!
Jetzt steh ich vor dem Rätsel, weshalb ein großer Teil meiner Umlaute in den SQL-Tabellen als Sonderzeichen abgelegt sind und im Browser trotzdem korrekt dargestellt werden, bei browserseitig eingestellter Zeichencodierung UTF-8.
-
Ich habe per phpMyAdmin mal die Tabellen wp_comments und wp_posts vom Server gezogen. Da tauchen bei mir Umlaute mal als Umlaute auf und mal als Sonderzeichen (ü = ü beispielsweise).
Egal, wer oder was das verursacht hat: Wie ist es denn grundsätzlich richtig? Sollten die MySQL-Tabellen die korrekten Umlaute enthalten oder die entsprechenden Sonderzeichen?
-
Kann ich leider nicht bestätigen, kriege die gleiche Fehlermeldung bezüglich Slideshow auch mit Version 1.0.2.
-
Das gleiche Problem habe ich auch.
Nachtrag:
Auch nach Downgrade auf die alte Version.
-
Das Auskommentieren der CHARSET- und COLLATE-Zeile in der wp-config.php hat das Problem bei mir gelöst. In der Zwischenzeit habe ich die beiden // wieder rausgenommen und bei COLLATE 'utf8' reingeschrieben - und jetzt funktionierts immer noch. Trotzdem schreibt Wordpress 2.7 alle Umlaute und scharfen S als Sonderzeichen in meine MySQL-Tabelle wp_comments. Ich weiß nicht, ob ich das CHARSET-Kuddelmuddel jemals gelöst kriege.
-
Mit dem All in One SEO Pack lassen sich zu jedem Artikel Keywords und Description hinzufügen.
-
Das Problem schien überhaupt erst aufzutreten, wenn man die Import- und Export-Funktion von WP benutzt hat...
Ja, das kein sein. Die hab ich leider auch mal benutzt. Auweia!
-
Wenn die Kommentare im Dashboard per Kommentar-Feed realisiert werden, wie "Neueste Entwürfe" und eigentlich fast das gesamte restliche Dashboard auch, dann schon. Fehler in der rss.php hatte ich heute auch ohne Ende, je nach Eintrag in der wp-config.php.
-
so hattest du es aber mal probiert?
Ich hab heute eigentlich alles probiert. ich glaube die ursprüngliche Variante erzeugte bei mir einen Fehler in der widgets.php.und noch was ... seit wann benutzt du Wordpress schon? Converting Database Character Sets WordPress Codex
Oh, das sieht nach jeder Menge Handarbeit aus. Aber danke für den Link, guck ich mir mal in Ruhe an. Ich wordpresse seit 2006, aber php und mySQL spreche ich immer noch nicht fließend. ;-) -
Sind die Fehler nur in den Feeds, die im Dashboard angezeigt werden ?
Wenn ja, dieser Fehler ist bereits seit einigen Versionen drin und wird mit 2.7.1 behoben werden (hoffe ich)
Danke für den Hinweis! Wenn einem ein falscher Fehler die Suche nach einem echten Fehler erschwert, lässt mans lieber bleiben. Warte ich also auf 2.7.1. -
Na unter "Neue Kommentare", z. B.
Von Stefan zu WordPress 2.7 ist da! #
Das Dashboard ist sehr gew�hnungsbed�rftig.
-
ich denke du meinst die wp-config.php?
Stimmt, genau die meine ich. :-)Stehen in der Datenbank die Umlaute richtig?
Nein, in der Datenbank stehen diese blöden Sonderzeichen: "Gruß" statt "Gruß"Welche WP-Version fährst du und welche Version hattest du vorher?
Ich hab von 2.6.5 auf 2.7 upgedatet.
Du könntest auch mal die o.g. Zeilen ganz auskommentieren.
Hab ich gemacht, jetzt habe ich die komischen Sonderzeichen im Dashboad.
Es ist zum Verzweifeln...
-
In meiner config.php steht:
define('DB_CHARSET', 'utf8');
define('DB_COLLATE', 'utf8');In phpMyAdmin steht zu jeder Tabelle unter Kollation "utf8_general_ci"
Trotzdem werden Umlaute in neuen Kommentaren als Sonderzeichen in die wp_comments eingetragen - warum?
-
Ich weiß nicht, ob ich mir damit irgendwas anderes kaputt gemacht habe, aber das Leeren der Tabelle wp_postmeta ist die Lösung für mein ursprüngliches Problem.
Nachtrag:
Nee, war nicht der Weisheit letzter Schluß, damit habe ich mir alle benutzerdefinierten Felder rausgeknallt. Also schnell mal wieder importiert die wp_postmeta. Werde also nur die tatsächlich überflüssigen Zeilen rauslöschen.
