Beiträge von codestyling

Wenn du einen managed Server hast, müsstest du doch trotzdem die php.ini ändern dürfen. Wenn du also schon mit PHP5 läufst, solltest du auch den Wert:

mbstring.func_overload = 0

auf 0 stehen haben.

Es gibt aber noch ein weiteres Problem, das bei einigen Provider FAQ's beschrieben wird. Dort wird als Lösung ebenfalls noch folgender Zusatz empfohlen:

zend.zel_compatibility_mode = Off 
  zend.ze1_compatibility_mode = Off

Da man sich in den Dokumentationen von PHP streitet, ob der Parameter nun "zel" oder "ze1" beginnt, würde ich beide so eintragen. Hier ein Link dazu: [URL="http://support.genotec.ch/index.php?_m=k…=478&nav=0,3,19"]WordPress 2.3.1 wird nicht ausgeführt (Dateien werden heruntergeladen)[/URL]
Dies wird im Netz auch als Lösung für sporadisch zerstörte grössere Downloads genannt, deren zip Files manchmal nach dowload "geschrottet" sind. Dieser ZEND_COMPATIBILITY_MODE ist für reine PHP 5 Ausführung kontrapoduktiv und kann diese Art der Problem mit hervorrufen.
Und ein PHP Bug wurde in den letzten Tagen endlich beseitigt und ein Patch-Download bereitgestellt: PHP Bugs: #27421: mbstring.func_overload set in .htaccess becomes global der das auch auslösen kann.

Das sieht nach dem Revisions Feature Bug und einer "silent" Error Unterdrückung seitens des Provider aus, da bei dir sicher ini_set() aus Sicherheitsgründen unterbunden wird. Hier ein vorläufiger Patch dafür: Code Styling Project » WordPress 2.6 und die Text/Diff Fehler im Editor
Ist bei WP schon in Arbeit, hab ich eingereicht und man streitet sich noch, wie das endgültig gefixed wird.

Gleich noch eine Ergänzung, um den Rahmen abzuschalten:

img.aligncenter, img[align="center"] {
    display: block;
    margin-left: auto;
    margin-right: auto;
    [COLOR=Green][B]border[/B][/COLOR][COLOR=Green][B]:0pt none;[/B][/COLOR]
 }

Ergänzung: und für denn Fall der Frage nach den anderen Bildern:

img.alignleft, img[align="left"] {
    float:left;
    margin:2px 10px 5px 0px;
     [COLOR=Green][B]border[/B][/COLOR][COLOR=Green][B]:0pt none;[/B][/COLOR]


}

und

img.alignright, img[align="right"] {
    float:right;
    margin:2px 0px 5px 10px;
     [COLOR=Green][B]border[/B][/COLOR][COLOR=Green][B]:0pt none;[/B][/COLOR]


}

Ich hab dir ja den Ausschnitt aus der HTML Ansicht deines Beitrags oben gezeigt mit dem Bild. Dort solltest du aligncenter gegen center austauschen.
Da du das aber dann bei allen Bildern machen musst, hatte ich vorgeschlagen, die style.css (wie Monika schon schrieb) zu ändern und zwar so:

img.[COLOR=Green][B]aligncenter[/B][/COLOR], img[align="center"] {
    display: block;
    margin-left: auto;
    margin-right: auto;
}

Zitat von gwen58

Hallo. Ich möchte nun ein upgrade von 2.2.1 auf die aktuelle Version machen.

Jetzt sehen die alte und die neue wp-config Datei ja völlig unterschiedlich aus.
Was muß ich denn nun tun?

Kann ich nicht meine mysql Einstellungen in die neue Datei kopieren und die nehmen und die alte auch löschen?

Als Erstes würde ich dir einen stufenweisen Upgrade empfehlen, denn die WP 2.6 hat einen Upgrade Bug, wenn man Versionen kleiner WP 2.3.3 auf die neue hochbringen will: man verliert dabei alle Kategoriebeschriftungen und Slugs dazu (nur die Beschriftung, nicht die Kategorie selbst).
Wenn du erstmal auf WP 2.5.1 und dann erst auf WP 2.6 updates, ist alles ok. Hier die Archiveseite mit Vorgängerversionen: WordPress Deutschland » Archiv » DE-Edition

Und zurückzukommen auf die wp-config.php, in die neue brauchst du nur die DB Einstellungen rübernehmen, was man mit dem Rest machen kann steht in den FAQ's: Upgrade − WordDoku

In deinem Stylesheet ist aligncenter nicht definiert:

<img width="200" height="200" alt="" 
src="http://www.sparblog.com/wp-content/uploads/2008/07/jam.jpg" 
title="jam" class="[COLOR=Red]aligncenter[/COLOR] size-full wp-image-382"/>

Dafür aber das hier:

img.center, img[align="center"] {
    display: block;
    margin-left: auto;
    margin-right: auto;
}

somit würde das bei dir nur zentriert, wenn das Bild so drin ist:

<img width="200" height="200" alt="" 
src="http://www.sparblog.com/wp-content/uploads/2008/07/jam.jpg" 
title="jam" class="[COLOR=Green][B]center[/B][/COLOR] size-full wp-image-382"/>

Entweder, du änderst das an jedem Bild oder du änderts dein o.g. Stylesheet auf aligncenter ab.

Weil die Nummer nicht im <a> drin ist sondern dahinter im <li> ist:

<li><a href=...>Text</a> (Nummer)</li>

Damit wird die Nummer auf die nächste Zeile verdrängt, wenn durch display:block der <a> den ganzen, zur Verfügung stehenden horizontalen Bereich nutzen soll.

Das Weisse Kästchen ist das hier:

<img width="1" hspace="1" height="1" border="0" align="bottom" src="http://ad.zanox.com/ppv/?9645660C192960337"/>

Hast du wohl was nicht richtig eingebaut.

Nur mal so am Rande: Wenn ich per DeveloperToolbar das Laden von Images jedweder Art verbiete, ist der Lade- und Darstellungsvorgang der Seite um mindestens 3 bis 5 Sekunden kürzer! Wenn ich das mit den Scripten mache, gewinnt man nur ca. 1.5 Sekunden.
Die Flickr direct loads brauchen am längsten und da es keine Größenangabe am Image gibt, kommt der Renderer nicht weiter, denn die Größe kann er erst bestimmen, wenn das Bild da ist.
Allein mit onpage Optimierung im Bereich Bilder (Größe, Anzahl, dynamische CSS Bildausschnitte aus einem Sammelbild per Positionierung usw.) wirkt da Wunder.
Den Rest macht mit Sicherheit ein Magazin Theme aus, denn als ich diese mal getestet hab, machten die meist mehr als 43 Queries in die DB obwohl man im Standard auch mit 13 auskommen könnte. Wenn dann noch die DB am "nassen Bindfaden" angebunden ist, Mahlzeit.
Ergo 3 Baustellen:

1. eigene Bilder, ggf. Scripte
2. Benutzerfelder und Magazin typische (unnütze) Einzelanfragen
3. Datenbank speed testen

Mal diese Abschnitte durchgehen der exec_php Beschreibung:
http://bluesome.net/post/2005/08/18/50/#troubleshooting
http://bluesome.net/post/2005/08/18/50/#faq
Hier sind einige Problemfälle gelistet, wie es scheint, könnte der eine oder andere zutreffen.

Warum wird eigentlich für den Beitrag/Seite keine eigenes Template gebaut, das im PHP code die POST Bearbeitung der per Editor eingeklebten <Form> macht ? Wäre doch um einiges leichter und braucht kein Plugin.

Primär sollte erstmal geklärt werden, wie das PHP Script, das im Beitragseditor eingeklebt wurde, ausgeführt wird. Da einige Fehlermeldungen von eval'd code schreiben, sieht das für mich so aus, als würde irgend ein Plugin das eingeklebte Script rausfischen und per eval() ausführen. Da kann es zu den merkwürdigsten Nebenwirkungen (angefangen von Scope Problemen bis zu nicht global zugegriffenen Objekten) kommen.
Es wäre gut, den gesamten Scriptblock mal zu sehen, der in den Editor eingefügt wird und die Angabe dazu, wer und wie das ausgeführt wird.

Zitat von marX

codestyling: Kannst du mich mal bitte aufklären, was du hier mit dem BOM möchtest? Das BOM sollte doch mit der Query selbst eigentlich nix am Hut haben (abgesehen von den UTF-8-codierten Sonderzeichen im Querystring natürlich...)?

Der BOM Hinweise war nur zusätzlich, primär wichtig ist nur, das die Seite (Template) UTF-8 gespeichert ist.
Hier noch ein paar Randinformationen. Wenn die betreffende DB nicht komplett auf UTF-8 läuft, wird es mit dem wpdb Objekt Probleme geben, denn:

function __construct($dbuser, $dbpassword, $dbname, $dbhost) {
        register_shutdown_function(array(&$this, "__destruct"));


        if ( defined('WP_DEBUG') and WP_DEBUG == true )
            $this->show_errors();


        if ( defined('DB_CHARSET') )
            [COLOR=Red]$this->charset = DB_CHARSET[/COLOR];


        if ( defined('DB_COLLATE') )
            [COLOR=Red]$this->collate = DB_COLLATE[/COLOR];


....


        if ( !empty($this->charset) && version_compare(mysql_get_server_info($this->dbh), '4.1.0', '>=') )
             [COLOR=Red]$this->query("SET NAMES '$this->charset'");[/COLOR]

Spätestens das SET NAMES wird UTF-8 verlangen, somit muß der Query String selbst UTF-8 sein. MySQL :: MySQL 5.1 Referenzhandbuch :: 10.4 Verbindungszeichensatz und -sortierfolge

Und zum Thema Beitragseditor: Mich würde interessieren, wie ein dort eingeklebtes Script ausgeführt wird. Wenn das mit exec_php gemacht wird, das WP Objekt zwar benutzt aber die wp-config.php nicht, dann sind DB_CHARSET und DB_COLLATE nicht definiert und die DB sucht sich raus, was sie verstehen will.

Ich es nun mit WordPress 2.6 getestet und es funktioniert auch in dieser Version anstandslos. Hab es wieder in meinem Testsystem WP 2.6 laufen.

Hatte ich schon mal mit einem anderen Forum-User durchgeführt: http://forum.wordpress-deutschland.org/konfiguration/…html#post178407
Das sollte dann mittels PhpMyAdmin gehen.

Hier die Wikipedia Beschreibung für BOM: Byte Order Mark – Wikipedia
Nicht alle Texteditoren (Standalone) können UTF-8 Text Dateien schreiben ohne eine Byte Order Mark vor dranzusetzen. Da du aber mit dem Theme-Editor ? arbeitest, sollte der eigentlich korrektes UTF-8 schreiben, sicher bin ich nicht, denn wenn die Ursprungsdatei ANSI war schreibt der auch wieder ANSI raus.

Ich mach erstmal Feierabend, komme später darauf nochmal zurück.

Zitat von diltigug

PHP

WordPress database error: []
SELECT * FROM mitarbeiter WHERE ort = 'Büro' ORDER BY lastname ASC, firstname ASC

Wenn deine DB auf UTF-8 läuft und du die Datei mit diesem Text 'Büro' direkt gefüttert hast, hast du sie auch als UTF-8 ohne BOM Marker im TextEditor gespeichert ? Wenn nicht, ist es eine ANSI Datei mit korruptem Zeichen in einer Anfrage für UTF-8.

Das ist kein UTF-8 codiertes Zeichen im Quelltext oder der Ausgabe:

<span style="line-height: 0px; text-transform: uppercase; font-weight: normal; font-size: 11px;">
�
       <a href="http://www.gutefrage.net"><img border="0" alt="www.gutefrage.net: Antworten auf Ihre Fragen!" src="http://www.wirtschaftkompakt.de/img/gf_header200_s.png"/></a>
     </span>

Ist ein ANSI codierter Umlaut oder Sonderzeichen > char(127), der nicht UTF-8 konform ist.

Wenn du schon UTF-8 Seiten ausliefern lässt, dann stell doch auch sicher, das deine Texte UTF-8 sind. Der Inhalt einer exemplarischen Seite: Roman | Buchtipps - Buchempfehlungen enthält ein Menge nicht UTF-8 Zeichen (Umlaute in ANSI):

</style>
<!--[if IE]>
    <style type="text/css"> 
    /* F�gen Sie CSS-Korrekturen f�r alle IE-Versionen in diesen bedingten Kommentar ein. */
    #nav { padding-top: 5px; 
   }
 
        </style>
    <![endif]-->

oder so was:

<h1><a href="http://www.leseberater.de/">Buchtipps - Buchempfehlungen</a>
Die besten B�cher - Buchtips und Buchempfehlungen von Buchh&auml;ndlern und Autoren</h1>

Damit wird das nix mit Google, denn deine Seite wird als "korrupt" schlechter eingestuft !

Das hat nicht mit dem SP3 zu tun. Hab selbst SP3 laufen und all major Broswer funktionieren: Opera, Safari, FireFox und IE.
Ich denke, irgend ein Plugin/Theme bringt seine eigenen Scripte mit, die dann die Editorscripte (egal of TinyMCE oder FCK Editor) abschiessen. Das ist schon zu oft passiert, als das man das ignorieren kann. Sehr oft schon hat sich ein Plugin als Übertäter herausgestellt in einem Fall, den ich hier behandelt habe, waren es sogar Scripte im Theme, die der User selbst geschrieben hat!
Ich würde alle Plugins mal deaktivieren und das Standard Theme einschalten.
Wenn die Editoren dann funktionieren, nach und nach Plugins aktivieren und prüfen, wann es nicht mehr geht. Wenn du alle Plugins benutzen kannst ohne Probleme, wird es dein Theme sein.

Ich hab noch keine Zeit gehabt, das unter WP 2.6 zu testen, aber werde das heute Abend nachholen und den Artikel ergänzen. Mir fallen pauschal keine Gründe ein, warum das in WP 2.6 nicht gehen sollte.
Wegen chronischem Zeitmangel (Terminstress) komme ich nur schleppend voran. Aber es wird definitiv weiterentwickelt und nicht eingestampft :)