KategoriePHP

WordPress WPDB (wp-db.php) public functions

public function init_charset()

public function determine_charset( $charset, $collate )

public function set_charset( $dbh, $charset = null, $collate = null )

public function set_sql_mode( $modes = array() )

public function set_prefix( $prefix, $set_table_names = true )

public function set_blog_id( $blog_id, $network_id = 0 )

public function get_blog_prefix( $blog_id = null )

public function tables( $scope = ‚all‘, $prefix = true, $blog_id = 0 )

public function select( $db, $dbh = null )

public function _escape( $data )

public function escape_by_ref( &$string )

public function prepare( $query, $args )

public function esc_like( $text )

public function print_error( $str = “ )

public function show_errors( $show = true )

public function hide_errors()

public function suppress_errors( $suppress = true )

public function flush()

public function db_connect( $allow_bail = true )

public function parse_db_host( $host )

public function check_connection( $allow_bail = true )

public function query( $query )

public function placeholder_escape()

public function add_placeholder_escape( $query )

public function remove_placeholder_escape( $query )

public function insert( $table, $data, $format = null ) {

public function replace( $table, $data, $format = null )

public function update( $table, $data, $where, $format = null, $where_format = null )

public function delete( $table, $where, $where_format = null )

public function get_var( $query = null, $x = 0, $y = 0 )

public function get_row( $query = null, $output = OBJECT, $y = 0 )

public function get_col( $query = null , $x = 0 )

public function get_results( $query = null, $output = OBJECT )

public function get_col_charset( $table, $column )

public function get_col_length( $table, $column )

public function strip_invalid_text_for_column( $table, $column, $value )

public function get_col_info( $info_type = ’name‘, $col_offset = -1 )

public function timer_start()

public function timer_stop()

public function bail( $message, $error_code = ‚500‘ )

public function close()

public function check_database_version()

public function supports_collation()

public function get_charset_collate()

public function has_cap( $db_cap )

public function get_caller()

public function db_version()

 

$wpdb->insert funktioniert nicht ohne erkennbaren Grund

Die Insert-Funktion der WordPress-eigenen Datenbankklasse ist bekanntermaßen sehr nützlich.
Allerdings gibt es eine wenig dokumentierte Einschränkung, welche einen an den Rand der Verzweiflung treiben kann.

Sofern man nämlich bspw. an ein als VARCHAR definiertes Feld mit einem String über die $wpdb->insert-Funktion füllen möchte, darf dieser String nicht länger als sein, als in der MySQL-Tabelle definiert. Ansonsten tut WordPress nämlich einfach gar nichts; keine Fehlermeldung, keine last_query, niente!

Zu allgemein? Wenn ich ein Feld „plz“ mit VARCHAR(5) definiert habe und über $wpdb->insert „123456“ zu schreiben versuche, passiert einfach gar nichts.

Nun kann man natürlich danach schreien, dass man doch alle Daten vor dem Schreiben validieren muss, aber MySQL selbst hat sich da gar nicht so. MySQL schneidet den String einfach ab und gut ist. Ein Insert über $wpdb->query funktionert natürlich, da es ja nur ein Wrapper für eine MySQL-Abfrage ist.

Wie kann man bei DomainFactory auf die Datenbank in einem anderen Auftrag per PHP zugreifen?

Bei vielen Hostern kann man auf alle Datenbanken des Hosters, so man die Zugangsdaten hat, zugreifen. Bei einigen Hostern kann man sogar externen Zugriff auf die Datenbanken gestatten.
Bei DomainFactory geht das leider nicht ohne Weiteres. Auch wenn eine Konfigurierbarkeit der Zugriffsmöglichkeiten wünschenswert wäre, muss man doch auf die etwas unhandliche Variante des SSH-Tunnels zurückgreifen.

Sofern man auf der Konsole per SSH arbeitet, ist das nicht weiter schwierig. Auf Server A einfach

eingeben, dass passende Kennwort für den SSH-Benutzer auf Server B eingeben und fertig.

Wenn man jetzt auch gleich noch den Datenbankzugriff auf eine MySql5-DB auf Server B haben möchte, sieht das dann so aus:

Anschließend lässt sich über den Host 127.0.0.1 auf Port 3307 auf die Datenbanken auf Server B zugreifen.

Wenn man nun das Ganze in PHP abbilden möchte, lernt man schnell, dass man zwar mit shell_exec() die SSH-Verbindung anstoßen kann, aber eben nicht das Kennwort übergeben kann.

Die Lösung ist eigentlich ganz einfach. Man generiert entsprechende Schlüssel und anschließend funktioniert der Zugriff ohne Eingabe eines Kennwortes.

Folgendes ist zu tun.

Auf Server A (von dem aus auf Server B zugegriffen werden soll) auf der Konsole:

eingeben und alle Abfragen mit [RETURN] bestätigen.
Es werden dann im Verzeichnis .ssh zwei Dateien abgelegt. Der private Schlüssel id_rsa und der öffentliche Schlüssel id_rsa.pub.

Die Datei id_rsa.pub muss anschließend auf den Server B in das Verzeichnis .ssh kopiert werden und anschließend in authorized_keys umbenannt werden. Sollte die Datei authorized_keys schon bestehen, so ist die id_rsa.pub mit der authorized_keys zu konkatenieren.
Anschließend muss das Verzeichnis .ssh noch auf die Rechte 0700 und die Datei authorized_keys auf die Rechte 0600 gesetzt werden.

Ein Test auf der Konsole von Server A mit

sollte nunmehr eine SSH-Vergbindung mit Server B ohne Rückfrage nach einem Passwort aufbauen.

Sofern das alles funktioniert, kann man nunmehr per PHP den SSH-Tunnel aufbauen und sich dann mit der Datenbank verbinden:

Das „2>&1“ kann man weglassen. Es sorgt lediglich dafür, dass in Verbindung mit der Option -v die Ausgaben der Konsole tatsächlich zurückgegeben werden.
Bei der mysqli-Verbindung muss zwingend 127.0.0.1 statt localhost angegeben werden, da ansonsten versucht wird, eine Socket-Verbindung statt einer Verbindung über Port 3307 aufzubauen, was natürlich nicht funktioniert.

Wie kann ich eine WordPress-Installation möglichst schnell und elegant umziehen?

Neben der „klassischen“ Methode (Dateien einzeln per FTP herunterladen, DB-Backup per PHPMyAdmin erstellen) gibt es auch noch den etwas eleganteren Umweg über die Kommandozeile.

Oftmals hat man jedoch in einfacheren Hostingpaketen keinen Zugriff per Telnet oder SSH. Allerdings lassen sich fast immer trotzdem Systembefehle absetzen.

Diesen Umstand kann man sich für eine schnelle Erstellung von Backups von Code und DB zu nutze machen.

Backup DB:
system("mysqldump --opt -Q -h DB-ALT-HOST -u DB-ALT-USER -p DB-ALT-NAME --password=\"DB-ALT-PASSWORT\" > ./dbdump.sql",$ret);

Backup Code:
system("tar -zcf ./backup.tar.gz ./*",$ret);

Anschließend werden die beiden erzeugten Dateien per (S)FTP heruntergeladen und auf den neuen Server hochgeladen.

DB einspielen:
system("mysql -h DB-NEU-HOST -u DB-NEU-USER --password=\"DB-NEU-PASSWORT\" DB-NEU-NAME < ./dbdump.sql");

Code entpacken:
system("tar -xvzf ./backup.tar.gz ",$ret);

Anschließend müssen in der Datei „wp-config.php“ noch die neuen DB-Daten eingetragen werden.

Hinter den DB-Daten müssen dann noch die beiden Zeilen für die neue Domain eingetragen werden:
define('WP_SITEURL', 'http://www.neue-adresse.de');
define('WP_HOME', 'http://www.neue-adresse.de');

Weiterhin sollte noch folgende Zeile eigefügt werden:
define('RELOCATE', true);

Anschließend muss die Login-Seite aufgerufen werden:
http://www.neue-adresse.de/wp-login.php

Diese Zeile wird noch vor dem Ausfüllen des Login-Formulars wieder entfernt.

Im Dashboard dann ein Plugin, z.B. „Better Search and Replace“, installieren und die alten URLs in der Datenbank durch die neuen URLs ersetzen.

WordPress zeigt nach dem Umzug keine Stylesheets oder Bilder an oder beim Versuch auf wp-admin zuzugreifen wirft der Server einen Fehler 403

Insbesondere beim Umzug zu einem neuen Hoster kann es vorkommen, dass beim Kopieren oder Entpacken der Dateien die Verzeichnisrechte nicht korrekt übernommen werden.

Dieses Problem lässt sich relativ leicht beheben, indem in einem FTP-Programm alle Verzeichnisse (rekursiv!) die Rechte 755 und alle Dateien die Rechte 644 zugewiesen bekommen.

Sollte man Zugriff auf die Serverkonsole, bspw. per SSH, haben, kann das Problem deutlich schneller gelöst werden, indem im WP-Stammverzeichnis folgende Befehle ausgeführt werden:
find ./ -type d -exec chmod 755 {} +
find ./ -type f -exec chmod 644 {} +

MYSQL Visualizer – Ein schlankes, webbasiertes Tool, um Datenbankstrukturen zu visualisieren

Wer jemals versucht hat, eine fremde Datenbankstruktur zu verstehen – oder, noch schlimmer – ein altes Projekt revisionieren sollte, der kennt das Problem: Wie zum Teufel hängen diese verd… Tabellen zusammen?

Natürlich gibt es professionelle Lösungen, die wahlweise vieles können, aber nicht das, was man will, oder die ein Schweinegeld kosten.

Aber eigentlich will man doch nur kurz visualisieren, welche Tabellen es gibt und wie sie zusammenhängen.

Das kleine Tool MYSQL Visualizer tut genau das. Man kopiert es in ein Verzeichnis auf dem passenden Webspace, legt einen Verzeichnisschutz drauf und ruft es auf. Nach Eingabe der DB-Konnektivitätsdaten zieht das Tool die Daten der Tabellen und Felder und stellt diese grafisch dar.

Anschließend lassen sich unbedeutende Tabellen ausblenden, die vorhandenen Tabellen neu auf dem Workspace positionieren und zwischen den Felder Abhängigkeiten mittels Linien herstellen. Beim Verschieben der Tabellen auf dem Workspace werden selbstverständlich auch die Verknüpfungen aktualisiert.

Neue Tabellen und Felder lassen sich problemlos einlesen, ohne dass vorhandene Verknüpfungen verloren gehen.

In der aktuellen Beta-Version werden die Tabellenpositionen zwar noch nicht an geänderte Workspacegrößen angepasst, aber ansonsten läuft das Tool angenehm stabil und speichert alle Eingaben zuverlässig ab.

Auf vielfachen Wunsch habe ich mal eine Demoumgebung für den MySQL Visualizer eingereichtet.

Mails per PHP von einer Synology Diskstation verschicken

mail() funktionert ja bekanntlich unter Synology DSM auf einer Diskstation nicht.

Relativ komfortabel kann man jedoch Mails mit dem PEAR-Mail-Paket via SMTP versenden.
Dazu sind folgende Schritte nötig:

  1. Über den Paketmanager PEAR installieren
  2. Per telnet oder ssh auf der Diskstation eine Konsole öffnen und abschicken
  3. Eine Mail per Mail verschicken:

Update für DSM6

Der PEAR-Pfad muss an zwei Stellen ergänzt werden:

1. Hauptmenü => WebStation => PHP-Einstellungen => Häkchen bei „PHP open_basedir benutzerspezifisch anpassen“ setzen und bei „opeb_basedir:“ am Ende :/volume1/@appstore/PEAR/ ergänzen

2. auf „Erweiterte Einstellungen“ klicken => Reiter „Kern“ anklicken => den Wert für „include_path“ auf „.:/volume1/@appstore/PEAR/“ anpassen und „OK“ klicken

Ggfls. muss der Webserver noch per SSH neu gestartet werden:
sudo synoservice --restart pkgctl-WebStation

WordPress per PHP direkt von wordpress.org als Zip-Datei auf Server herunterladen und entpacken

Um Prototypen für Kunden zu bauen oder auch für eigene Bastelprojekte muss ich immer mal wieder WordPress neu aufsetzen.

Bei vielen Hostern geht das heute auch als App oder Service relativ vollautomatisch, aber oftmals hat man dann nicht volle Schreibrechte in den WordPress-Verzeichnissen. Also installiere ich lieber selbst.

Da das Herunterladen auf den eigenen Rechner, das lokale Entpacken der Zip-Datei und der anschließende Upload der Daten relativ unspannend und zumindest im FTP-Transfer auch zeitaufwändig ist, lässt sich dieser Vorgang mit einem kleinen Skript weitestgehend automatisieren.

  1. aktuelle deutsche Version von WordPress als Zip-Datei mit cURL direkt auf den Server ziehen
  2. Zip-Datei entpacken
  3. Verzeichnisse und Dateien aus dem Unterordner „wordpress“ auf die aktuelle Verzeichnisebene verschieben
  4. WordPress-Installation anstoßen

Als Skript sieht das dann so aus:

Noch ein paar Worte zur Erläuterung:

  • Die Klasse ZipArchive sollte ab PHP 5.2 zur Verfügung stehen.
  • Das exec-Kommando kann bei anderen Hostern anders heißen, bspw. system etc.

 

Ein PHP-Skript unter Synology DSM per Cronjob regelmäßig ausführen lassen

In aller Kürze:

  1. Auf der Diskstation den SSH-Dienst aktivieren:
    Systemsteuerung => Terminal & SNMP => Häkchen bei „SSH-Dienst aktivieren“ setzen => „Übernehmen“ klicken
  2. Per Putty oder anderem SSH-Cilent mit der Diskstation verbinden:
    Host: diskstation (oder welchen Namen Ihr vergeben habt oder die IP-Adresse)
    User: root
    Password: Das Admin-Password
  3. Crontab bearbeiten:
    cd /etc[RETURN]
    vi crontab[RETURN]
    mit den Cursortasten an das Ende der untersten Zeile gehen
    [i] drücken, um in den Editiermodus zu gelangen
    Daten eintragen, bspw.
    0 6 * * * root curl http://127.0.0.1/ein_verzeichnis/eine_php_datei.php
    für das tägliche Aufrufen des Sripts morgens um 6 Uhr
    Die einzelnen Werte müssen mit Tabstopps getrennt werden!
    [ESC] drücken, um den Editiermodus zu verlassen
    [:][w][q] drücken, um die crontab zu speichern und den vi zu verlassen
  4. Cron neu starten:
    restart crond[RETURN]
    exit[RETURN]

Update ab DSM 6.0

Synology lässt nunmehr keinen Login auf das root-Konto zu. Stattdessen muss man sich als admin einloggen und dann vor das vi crontab[RETURN] noch ein sudo setzen. Komplett lautet der Aufruf dann
sudo vi crontab[RETURN]

Google Chrome lädt Seiten nicht oder nur unvollständig und zeigt Net::ERR_INCOMPLETE_CHUNKED_ENCODING oder net::ERR_CONTENT_LENGTH_MISMATCH in der Console an

Wenn Eure PHP-Skripte unter Google Chrome nur unvollständige oder auch gar keine Ausgaben erzeugen, liegt dies mittlerweile immer häufiger an den diversen Echtzeitschutzmodulen der Anti-Viren-Softwarepakete.

Diese scheinen erhebliche Probleme zu haben, wenn im Header keine oder eine falsche Content-Length übertragen wird. Sobald man den Echtzeitschutz temporär ausschaltet, tritt das Problem nicht mehr auf.

Dieses Problem tritt – allerdings ohne brauchbare Fehlermeldung – auch in Firefox auf.

Insbesondere wenn Inhalte dynamisch erzeugt werden und Teile bspw. per Include nachgeladen werden, ist jedoch die Content-Length vorher nicht bekannt.

Abhilfe ist relativ einfach, indem  die Ausgabepufferung aktiviert wird.

Startet ggfls. nach dem öffnenden PHP-Tag noch Eure Session und aktiviert dann die Ausgabepufferung mit ob_start(). Am Ende Eures Skripts gebt Ihr dann durch header(„Content-Length: „.ob_get_length()); die korrekte Content-Length an und gebt den Ausgabepuffer mit ob_flush(); aus.

PHP-Skript bricht ohne Fehlermeldungen ab

Ich habe kürzlich im Rahmen eines Projektes ein Skript gebaut, welches ein dynamisches HTML-Formular erzeugt. Das Formular besteht aus ca. 15.000 Zeichen und wird je nach gesetzten Werten erneut über Ajax nachgeladen.

Leider funktionierte das Nachladen nur sporadisch und ohne erkennbares Muster. Die Logfiles wiesen auf keinerlei Fehler hin und auch der Support des Hosters für das Projekt hatte keine rechte Idee, woran es liegen könnte.

Meinem Kunden kann ich aber schlecht erklären, dass seine Anwendung nur gelegentlich funktionert.

Firebug zeigte über die Konsole zwar brav, dass das Skript über Ajax aufgerufen wurde, jedoch war die Übertragung in 4 von 5 Fällen unvollständig, obwohl ein HTTP-Return-Code 200 zurückgegeben wurde. Mit 0.9 Sekunden Laufzeit war auch das Überschreiten etwaiger maximaler Skriptlaufzeiten unwahrscheinlich.

Vorsichtshalber habe ich auch den Speicherbedarf während der Verarbeitung des Skripts mitgeloggt und bei ca. 16 MB Speicherbedarf gabe es auch keine Probleme.

Schließlich habe ich mir über „Live HTTP headers“ die übertragenen Werte des Headers angeschaut und siehe da, für „Content-Length“ wurde nur der Wert 32 übertragen.

Also habe ich vor der Ausgabe des Wertes den entsprechenden Header mit

die korrekte Länge des Contents übergeben und siehe da, die Übertragung funktioniert reibungslos.