Beiträge von codestyling

    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.

    Code
    [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:

    Code
    {"id":null,"result":["WordPress","Spam","geh","Pluginbereich","aktivier","entspredchenden","Plugins","\u00c4ffchene","geschwafelt"],"error":null}


    und Vorschläge:

    Code
    {"id":null,"result":["\u00c3\u0084ffchens","Afghane","Verkenne"],"error":null}

    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.

    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 :D - 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.

    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:

    und den letzten <li> dann direkt

    Code
    <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:

    Code
    // ** 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).

    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.

    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.

    Hier mal eines deiner Bilder benutzt / style.css ( line 478 ):

    Code
    #sidebar #searchsubmit {
    [COLOR=Red]background:transparent url(http://www.deniz-page.de/blog/images/icons/folder_go.png) no-repeat scroll 0%;
    [/COLOR][COLOR=Red]padding-left:16px;[/COLOR]
    }

    und style.css ( line 472 )

    Code
    #sidebar #searchform #s {
    padding:2px;
    width:[COLOR=Red][B]92[/B][/COLOR]px;
    }