Kategorie: WordPress

Javascript-Debugging unter WordPress mit console.log beim Staging / bei Verwendung einer Testumgebung

Die Javascript-Funktion console.log() ist beim Debugging quasi unumgänglich. Allerdings möchte man in Produktivumgebungen keine Debug-Meldungen sehen.

Man kann natürlich beim Staging aus der Entwicklungs- oder Test-Umgebung jedes mal alle Aufrufe von console.log() auskommentieren oder löschen. Sofern eine Website allerdings einer ständigen Eeiterentwicklung unterliegt, ist das eher mühsam. Außerdem ist jeder manuelle Schritt beim Staging eine potentielle Fehlerquelle.

Eleganter ist es, dabei auf den Debug-Status von WordPress zurückzugreifen.

In Entwicklungs- oder Test-Umgebungen wird sich ziemlich sicher in der wp-config.php die Zeile

finden.
Während in Live- oder Produktivumgebungen hoffentlich die Zeile

vorhanden ist.

Die Konstante WP_DEBUG lässt sich beim Enqueuing des Javascripts im (Child-)Theme oder Plugin über die Lokalisierung mit übergeben:

In der Javascript-Datei muss dann nur noch console.log() in einer eigenen Funktion gekapselt werden

und einmalig “console.log( … )” durch “stableweblog( … )” ersetzt werden.

TinyMCE in WordPress per AJAX aufrufen

TinyMCE lässt sich in Plugins sehr einfach über wp_editor() aufrufen. Allerdings funktioniert das nicht, sobald der Call über AJAX erfolgt, bspw. um in einem Modal TinyMCE zu verwenden.

Abhilfe schafft der Aufruf von

nach dem Schließen des beinhaltenden Formulars.

Anschließend funktionert TinyMCE auch im Modal.

Wichtig ist dabei, das Formular erst mit

zu schließen, da ansonsten das Formular “zerschossen” werden kann.

Die Ausgaben von wp_editor() und do_action lassen sich bei Bedarf übrigens einfach abfangen, wenn bspw. das Ergebnis der AJAX-Calls in einem JSON-encoded-Array zurückgegeben werden soll:

Wie erstelle ich ein Child-Theme in WordPress?

WordPress Child-Themes sind eine prima Sache, um fertige Themes anzupassen und zu erweitern, ohne dass diese Änderungen bei einem Update des Parent-Themes verloren gehen.

Um ein Child-Theme anzulegen, wird im WordPress-Themes-Verzeichnis ein neuer Ordner mit dem Zusatz “-child” angelegt. Wenn der Ordner des Parent-Themes “xyz” heißt, wird also ein Ordner mit dem Namen “xyz-child” angelegt.

In diesem Ordner muss es mindestens zwei Dateien geben:

  • stlye.css
  • functions.php

Wichtig ist zum einen der Header in der Datei style.css mit der Zeile “Template:”:

Und zum anderen das Einbinden der Stylesheets aus dem Parent-Theme mit dem anschließenden Einbinden der Stylesheets des Child-Themes:

Anschließemd muss das Child-Theme natürlich noch aktiviert werden.

Wie kann ich aus einem WordPress-Plugin heraus auf eine andere Datenbank zugreifen

Gelegentlich möchte man auf eine andere Datenbank zugreifen als auf die, auf der WordPress läuft.

Glücklicherweise kann man sehr leicht eine neue Instanz von wpdb anlegen:

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 lassen sich in WordPress Medien aus der Mediathek in einem Plugin auswählen bzw. einfügen?

Einbinden der Skripte:

Ausschnitt aus einem tabellarischen Formular (PHP):

Passender JavaScript-Code (jQuery)

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 {} +

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.