Um schreiben oder kommentieren zu können, benötigen Sie ein Benutzerkonto.
Sie haben schon ein Benutzerkonto? Melden Sie sich hier an.
Jetzt anmeldenHier können Sie ein neues Benutzerkonto erstellen.
Neues Benutzerkonto erstellen
Hallo!
Wenn du gerade an deiner Website arbeitest oder dein aktuelles Hosting überdenkst: Wir betreiben mit NetzLiving eine Hosting-Plattform, die speziell auf Performance, Sicherheit und einfache Verwaltung ausgelegt ist.
Jop, sieht gar nicht schlecht aus. Ich tipp echt auf den Umlaut da, das der irgendwie Probleme macht... kannst du da nicht mal auf was andres als auf "Büro" filtern? Nur mal zum testen...
PS: Wir sind doch erst bei 21 Antworten. Das ist doch noch harmlos ;)
PHPWordPress 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.
Was mir auch grade noch auffällt: Bisher hieß der Wert immer "büro", jetzt auf einmal "Büro". MySQL ist unter Umständen Case-sensitive.
Naja, die Query an sich ist ja okay, nur liefert "Büro" halt kein Ergebnis. "Obergeschoss" liefert auch "null" zurück? In PHPMyAdmin liefern die Queries Ergebnisse?
So, bin erstmal weg für heute...
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.
Sowohl die Tabellen der WP-DB als auch die der mit den mitarbeiter-Daten stehen laut phpmyadmin auf latin1_general_ci nur das Feld ort hatte ich im Laufe unserer Versuchsreihe auf utf8_unicode_ci umgestellt.
Was ist ein BOM Marker? Das musst Du mir nochmal erläutern.
Das Skript bearbeite ich derzeit im Editor in WP im html-Fenster, ansonsten arbeite ich mit Phase5.
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.
Kannst du mal irgendwas "einfaches" ausprobieren?
"SHOW TABLES" oder sowas?
Vielleicht auch mal direkt als 1. Parameter von get_results(), statt vorheriger query()?
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...)?
Guten Morgen,
mmh... irgendwie ist mein letzter Tread verloren gegangen, also nochmal:
Da du aber mit dem Theme-Editor ?
Ich arbeiten an dem Skript derzeit im Beitragseditor von WP im html-Bereich (nicht im Visuell-Bereich). Hier habe ich eine statische Seite angelegt auf der die externen Daten ausgegeben werden sollen.
Das "Ursprungsskript" ist mit Phase5 erstellt und Teile davon mit copy+paste in WP eingefügt worden.
Aber irgendwie glaub ich nicht, das es daran liegt, denn ich habe bereits ein Skript, was anstandslos funktioniert (noch ohne wpdb-Klasse), das ich auf die gleiche Weise erstellt habe.
Auch ein direkter Vergleich dieser Skripte hat mich nicht weitergebracht. Die einzigen Unterschiede im SQL-String bestehen darin, das ich nicht alles auslese (sprich "*" nicht verwende, sondern Felder definert habe) und keine where-Klausel benutze.
Sehr verwirrend finde ich.
d.
Verwende mal '*' statt dessen, oder meine "SHOW TABLES"-Query von weiter oben. Mal irgendwas wo wir sicher sein können, dass keine Umlaute irgendwo stören könnten.
Du meinst, direkt im Beitragseditor? Mit einem PHP-Plugin? Vielleicht macht auch der Editor Müll aus deiner Query... verwende doch statt dessen mal lieber ein Seitentemplate oder so, und gib den Code direkt mit einem Texteditor ein.
Kannst du mal irgendwas "einfaches" ausprobieren?
"SHOW TABLES" oder sowas?Vielleicht auch mal direkt als 1. Parameter von get_results(), statt vorheriger query()?
:oops: So?
$my_wpdb->query($my_wpdb->prepare("SHOW TABLES"));und/oder so?
$ergebnis = $my_wpdb->get_results(SHOW TABLES);erstes bringt
WordPress database error: []
SHOW TABLES
NULL
Warning: Invalid argument supplied for foreach() in /srv/www/wordpress/wp-content/plugins/exec-php/includes/runtime.php(42) : eval()’d code on line 27
und zweites einen syntax-error.
Sorry, ich hab´s einfach noch nicht so drauf mit der richtigen Syntax-Formulierung, brauch da immer ein paar Anläufe.:-?
So langsam bekomme ich Muffensausen, das es irgendein blöder Syntxfehler ist, obwohl ich alles schon ich weiß nicht wie oft kontrolliert habe.:neutral:
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.
diltigug: Das 2., aber mit Anführungszeichen:
$ergebnis = $my_wpdb->get_results([COLOR="Red"][B]"[/B][/COLOR]SHOW TABLES[COLOR="Red"][B]"[/B][/COLOR]);
(mmh, das 1. sollte doch auch funktionieren... vielleicht passt da intern was nicht oder ich interpretiere die Doku zu get_results() falsch... :???:)
Der BOM Hinweise war nur zusätzlich, primär wichtig ist nur, das die Seite (Template) UTF-8 gespeichert ist.
Ja okay, deswegten fragte ich ja. Aber anscheinend nimmt er ja kein Template.
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:
Ja, das hab ich auch schon gefunden. Daher ja meine Testqueries komplett ohne irgendwelche Umlaute oder Non-ASCII-Sonderzeichen. Die müssen ja was liefern, egal wie's in der DB aussieht. Oder siehst du das anders?
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.
Das könnte man ja eventuell sogar zum Vorteil nutzen, um die Konstanten mit anderen Werten nochmal neu zu initialisieren. Falls es wirklich an den Umlauten liegt...
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.
diltigug: Das 2., aber mit Anführungszeichen:
Code$ergebnis = $my_wpdb->get_results([COLOR=Red][B]"[/B][/COLOR]SHOW TABLES[COLOR=Red][B]"[/B][/COLOR]);
Aha, endlich passiert mal was neues :):
WordPress database error: []
SET NAMES 'utf8'
array(9) { [0]=> object(stdClass)#147 (1) { ["Tables_in_intranet02"]=> string(7) "bereich" } [1]=> object(stdClass)#148 (1) { ["Tables_in_intranet02"]=> string(7) "gewerke" } [2]=> object(stdClass)#149 (1) { ["Tables_in_intranet02"]=> string(11) "mitarbeiter" } [3]=> object(stdClass)#175 (1) { ["Tables_in_intranet02"]=> string(8) "projekte" } [4]=> object(stdClass)#176 (1) { ["Tables_in_intranet02"]=> string(8) "prospekt" } [5]=> object(stdClass)#177 (1) { ["Tables_in_intranet02"]=> string(11) "urteilarten" } [6]=> object(stdClass)#178 (1) { ["Tables_in_intranet02"]=> string(7) "urteile" } [7]=> object(stdClass)#179 (1) { ["Tables_in_intranet02"]=> string(12) "vergabearten" } [8]=> object(stdClass)#180 (1) { ["Tables_in_intranet02"]=> string(8) "vergaben" } }
Catchable fatal error: Object of class stdClass could not be converted to string in /srv/www/wordpress/wp-content/plugins/exec-php/includes/runtime.php(42) : eval()'d code on line 30
Aha, endlich passiert mal was neues :
Mmh.... sollte ich die Doku doch tatsächlich missinterpretiert haben? aber es steht doch eindeutig so da:
[SIZE="4"]get_results - SELECT Generic Results [/SIZE]
Generic, mulitple row results can be pulled from the database with get_results. The function returns the entire query result as an array. Each element of this array corresponds to one row of the query result and, like get_row can be an object, an associative array, or a numbered array.
PHP<?php $wpdb->get_results('query', output_type); ?>
query
(string) The query you wish to run. [COLOR="Red"]Setting this parameter to null will return the data from the cached results of the previous query[/COLOR].
Sehr merkwürdig das ganze...
Catchable fatal error: Object of class stdClass could not be converted to string in /srv/www/wordpress/wp-content/plugins/exec-php/includes/runtime.php(42) : eval()'d code on line 30
Was is denn das nu wieder? :shock: Was steht in Zeile 30 des eval'd Code? Also wahrscheinlich die 30. Zeile des Codes im Editorfenster. Sollte es doch mit Exec-PHP zusammenhängen, dass es anders nicht funktioniert?
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.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!