Beiträge von codestyling

    Leider nicht Geschichte, denn wenn du ein @ davor machts und es trotzdem nicht geht, den include_path zu setzen, dann unterdrückst du nur die Ausgabe der Fehlermeldung!
    Und die restlichen Dateien können nicht geladen und gefunden werden, denn WP 2.6 bringt alles mit, wie ich schon dachte. Nur muß der Pfad auch zu setzen gehen, damit WP seine mitgebrachten Unterordner und Dateien erreichen kann!

    Also hast du nix weiter gekonnt, als eine Fehlermeldung zu unterdrücken aber dann weiterhin Code ausführen zu lassen, der beliebige Fehler macht und ggf. ganz abbricht und zufällige Ergebnisse liefert.

    Werte in der .htaccess für php setzen:

    Code
    php_value include_path "korrekter voller Pfad"

    Allerdings mußt du alle bisherigen Pfade aufnehmen, die momentan aktive sind und den von der Funktion benötigten noch anfügen.
    Besser den Provider fragen, oder umprogrammieren .

    Oder aber (hab 2.6 immer noch nicht installiert aber daliegen) man kann das Revisionsfeature in den Einstellungen abschalten. Dann wird der Textdiff nicht benutzt (soweit ich mich an die WP Ankündigungen erinnere). Dann könnte es auch funktionieren.

    Es scheint auf abgesicherten Providern ini_set() verboten ein Problem mit der TextDiff Implementierung zu geben, denn der neue Code aus WP 2.6 sieht so aus (wp-includes/pluggable.php):

    Es wird versucht, den include_path temporär zu setzen (wird weiter unten wieder hergestellt), was aber einige Provider nichtzulassen ! Somit bekommt man dann auch die Probleme und Fehlermeldungen aus dem Eingangsbeitrag. Ich denke, hierfür gibt es 3 Lösungsansätze:

    1. Den Provider um Freigabe der ini_set() Funktion bitten.
    2. versuchen, die betroffenen ini Werte per .htaccess Datei zu setzen
    3. Alle betroffenen Dateien des Bereiches wp-includes/Text so patchen, dass es immer funktioniert.

    Punkt 3 ist eigentlich Sache des WP Core Teams und hätte auch vor Freigabe mal simpel getestet werden können, Punkt 2 kann man ohne Garantie (und wenig Hoffnung) probieren und Punkt 1 wird vermutlich nicht durchführbar sein, denn nicht viele Provider lassen in diesem Punkt mit sich reden.

    Hat jemand Lust, den Patch zu programmieren? Würde auch unterstützend tätig werden :)

    Ich greif mal folgenden code von oben auf:

    Code
    ### Create Text Domain For Translation
    add_action('init', 'ban_textdomain');
    function ban_textdomain() {
        if ([COLOR=Red][B]![/B][/COLOR]function_exists('[COLOR=Red][B]wp_print_styles[/B][/COLOR]')) {
            load_plugin_textdomain('wp-ban', 'wp-content/plugins/wp-ban');  //<-- alles kleiner WP 2.6
        } else {
            load_plugin_textdomain('wp-ban', false, 'wp-ban');  //<-- WP 2.6 Fall
        }
    }

    Da hat der Autor ? teilweise mitgedacht und an WP 2.6 anpassen wollen ([COLOR=Red]rot markiert[/COLOR]). Die Funktion wp_print_styles gibt es erst ab WP 2.6 somit wird mit diesem if entschieden, ob der Blog schon 2.6 oder niedriger ist. Also ein auskommentieren ist sicher nicht die beste Wahl, eine Korrektur ist angemessener.
    Da ich selbst noch keine Zeit hatte, die WP 2.6 zu installieren (liegt nur ausgepackt in einem deaktivierten, lokalen vhost rum), kann ich noch nicht viel zur Arbeitsweise der erweiterten load_plugin_textdomain Funktion sagen. Die schau ich mir aber später noch an.

    Ergänzungen:

    Die Sprachdatei für diese Plugin muß, um es nochmal eindeutig und exakt zu sagen, "wp-ban-de_DE.mo" für deutsch heißen und im wp-ban Ordner liegen.
    Desweiteren muß in der wp-config.php folgendes drinstehen:

    PHP
    define ('WPLANG', 'de_DE');

    Dann sollte die Übersetzung auch geladen werden, denn die WP 2.6 Funktion ist intern so definiert:

    Ich werd mal hier antworten, auch wenn du dich durch mehrere Threads mit der selben Frage gerade durchwühlst :)
    WordPress betreibt ein (X)HTML konformes Konzept was Webseiten betrifft. Deshalb wird auch strikt darauf geachtet, das Inhalt und Darstellung voneinander getrennt sind. Der Inhalt (also das was du eingibst im Editor) kannst du per Themes in HTML auszeichnen. Das gibt dem ganzen Struktur aber noch kein Aussehen. Deshalb wird zu den php Dateien, die das Theme bilden im Theme Ordner immer auch eine Stylesheet Datei (style.css) liegen, die beschreibt, wie und wo die einzelnen HTML Auszeichnungen samt deiner Inhalte zu präsentieren sind. Diese Stylesheet Dateien enthalten dann die Angaben zu Fonts, Größen, Farben, Bildern, Positionen etc.
    Du solltest dich mit dem, was hinter HTML und CSS steht, näher beschäftigen, denn WordPress ist trotzdem keine Textverarbeitung nur weil Word im Namen vorkommt. SELFHTML 8.1.2 (HTML-Dateien selbst erstellen)

    Das liegt an der Art der Seitengestaltung. Du hast alles, was im body ist entweder mit relative oder absolute aus dem Fluss des body rausgenommen, so dass dann natürlich height: 101% nicht helfen kann.
    Da müsste man sich ein anderes Designkonzept ausdenken, oder der Kunde lebt damit, das im FF der Sprung drin möglich ist.

    Und was den IE betrifft, fliegt mir MooTools 1.11 mit TypeConflict um die Ohren. Von MooTools gibt es aktuell v1.2, mag sein dass die korrekt geht. Ohne funktionierendes Moo kann man nicht sagen, wie es aussieht.

    Hi,
    ich habe ziemlich sicher genau das selbe Problem. Braucht der Content mehr Platz als der Bildschirm bietet, kommt es zu dem Ruck nach links.:-?
    Nur die genannte Lösung zeigt bei mir keine Lösung, trotz Cache löschen und Seite neu laden.
    Gibt es sonst noch einen Grund, der zu dem Verhalten führen kann?


    Sogar mehrere:

    1. Du hast massive JavaScript Fehler im IE7, wer weis was die Scripts in anderen Browsern machen.
    2. Die Seite hat ca. 70 HTML Fehler: [Invalid] Markup Validation of http://www.janimnetz.de/ - W3C Markup Validator

    Bevor du das nicht repariert hast, kann man nix fundiert dazu sagen.

    Das passiert im Firefox zum Beispiel, wenn du eine sehr große Höhe bei deinem Bildschirm eingestellt hast. Passt die ganze Seite in die Anzeige, stellt FF keine vertikale Scrollbar dar und nutzt den 16px Platz in der Zentrierung mit. Wenn du dann auf deine andere Seite umschaltest, braucht FF den Platz für die Scrollbar und demzufolge "springt" deine Seite wegen Zentrierung ein wenig nach links.
    Wenn du das verhindern willst:

    Code
    body { height: 101%; }


    dann macht FF immer eine Scrollbar.

    Korrigiert mich, wenn ich irre, aber ist das nicht das 2.6 Problem mit den index.php im Permalink?

    Code
    http://www.nachtfliegerin.de/Blog/index.php/2008/07/18/verschwende-deine-zeit/


    Sollte man da als Workaround nicht etwas in die anderen Permafelder einfüllen, damit das geht ? Gab es auch schon mehrere Threads hier, kann mich dunkel erinnern.

    Das liegt am js cache. Bitte mal noch auf der Domain unter wp-content\uploads\js_cache die Datei(en) tinymce_xxxxx.gz löschen, diese beinhaltet u.a. deine bisherige Editoreinstellung und durch den Theme Patch wird die nicht regeneriert. Nach dem Löschen und erneutem Aufruf des Editors legt WP die neu an mit den dann jetzt gültigen Einstellungen, auch denen des Themes. Und sicherheitshalber mal den Browsercache vorher löschen, damit der Browser auch die Scripts neu abholen muß.

    Ich hab momentan keine WP 2.6 hier zur Verfügung. Kann mir das später erst ansehen. Allerdings hat WP noch nie irgend etwas vorausgesetzt, das man u.U. gar nicht installiert hat. Deshalb sollte das schon "out of the box" funktionieren meiner Meinung nach.

    WP 2.6 bringt aber alle diese Dateien in ein Ordner selbst mit. Die Dateien und Ordner sind im Installpaket enthalten und gab es bei 2.5.1 und drunter nicht.
    Es kann auch sein, das euer FTP Programm alle betroffenen Dateien und/oder Ordner in Kleinbuchstaben transferiert hat. Das ist ein Problem, denn unix Systeme unterscheiden zwischen wp-includes/Text/Diff/Renderer und wp-includes/text/diff/renderer, das ist nicht das gleiche. Bitte mal die Schreibweise der Ordner und Dateien mit der aus dem Paket vergleichen.

    Hast du von 1und1 weitergehende Informationen bekommen oder kannst du die besorgen ? Wichtig wären die logfiles, in denen ein Absturz protokolliert wurde (error.log und access.log). Damit kann man sich erstmal ansehen, was da versucht wurde und Gegenmaßnahmen ergreifen. Die robots.txt nutzt dir gar nix, denn diese Art von "bad" bots kümmert sich einen "Dreck" um diese Angaben. Deren Ziel ist nur, in den Server einbrechen zu wollen.

    Also in der functions.php des Freshy 2 Themes findest du das hier:

    PHP
    function freshy_editor_mce_buttons($buttons) {
        array_pop($buttons);
        $buttons[] = "styleselect";
        $buttons[] = "wp_adv_end";
        return $buttons;
    }

    Ändere das mal auf:

    PHP
    function freshy_editor_mce_buttons($buttons) {
        $last = array_pop($buttons);   //temorary removes expander for additional control bars
        $buttons[] = "styleselect";    //enables style selector
        $buttons[] = $last;            //adds the expander again
        return $buttons;
    }

    Dann hast du wieder deinen Knopf zum Expandieren der zusätzlichen Leisten.

    Wenn du wieder auf schöne permalinks umstellen willst (im Moment ist ja alles ohne wegen p= und cat=) dann solltest du auch die slugs anpassen. Aber sieht schon gut aus.

    Und noch was am Rande: Ein Spruch aus deinem Zitate Widget ist nicht UTF-8 kodiert

    Zitat


    "Die F�higkeit zu Verdr�ngen ist ein essentielles Werkzeug zur Selbsterhaltung." - Gothika


    Kannst du ja mal bei Gelegenheit anpassen.

    Dann kannst du das über PhpMyAdmin wieder gerade biegen:

    in der Tabelle: wp_term_taxonomy wird beschrieben, welche ID's (Feld term_id) eine category (Feld taxonomy) sind.

    in der Tabelle: wp_terms kannst du dann allen ID's die du als category in der anderen Tabelle identifiziert hast, dann benennen (Feld name / Feld slug)

    Slug ist der Teil, der für die url verwendet wird. Ich würde sowas im ersten Schritt machen, Beispiel: ID = 4 -> name auf "cat-4" und slug auf "cat-4" setzen. Wenn du alle erstmal benannt hast, kannst du dann per Admin Interface wieder die richtigen Namen vergeben.