Beiträge von codestyling

    In deinem Stylesheet gibt es nur für posts diese Angabe:

    Code
    .post p {
      line-height:14px;
      padding:5px 0;
    }

    Um das auch für die Seiten gemäß deines Themes hinzubekommen, brauchst du aber noch:

    Code
    .page p { 
      line-height:14px;
      padding:5px 0;
     }

    oder zusammenfasst:

    Code
    .post p, .page p { 
      line-height:14px;
      padding:5px 0;
     }

    Google Chrome hat einige Probleme und Inkompatibilitäten mit Javascripts. Dies habe ich leider selbst schon in meinen eigenen Plugins feststellen müssen und bin nicht bereit Google Chrome zu unterstützen, solange die Javascript Engine nicht tut, was sie soll.
    Da der TinyMCE und alles auf den Post/Pages Seiten regen Gebrauch von Javascripten diverser Art macht, kann es schon vorkommen, das die eine oder andere Scriptausführung einfach unterbleibt (ja, Chrome führt einfach manchmal Code nicht aus!) und das Ergebnis unerwünscht ist.
    Daher empfehle ich momentan den Einsatz von Google Chrome auf Javascript basierten Seiten nicht.

    Google ist nicht dumm. Wenn deine Übersichtsseiten bereits den den kompletten Inhalt der Detailseiten enthalten, warum sollten die doppelten Content 2 x indizieren ?
    Übersichtseite= Content A + Content B + Content C + ....
    Detailseite= Content B

    Da die Übersichtsseite schon Content B enthält und auf B nix wirklich neues oder attraktives ist, fällt die Detailseite weg. Auf diese Weise kann man aber auch ganz schnell im Ranking abgewertet werden.

    Ich persönlich hab mit dem SEO Kram nichts am Hut, aber Content 2 mal identisch anzubieten, ist mit Verlaub: Dummheit.

    Man kann auch ohne an der locale des Betriebssystems rumzuschrauben, lokalisierte Datumsausgaben machen:

    Hier ein Anwendungsbeispiel:

    PHP
    echo date_i18n(__( 'M j, Y @ G:i', 'theme-textdomain'), strtotime( $post->post_date ));

    wobei theme-textdomain die textdomain deines Themes sein sollte, damit du das in der Sprachdatei des Themes auch bearbeiten kannst. (Dann findet das auch mein Plugin bei Einlesen der Dateien und du kannst es einfach übersetzen.)

    Für den IE kannst du keine width 100% für das Bild angeben, das rechnet der falsch.
    Ein width von 98% funktioniert im IE und auch bei allen anderen, geteste mit der DevToolbar des IE und die Breite online gepatched.

    Ergänzung zu finden hier:

    CSS
    .ngg-imagebrowser img {
    border:1px solid #A9A9A9;
    display:block !important;
    margin-bottom:10px;
    margin-top:10px;
    padding:5px;
    [B]width:100%;[/B]

    Müsste bei der nextgen gallery im Stylesheet sein, bitte auf 98% ändern.

    Liegt mit Sicherheit am IFrame, in dem du das machst.
    Wenn du die WordPress Installation direkt benutzt über:

    Code
    http://tobicomic.ch/wordpress/wp-login.php


    dann sollte es auch keine Probleme geben.
    Ich denke, dass dir die "same origin policy" der Browser hier nicht mitspielt (weil Aussen und Innenseite andere Domains sind).


    ich möchte, dass ein html-code von einem formular gesendet in das editorfeld kopiert wird. hab schon nach send_to_editor gegoogelt und etwas mit javascript rumprobiert. war bis jetzt aber alles nicht so das, was ich will. ich generiere einen html-code und will, dass der nach dem "submit" in den editor geladen wird.


    Das verstehe ich nicht, hast du ein praktisches Beispiel dafür ?
    Wer sendet von wo nach wo was ?

    Das Datumsformat? Ich geb dir ja recht, dass das am saubersten per per get_option() aus den allgemeinen Einstellungen geholt wird, aber hier IMHO eher unnötig.
    Der "Januar" wird ja korrekt übersetzt, die Sprachdatei sollte also okay sein.


    Sehe ich anders. Der Theme Author hat sich die Mühe gemacht, alles in seiner eigenen Sprachdatei des Themes anpassbar zu machen:

    PHP
    <?php the_time([COLOR=Blue][B]__([/B][/COLOR]'[COLOR=SeaGreen]F jS, Y[/COLOR]', '[COLOR=Red][B]inove[/B][/COLOR]')) ?>


    wobei dann:

    • [COLOR=Blue]__([/COLOR] derAufruf der gettext Funktion für reine Textübersetzung
    • [COLOR=SeaGreen]'F jS, Y'[/COLOR] der zu übersetzende Datumsformatierer
    • [COLOR=Red]'inove'[/COLOR] die Textdomain der Theme spezifischen Sprachdatei ist.


    Also kommt das nicht aus der WordPress Sprachdatei sondern aus der des Themes. Und genau dort sollte das auch angepasst werden. Damit erspart man sich bei Theme Updates Ärger, denn die angepassten Sprachdateien kann man sich als Backup sichern und muß nicht ständig Code "umbasteln".

    ich muß die Frage nochmal nach oben schieben. Weiß leider immer noch nicht, woran es liegt, daß die Seiten ca. 5 s. warten, bis sie anfangen zu laden.
    Ich hab's mit dem Standart-Theme probiert, mit deaktiviertem JavaScript. Hab auch das GeoMashup- Plugin in Verdacht gehabt, auch keine Änderung.

    Ich komm nicht weiter. YSlow in Firebug sagt mir, daß diese Seite 6,5 s. für den GET-Befehl braucht. Sagt mir aber leider nicht, wo es klemmt.
    Liegt der Fehler am Provider? Oder am Netz? Läd die Seite bei Euch schneller?

    Ich kann doch die Seite so nicht unseren Fans anbieten. Wäre ja ne Zumutung...
    Bin für jeden Tip dankbar.


    Also was auch immer dein WordPress hier macht, für diese Seite braucht es mit Sicherheit keine > 400 Datenbankanfragen!

    Code
    <p class="footerstats">
    
    
    
    
            427 queries. 2.1150 seconds.    </p>

    Bei dieser Masse an Datenbankanfragen grenzt es schon an ein Wunder, unter 10 Sekunden weg zu kommen. Das sollte sich mal jemand ansehen, denn ein Standardtheme braucht gerade mal 10-12 Anfragen, ein gutes Theme sollte mit 30-40 max. auskommen. Dein Theme braucht aber das 10fache und somit auch die 10fache Zeit. Wenn man normalerweise eine Seite in 500 msec ausliefern kann, werden das dann bei dir 5sec sein.

    <?php the_time(__('F jS, Y', '[COLOR=Red]inove[/COLOR]')) ?>


    Das weisst darauf hin, das dein Theme ein Sprachdatei versteht, du aber keine deutsche Sprachdatei für das Theme verwendest, die falsch benannt ist oder die Übersetzung des Formatierers nicht dem Deutschen entspricht.

    In die Doku zu schauen wäre zu einfach, was? ;)
    Template Tags/the time WordPress Codex

    PHP
    <?php the_time("d.m.Y") ?>

    Andere Datumsformate siehe PHP-Doku:
    PHP: date - Manual


    Ganz schlechter Rat, das im Code zu ändern. Das sollte man in der Sprachdatei des Themes anpassen. Geht sehr einfach: Code Styling Project WordPress Plugin: Codestyling Localization