Beiträge von codestyling

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

Und wie sieht die Gegenprobe mit dem IE 7 aus ? Funktioniert der ?

Und noch ein ergänzende [COLOR=Red]Warnung[/COLOR]: Wenn du von so einer "alten" Version auf 2.6 umsteigen willst/musst, dann besorg dir aus dem Archiv erstmal eine WP 2.5.1 und update erstmal auf diese. Erst danach auf die WP 2.6, denn die WP2.6 hat einen Bug, wenn man Versionen < 2.3.3 updaten will. Dabei verliert man die Kategorien!
Die 2.5.1 macht alles sauber und danach ist ein weiterer Upgrade auf 2.6 kein Problem mehr.

Archiv: WordPress Deutschland » Archiv » DE-Edition

Sehr schön. Mittlerweile gibt es, basierende auf dem finalen 2. Patch, den ich ebenfalls veröffentlicht habe, einen offiziellen Patch in WP 2.6, der mit der 2.6.1 ausgeliefert wird: Changeset 8421 - WordPress Trac - Trac

Wird dein mint.js auch im Backend geladen ? Wenn ja, deaktive das mal. Konnte die Bibliotheken von prototype.j/jquery.js oder TinyMCE stören.

Das sind 2 Probleme in einer Beschreibung. Für das in_set() Fehler Problem mir Abbruch hab ich einen Fix gebaut, an WordPress gemeldet und hier erstmal zu download bereitgestellt: Code Styling Project » WordPress 2.6 und die Text/Diff Fehler im Editor
Die Sache mit dem TinyMCE (visueller Editor) sollte man dann im 2.Schritt angehen.