Kategorie: WordPress

Borlabs Cookies zeigt „Ihre Website verwendet keine SSL-Zertifizierung.“ an, obwohl SSL aktiviert ist

Wenn Borlabs Cookies „Ihre Website verwendet keine SSL-Zertifizierung.“ anzeigt, obwohl SSL aktiviert ist, kann das einen relativen einfachen Grund haben, der – ebenso wie das Problem der WPML typischen Konstante “ICL_LANGUAGE_CODE” – trotzdem mehr als ärgerlich ist.

Borlabs Cookies wertet interessanterweise offensichtlich die Konstante WP_CONTENT_URL aus, um zu bestimmen, ob SSL aktiv ist bzw. die Seite über https ausgeliefert wird. Das Setzen von
define( 'WP_CONTENT_URL', '/wp-content');
ist jedoch alles andere als unüblich; insbesondere wenn eine Seite unter einer Entwicklungsdomain gebaut wird und später umzieht. Mal davon abgesehen, dass die Media-Pfade daduch deutlich kürzer werden.
Es reicht also, die Definition in der wp-config.php auszukommentieren.

Es ist natürlich so, dass eine URL, in diesem Fall die WP_CONTENT_URL, aus Protokoll, Host und Pfad bestehen sollte. Gelebt wird es bzgl. WP_CONTENT_URL jedoch meist anders.

Sollte das Content-Verzeichnis tatsächlich nicht in /wp-content/ liegen, ist WP_CONTENT_URL ggfs. mit Protokoll und Domain zu definieren.

Borlabs Cookie meldet den Fehler „Ihre Sprachkonfiguration ist defekt.“

Sofern man WPML für die Mehrsprachigkeit auf einer WordPress-Instanz im Einsatz hatte und WPML deinstalliert, kann es durchaus sein, dass man im eigenen Code die für WPML typische Konstante „ICL_LANGUAGE_CODE“ abfragt und auch selbst setzt, falls sie nicht vorhanden ist, um den eigenen Code unabhängig von WPML lauffähig zu halten.

Sofern man „ICL_LANGUAGE_CODE“ im eigenen Code gesetzt hat und WPML nicht mehr im Einsatz ist, stehen die Chancen sehr gut, dass Borlabs Cookie den Dienst – teilweise – verweigert.

Der Grund dafür ist, dass Borlabs Cookie bei Vorhandensein der Konstante „ICL_LANGUAGE_CODE“ davon ausgeht, dass WPML installiert ist.

Bei Einsatz bspw. in der functions.php des (Child-)Themes erscheint dann vermutlich im Backend die Fehlermedlung „Ihre Sprachkonfiguration ist defekt. Deaktivieren Sie alle Plugins außer Borlabs Cookie, bis diese Meldung verschwindet. Wenn Sie das Plugin gefunden haben, das diesen Fehler verursacht, überprüfen Sie, ob ein Update verfügbar ist, und installieren Sie es.“.
Darüber hinaus lassen sich vermutlich keine Cookie im Backend anlegen. Stattdessen gibt es die Fehlermeldung „Die ausgewählte Cookie Gruppe existiert nicht.“.

Die Lösung ist realtiv einfach. Statt „ICL_LANGUAGE_CODE“ setzt man eine eigene Sprachkonstante und gleicht diese nur bei Vorhandensein mit „ICL_LANGUAGE_CODE“ ab.

Sofern man „ICL_LANGUAGE_CODE“ in den Template-Files einsetzt, gibt es vermutlich keine Fehlermeldung. Allerdings kann es passieren, dass weder die Cookie-Gruppen in der Cookie Box angezeigt werden, noch dass die optischen Anpassungen der Cookie Box greifen.

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 werden sich ziemlich sicher in der wp-config.php die Zeilen

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

vorhanden sind.

Man ergänzt jetzt diesen Abschnitt einfach um eine weitere Konstante:

Die Konstante WP_DEBUG_JS 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 „stablew_eblog( … )“ ersetzt werden.


Exkurs: Relative URLs für Medien für einfacheres Migrieren von der Test- in die Live-Umgebung

Wenn man schon an der wp-config.php dran ist, kann man auch gleich noch dafür Sorge tragen, dass Medien mit relativen URLs verarbeitet 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.