Beiträge von codestyling

    Als Laie frage ich mich natürlich, wie Du das mit dem Google Sitemap Generator raus gekriegt hast...:-D. In der sitemap.xml steht doch die Versionsnummer nicht drinne, oder?


    Da stimmte was in der Stylesheetangabe nicht, weshalb die Sitemap auch nicht per Stylesheet im Browser angezeigt wird:

    Code
    ....../plugins/sitemap.xsl

    Allerdings meint deine sitemap in der Tat, neuer zu sein: sitemap-generator-version="3.1.0.1".
    Müsste eigentlich so aussehen, war mal ein Bug zwischenzeitlich:

    Code
    ....../plugins/google-sitemap-generator/sitemap.xsl

    Da du eine ältere Version des Google Sitemap Generator Plugins installiert hast :), nehme ich an, dass dieses nun beim Bearbeiten von Posts/Pages oder Kommentaren die Datei baut und damit viel zu lange braucht bzw. die DB nicht mehr zu macht. Dann produziert es natürlich "ohne" Änderungen deinerseits jetzt erst Probleme, weil die Anzahl deinen Posts/Pages ja erst langsam angewachsen ist.
    Könnte auch noch andere Ursachen haben, nur fällt mir das spontan dazu ein.

    Code
    [Fri Aug 22 08:54:55 2008] [warn] mod_fcgid: stderr: ALERT - [COLOR=Red]configured fileupload limit exceeded - file dropped[/COLOR] (attacker '83.221.242.210', file '/wp-admin/admin.php')

    Die IP ist aus dem envia Netz Dresden, also gehe ich davon aus, das du einen Upload gemacht hasts. Wie die Warnung bereits aussagt, beschränkt dein Provider deine Upload Möglichkeiten. Wie ebenfalls zu sehen, wurden ein paar Dateien nicht übertragen und weggeworfen (dropped).

    Wenn ich mich richtig erinnere, hat der Provider ein 1MB Upload Limit. Wenn du 20 Bilder a 78 kb = 2* 780 kb > 1MB ! hochladen willst, wird das nicht funktionieren. Bitte bedenke diese Limitierung beim Upload.

    Das liegt daran, das im Frontend die Thickbox direkt vom Plugin selbst ausgeliefert wird:

    Code
    http://wp1117349.wp153.webpack.hosteurope.de/wp-content/plugins/nextgen-gallery/thickbox/thickbox-pack.js?ver=3.1.1

    während im Backend die Thickbox benutzt wird, die WordPress mitbringt.
    In dem von NGG bereitgestellten Thickbox Script ist das hart codiert:

    Code
    ...
    <div id='TB_caption'>"+caption+"<divid='TB_secondLine'>"+
    TB_imageCount+"&nbsp;&nbsp;<a href='"+url+"' id='TB_FullSize' 
    title='Full Size'>[COLOR=Red][B]FullSize[/B][/COLOR]</a>&nbsp;&nbsp;"+
    TB_PrevHTML+TB_NextHTML+"</div></div><div id='TB_closeWindow'>
    <a href='#' id='TB_closeWindowButton' title='Close'>[COLOR=Red][B]close[/B][/COLOR]</a>[B][COLOR=Red] or Esc Key[/COLOR][/B]</div>");$("#TB_closeWindowButton").click(tb_remove);
    if(!(TB_PrevHTML==="")){function
    ...

    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.