Hm... habs deaktiviert und alles funktioniert. Alelsings nutze ich schon die neueste Version von Lightbox 0.7
Also dieses hier Lightbox2 Plugin for Wordpress @ [m] webdev:blog
Version 0.7a von morgen ![]()
Um schreiben oder kommentieren zu können, benötigen Sie ein Benutzerkonto.
Sie haben schon ein Benutzerkonto? Melden Sie sich hier an.
Jetzt anmeldenHier können Sie ein neues Benutzerkonto erstellen.
Neues Benutzerkonto erstellenHm... habs deaktiviert und alles funktioniert. Alelsings nutze ich schon die neueste Version von Lightbox 0.7
Also dieses hier Lightbox2 Plugin for Wordpress @ [m] webdev:blog
Version 0.7a von morgen ![]()
Schalt mal zum Test dein Lightbox Plugin aus (deaktivieren) und lade deine Seite neu (FireFox -> Shift + Reload).
Dann sollte der Kasten nicht mehr da sein. Es ist der nicht versteckte Tooltip deines Calendar Plugins, denn jQuery.js das vom Calendar benutzt wird kollidiert mit der veralteten prototype.js Version der Lightbox in zeigt einen Scriptfehler an.
Wenn das jQuery Tooltip Script laufen darf, dann ist auch der Kasten weg.
Wenn das so im Test korrekt ist, solltest du dir eine neuere (kompatible) Version des Lightbox Plugins besorgen.
[B]Warning[/B]: file_get_contents() [[URL="http://www.seo-party.de/function.file-get-contents"]function.file-get-contents[/URL]]:
URL [B][COLOR=Red]f[/COLOR][COLOR=Red]ile-access is disabled in the server configuration in
[/COLOR]/usr/www/users/privatw/seo-party.de/wp-content/plugins/events-calendar/ec_calendar.class.php[/B] on line [B]42[/B]
[B]Warning[/B]: file_get_contents([B][COLOR=Red]http://www.seo-party.de/wp-content/themes/cloudy/style.css[/COLOR][/B])
[[URL="http://www.seo-party.de/function.file-get-contents"]function.file-get-contents[/URL]]: failed to open stream: no suitable wrapper could be found in [B]/usr/www/users/privatw/seo-party.de/wp-content/plugins/events-calendar/ec_calendar.class.php[/B] on line [B]42[/B]
Dein Provider erlaubt nicht, dass du mit der PHP Funktion file_get_contents() auf eine Url losgehen kannst, um die Daten von dort einzulesen.
Entweder kann man das im Calendar Plugin auf den direkten Serverpfad konfigurieren irgendwo (weil das Plugin ein CSS einlesen will) oder du wirst nicht drumrum kommen, den Autor des Plugin zu fragen, ob das auch anders geht. Die 3. Möglichkeit, wäre den Provider zu "beschwatzen", aber da sehe ich nicht viele Chancen.
Hmm, das scheint am SpellChecker von Moxiecode zu liegen, den WP für Google requests nur benutzt:
Prüfungsergebnis:
{"id":null,"result":["WordPress","Spam","geh","Pluginbereich","aktivier","entspredchenden","Plugins","\u00c4ffchene","geschwafelt"],"error":null}
und Vorschläge:
Die verarbeiten intern die Codierungen nicht korrekt. Das kann ich jetzt so auf die Schnelle nicht machen, muß ich mir heute abend mal näher ansehen.
Hast du GoogleSpell aktiv oder umkonfiguriert auf einen anderen SpellChecker ?
Im Backend sagt der Quelltext aber auch:
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
Und "alles andere" in der Administration sieht ja auch soweit gut aus, nur diese Retschreibprüfung liefert Mist...
Was im head eine Seite steht verwendet der Browser nur dann, wenn der HTTP header keine Angaben mitgeschicht hat. Wenn die header Angabe des Servers was gegenteiliges meint, dann gilt für den Browser dieses.
Die 2. Möglichkeit ist, das dein Blog in einem Frame oder iframe läuft, weil die einen Hoster hast, der der so weiterleitet. Dann kann es sein, das ein Frame aussendrum ISO ist und die Spellchecker auf der Ebene des frame kommunizieren, was dann ISO Kodierung ist. Dies kann ich beides aber so nicht einschätzen, ohne den betreffenden Blog gesehen zu haben oder den Hoster zu kennen.
Hier gerade nur IE7, und der sagt Westeuropäisch-ISO...
Wenn ich das umstelle auf UTF-8, sieht alles ziemlich bescheuert aus- und am Ergebnis der Rechtschreibprüfung ändert sich auch nichts.
Ich hatte ja auch nichts von umstellen geschrieben.
Wichtig ist ja, das dein Backend offensichtlich in ISO Kodierung ausgeliefert wird statt in UTF-8. Deshalb hat mein o.g. Post auch seine Gültigkeit.
So ohne weitere Ansicht deines Blogs und dessen gesamte Konfiguration kann ich nicht sagen, was falsch eingestellt ist. Definitiv muß aber der Admin Bereich als UTF-8 laufen (und somit auch dein Frontend) sonst kommt immer irgendwelcher Müll raus.
Was sagt deine Browser zur Zeichenkodierung der Seite (FireFox unter Ansicht -> Zeichenkodierung) wenn du auf deiner Admin Edit Seite bist ?
Nein. Wie gesagt, übergroße Bilder auf Bildschrimgröße zu verkleinern ist eine Komfort-Funktion deines Browsers. Die kann der Anwender nur selbst umstellen. Im Firefox z.B. unter about:config bei unter der Eigenschaft "browser.enable_automatic_image_resizing". (wenn ich das jetzt richtig interpretiere, habs nicht ausprobiert)
Nur noch mal zum Nachlesen aus der FireFox 2.0 Beschreibung
: FAQ:Was ist beim Update auf Firefox 2.0 zu beachten? - FirefoxWiki
Da alle Javascript basierten Sachen ausschliesslich unicode ( UTF-8 ) benutzen, werden die Ergebnisse eines Spellchecker, die irgendwo abholt werden, in js Variablen abgelegt ( und somit UTF-8 ) und dann angezeigt.
Offensichtlich läuft aber dein Blog nicht auf UTF-8 sondern mit ISO-xxx weshalb das dann so aussehen muß.
Wenn du das korrekt haben möchtest, müsstest du dein komplettes Blog auf UTF-8 umstellen, was allerdings auch eine Menge Arbeit an bestehenden Texten in der DB bedeutet. Wie man das macht und welche Stolperfallen dabei sind, ist in mehreren Threads hier schon beschrieben worden.
Folgendes erfolgreich on the fly mit Firebug gestyled:
.mainmenu li a {
color:#FF3300;
display:inline;
font-weight:bold;
/* padding-left:20px; das raus*/
}
.mainmenu li {
display:block;
float:left;
padding-right:40px; /* neu*/
position:relative;
text-align:center; /* neu */
}
Alles anzeigen
und den letzten <li> dann direkt
<li style="float: right; text-align: right; padding-right: 0px;" class="page_item"><a href="http://www.esskultur.at/index.php/uber-esskulturat/" title="über esskultur.at">über esskultur.at</a></li>
Dann sieht das wie im Bild aus. Setzt voraus, dass du den letzten <li> auch addressieren kannst.
Also die Einstellungen sehen so aus:
// ** MySQL Einstellungen ** //
define('DB_NAME', 'dbxxxxxxxxx'); // Der Name der Datenbank, die du benutzt.
define('DB_USER', 'dboxxxxxxxxx'); // Dein MySQL-Datenbank-Benutzername.
define('DB_PASSWORD', 'xxxxxxxxxx'); // Dein MySQL-Passwort
define('DB_HOST', 'dbxxx.1und1.de:3306'); // 99% Chance, dass du hier nichts ändern musst.
define('DB_CHARSET', 'utf8');
define('DB_COLLATE', '');
wobei bei dir ja DB_NAME, DB_USER, DB_PASSWORD und DB_HOST von 1und1 mitgeteilt wurden und ersetzt werden müssen (also die ganzen xxx Teile).
Also ich hab auch einen 1und1 Blog und es ist definitiv nicht! localhost, denn die DB Server stehen woanders. Bei mir ist das ungefähr so: dbxxx.1und1.de:3306 (also noch eine Portnummer hinten dran)
Klingt nach dem "IE Guillotine" Bug denn ohne Link zur Seite kann man das nicht glasklar sagen. Schau dir dies aus dem YAML Forum mal an, ob das auf dich zutrifft: Tip: IE Guillotine Bug - Vermeidung
Es sind wieder ein paar kleine Nicklichkeiten mit ein paar Plugins aufgetreten, die ich gerade behebe (mehr als 200 gebräuchliche Plugins hab ich jetzt durchgetestet), Update kommt über's Wochenende.
(Es wird auch Zeit, dass ich das endlich mal ins SVN bekomme, wegen der automatischen Updates über WordPress, aber woher die Zeit nehmen ...)
Bei den Japanern ist das so eine Sache. Die "kochen" mehrere Suppen wenn es um Zeichensätze geht (Chinesen auch, eigentliche alle asiatischen Sprachen). Deswegen liegt da meist auch nur eine ja.mo rum, die dann mit x Zusätzen versehen wird.
Die nächste größere Version (nach dem Hotfix) sollte dann auch damit zurechtkommen können.
Also wpml-admin ist nun in Überarbeitung und Test, allerdings muss ich mir noch eine neuere Version von qtranslate installieren und testen.
Die fertige Version wird dann nicht mehr Beta sein und im Entwicklungsbereich zum Dowload bereitstehen.
Etwas Geduld bitte, ich muss erstmal Zeit kaufen gehen :mrgreen:
Da würde ich den Provider kontaktieren. Das hatte ich auch schon, da war die Verbindung zum DB Server gestört. Das passiert u.a. auch, wenn mehrere Leute massive Backups machen oder in die DB Daten pumpen bei Massenhostern, wenn du den Server nicht allein hast.
Da die initiale Seite bereits > 42000 Millisekunden braucht, sieht das nach einem massiven DB Problem aus, denn Bilder und Scripte kann man da erstmal ausschliessen.
Klar doch, im FireFox Shift + Reload, denn dein Cache zeigt noch das alte an.
Browsercache löschen hilft.