Schlagwort-Archive: PHP

Ein Child-Theme anlegen, schnell und einfach

Jeder, der in WordPress mehr möchte, als nur fremd-produzierte Themes zu administrieren, kommt früher oder später dazu, ein Child Theme zu bearbeiten bzw. herzustellen.

Was ist ein Child Theme?

Ein Child Theme ist zunächst einmal ein Abkömmling (eben das “Child”) eines anderen Themes. Ist man mit dem bisher genutztes Theme für WordPress nicht zufrieden, ist ein Child Theme der beste Ansatzpunkt, um individuelle Lösungen einzubinden.

Das Child Theme übernimmt alle Eigenschaften des Eltern Themes – solange sie nicht im Child Theme expliziert überschrieben werden (was ja Sinn der ganzen Sache ist).

Das (Child)-Theme darf man dann ohne Gefahr manipulieren, wobei das Eltern Theme niemals angefasst wird. Dies hat mehrere Vorteile:

  1. Falls eine Änderung (vielleicht unwiederbringlich) misslingen, kann man das Child Theme einfach verwerfen und auf das Eltern Theme zurückgehen – oder einfach ein neues Child Theme anlegen.
  2. Sollte das Eltern Theme durch ein Update aufgefrischt werden, so gehen die eigenen Änderungsmaßnahmen im Child Theme nicht verloren, denn dieses Theme bleibt von Updates unberührt.
  3. Wenn man sich zwischen zwei (oder mehr) Änderungen nicht entscheiden kann, so legt man einfach weitere Child Themes an, um schnell zwischen die Änderungen hin- und herzuspringen.

Wichtige Regel daher: NIEMALS im Eltern Theme Änderungen vornehmen. NIEMALS NIEMALS NIEMALS

Was kann man im Child Theme machen?

Das child Theme bietet zwei große Gebiete, auf denen man sich nach Belieben austoben darf.

Design in Child Theme

HTML, CSS und Mediendateien

Im Child Theme darf (sollte) man den HTML Code anpassen. Aber nicht nur. Auch CSS Styles dürfen geändert werden. Ebenso liegt hier die beste Möglichkeit vor, Bilder, z.B Background-Images, oder andere Mediendateien permanent einzubinden. So erspart man sich den Umweg über den Medien-Upload von WordPress.

PHP Funktionalität

Ebenso lassen sich auch Funktionalitäten nachrüsten, die man sonst in einem extra anzulegenden Plugin speichern müsste. PHP-Code-lastige Teile des Themes kann man wunderbar in einer Datei namens functions.php auslagern, die man im Hauptverzeichnis des Child Themes anlegt.

Child Theme angelegen – Schritt für Schritt

1. Verzeichnis anlegen

  • per FTP mit dem Server verbinden
  •  im Verzeichnis wp-content/themes/ ein Verzeichnis anlegen. Dieses Verzeichnis bekannt den Namen des um die Endung -child erweiterten Namens des Eltern Themes. Heißt das Verzeichnis des Eltern Themes twentytwenty, so landet das Child Theme im Verzeichnis twentytwenty-child.
Wordpress Child Theme

2. Style Datei anlegen

Die wichtigsten Informationen über das Child Theme werden (vielleicht ungewohnterweise) in der anzulegenden Datei style.css eingefügt. Der Kopf der Datei sollte folgendermaßen aussehen:

/*
 Theme Name:   Twenty Twenty Child
 Description:  Ein Child Theme
 Author:       Clark Kent
 Author URI:   https://domain.de
 Template:     twentytwenty
 Version:      1.0
 Text Domain:  twenty-twenty-child
*/

Nicht alle diese Angaben sind verpflichtend. Lediglich zwei davon sind absolut notwendig:

Theme Name – Muss eindeutig sein.

Template – Der Verzeichnisname des Eltern Themes (hier also twentytwenty)

3. functions.php anlegen

In der Datei functions.php wird PHP Code eingebunden, der gezielt nur für dieses Child Theme zur Anwendung kommt. Zunächst einmal begnügen wir uns mit den befehlen zum Einbinden des Style Sheets der Eltern. Das Style Sheet des Child Themes wird automatisch korrekt eingebunden

<?php
/**
* Style sheets des Eltern Themes einbinden
*/
function my_child_theme_styles() {
	wp_enqueue_style( 'parent-style', get_template_directory_uri() . '/style.css' );
}
add_action( 'wp_enqueue_scripts', 'my_child_theme_styles' );
?>

Jetzt sollte unser Verzeichnis so aussehen.

Wordpress Child Theme

4. Screenshot anlegen

Ich lege gerne eine Screenshot Datei an, um bei mehreren Themes nicht die Übersicht zu verlieren. Am schnellsten geht es, wenn man die Datei screenshot.png aus dem Verzeichnis des Eltern Themes anpasst.

Wordpress Child Theme

Das Verzeichnis sieht jetzt so aus:

Wordpress Child Theme

Jetzt können wir unsere noch “nacktes” Child Theme erstmalig in WordPress auswählen.

Wordpress Child Theme

Wenn wir jetzt den Source Code unserer Seite im Browser anzeigen lassen (in der Regel mit dem Tastaturbefehl STRG+U) sollte es genau so aussehen:

Der Source Code unserer Website unter Verwendung eines Child Theme

Wie man sehen kann, werden hier die Style Sheet des Parent Themes und des Child Themes eingebunden.

Das war es für jetzt. Wir werden im Weiteren noch lernen, wie man im Child Theme eigene CSS Styles einbindet bzw. die des Eltern Themes anpasst und/oder überschreibt.

composer in 60 Sekunden installieren

Linux/Debian, PHP 5.3.2+, globale Installation

cd ~
php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
php composer-setup.php
php -r "unlink('composer-setup.php');"
sudo mv composer.phar /usr/local/bin/composer
composer #check
md /var/www/test
cd /var/www/test
sudo chmod 775 .
sudo chown www-data .
sudo chgrp www-data .
composer init --require=aws/aws-sdk-php:2.8.31 -n # oder was auch immer, man benötigt
cat composer.json #check
composer install
echo "<?php require 'vendor/autoload.php'; ?>" > index.php
sudo chown www-data index.php
sudo chgrp www-data index.php

Jetzt index.php im Browser öffnen.

Mehr Pakete finden sich unter: https://packagist.org/

Stress mit Fehlermeldung “vendor does not exist and could not be created”?

Probieren Sie das:

sudo usermod -a -G www-data `whoami` # logout und login notwendig
sudo chown root:root /var/www
sudo chmod 755 /var/www/
sudo chown -R www-data:www-data /var/www/test
sudo chmod -R 774 /var/www/test

 

Eine simple API für WordPress, Teil 1

Ich benötig(t)e eine Methode, um von ferne (remote) meine verschiedenen WordPress-Blogs betreiben zu können. Artikel, Posts etc. sollen von einer Datenbank gefüttert werden.

Dazu hat es früher einmal im Kern von WordPress eine REST-API gegeben, die aber abgeschaltet wurde. Demnächst (ab WP 4.7) soll sie wieder implementiert werden. Ich habe mir die Dokumentation des Beta-Plugins durchgelesen und finde sie wie immer viel zu lang. Es dauert ewig, bis jemand auf den Punkt kommt. Typisch doppelter Overhead der OOP-verliebten Informatiker was Code und Dokumentation betrifft.

Auch wollte ich mich nicht auf eine Beta-API verlassen, deren Schnittstellen offen vorlegen. Da kann ich die Zeit stoppen, bis die ersten Hacker sich drauf einstellen. Dann eine Lücke und zack! ist mein Blog gekapert.

Also muss eine eigene Lösung her. WordPress liefert intern alle möglichen, bequemen Methoden, um Artikel anzulegen, zu bearbeiten oder zu löschen. Mehr brauchen wir erstmal nicht. Die Kunst besteht nur darin, diese Methoden anzusprechen.

Also bauen wir uns unsere eigene API. Wir benötigen:

  1. einen Server im WordPress-Blog, der auf Kommandos wartet, diese verarbeitet und Ergebnisse zurückmeldet.
  2. einen Client, der Befehle sendet, wartet und die Antworten des Servers auswertet.
  3. und natürlich sollte der Server geschützt sein, damit er nicht gehackt wird.

Der Server

Zunächst legen wir im Hauptverzeichnis des WordPress-Webservers einen Unterverzeichnis an. Ich nenne diese Verzeichnis “maschine” – aber ihr könnt auch jeden anderen eindeutigen Namen nehmen.

md maschine

(Natürlich kann man das Verzeichnis auch per FTP anlegen, wenn ihr keine Kommandozeile öffnen könnt.)

Nun heißt es erst einmal, das Verzeichnis gegen Unbefugte abzusichern. Das geht am einfachsten mit einer .htpasswd-Datei. Diese kann man online generieren. Dann einfach nur ins Verzeichnis “maschine” kopieren.

Mit der User/Passwort-Kombination mueller/geheim sieht die Datei folgendermaßen aus:

mueller:$apr1$rgTdOKDd$3SFDZoE.N1QNkzmHXmOKe1

Aufpassen: vor dem htpasswd steht ein Punkt, das macht die Datei normalerweise unsichtbar, daher muss man das Anzeigen von versteckten Dateien im FTP-Programm aktivieren.

Nun braucht es noch eine .htaccess-Datei mit folgenden Einträgen:

AuthName "beliebig"
AuthType Basic
AuthUserFile /var/www/domain.tld/maschine/.htpasswd
require valid-user

Der Eintrag in AuthUserFile kann bei euch natürlich ein anderer sein. Wichtig ist, dass er den absoluten Pfad (vom root des Servers aus) zur eben angelegten .htasswd-Datei beinhaltet. Diesen Pfad könnt ihr bei eurem Provider erfragen oder in den FAQ nachlesen. Meist liefern die Provider auch bequeme Funktionen (Stichwort: Verzeichnisschutz) gleich mit, um alles online zu generieren.

Nun ein kleiner Test. Wir rufen im Browser auf:

http://domain.tld/maschine/

Ab jetzt steht “domain.tld” natürlich für eure eigene Domain. Jetzt müsste sofort die Abfrage nach User und Passwort erfolgen. Wenn nicht, habt ihr etwas falsch gemacht. Dann nochmal von vorn, denn Sicherheit, besonders im produktiven Bereich ist wichtig.

In Zukunft erfolgt der Aufruf natürlich automatisiert, da ist eine Passwort-Eingabe nicht möglich. Zu diesem Punkt kommen wir gleich.

Jetzt programmieren wir den einfachsten Server. Dazu legen wir eine Datei “index.php” im Verzeichnis “maschine” an, die demnächst unsere Befehle verarbeitet.

<?php
header('Content-Type: text/html; charset=utf-8');
if (isset($_GET['befehl'])) $befehl=$_GET['befehl'];
if (isset($_POST['befehl'])) $befehl=$_POST['befehl'];
print mb_strtoupper($befehl);
exit();
?>

Wir nutzen die multibyte-fähigen Funktionen, die man am Präfix “mb_” erkennt, damit wir später keine Probleme mit Umlauten haben. Unseren kleinen Server kann man schon per Get-Parameter in der URL oder per Post (bspw. bei Formulareingaben) bedienen. Zurückgegeben wir ein einfacher utf8-kodierter Text. Das ist für unsere Belange absolut ausreichend und bietet bessere Debug-Möglichkeiten.

Was macht der Server? Er nimmt einen Parameter (Hier “befehl”) auf und wandelt den String in Großbuchstaben um. Das ist natürlich ein wenig sinnfrei, aber wir wollen ja erstmal testen.

Wir rufen also im Browser auf:

http://mueller:geheim@domain.tld/maschine/?befehl=hallo

Mit den Angaben vor dem “@” kann man User und Passwort gleich in der URL übergeben und muss diese nicht immer extra eingeben. Und wenn alles geklappt hat, müsste im Browser der Text “HALLO” erscheinen.

Der Client

Jetzt geht es an einen kleinen, ersten Client. Wir legen eine Datei an, der Name ist egal, ich nenne sie “client.php”. Diese Datei kann irgendwo angelegt sein, sinnvollerweise nicht auf dem selben Server, auf dem unser API-Server läuft, denn sonst wäre die Arbeit ja sinnlos.

<?php
$username='mueller';
$password='geheim';
$serverurl='http://domain.tld/maschine/';
$befehl="hallo nochmal äöüß";

$postdata = http_build_query(
array(
'befehl' =>&nbsp;$befehl
)
);

$auth = base64_encode($username.':'.$password);
$header = array("Authorization: Basic $auth",
	'Content-type: application/x-www-form-urlencoded'
	);

$opts = array('http'&nbsp;=>
array(
'method' =>&nbsp;'POST',
'header' =>&nbsp;$header,
'content' =>&nbsp;$postdata,
'timeout' =>&nbsp;5000
)
);

$context = stream_context_create($opts);
$result = file_get_contents($serverurl, false, $context);

header('Content-Type: text/html; charset=utf-8');
print $result;
exit();
?>

Das sieht schon etwas komplizierter aus. Im Grunde simulieren wir das, was wir vorhin im Browser händisch gemacht haben: Wir packen Daten zusammen (hier nur $befehl), authentifizieren uns am Server und geben die Rückgabe wieder aus.

Zeile 2+3 sind selbsterklärend. WICHTIG: Ohne das abschließende Slash in Zeile 4 wird es nicht funktionieren – also nicht vergessen.

Zeile 5 beinhaltet den “Befehl”, den wir absenden, wieder erstmal nichts besonderes.

Der Rest der Zeilen dient dazu, einen Stream zu generieren und damit das PHP-Skript zu einem kleinen Browser zu machen.

Zeile 21 legt einen Timeout in Millisekunden fest. Da die meisten Hoster nur 30 Sekunden an Ausführungszeit für ihre Skripte zulassen, lohnen sich Werte über 30 Sekunden gar nicht erst, denn der Server wird bereits vorher abbrechen.

Wir machen den Test und rufen den Client im Browser auf:

http://localhost/client.php

Etwas smarter, bitte!

Nun ist es auf Dauer etwas unbefriedigend, immer nur $befehl=blabla an den Server zu senden, daher machen wir jetzt die Datenübermittlung etwas smarter. Und zwar so, dass im Prinzip alles gesendet und empfangen werden kann, solang wir es in Variablen verpacken können.

Dazu passen wir zunächst den Client an:

Zeile 5 wird zu:

$werte_array=array(3, 'Test äöü', 'farbe' => 'rot');

und Zeile 9 zu:

'werte_array' => serialize($werte_array)

Und der Server wird auch angepasst.

Die Zeilen 3, 4 und 5 werden zu:

if (count($_GET)>0) $werte_array=unserialize(array_shift($_GET));
if (count($_POST)>0) $werte_array=unserialize(array_shift($_POST));
print_r ($werte_array);

Welchen Sinn hat das? Wir packen alle Variablen, die wir übertragen wissen wollen, in ein Array, serialisieren es mit serialize und packen es auf der anderen Seite wir mit unserialize wieder aus. Der Name des zu transportierenden Arrays spielt dabei keine Rolle; array_shift ermittel automatisch das richtige Array.

Später werden wir serialize auch nutzen, um mehr als nur ein simples “Hallo Welt” an den Client zurückzuliefern. Aber fürs erste sollte das genügen.

Wir fassen zusammen

Server

<?php
header('Content-Type: text/html; charset=utf-8');
if (count($_GET)>0) $werte_array=unserialize(array_shift($_GET));
if (count($_POST)>0) $werte_array=unserialize(array_shift($_POST));
print_r ($werte_array);
exit();
?>

Client

<?php
$username='mueller';
$password='geheim';
$serverurl='http://domain.tld/maschine/';
$werte_array=array(3, 'Test äöü', 'farbe' => 'rot');

$postdata = http_build_query(
array(
'werte_array' =>&nbsp;serialize($werte_array)
)
);

$auth = base64_encode($username.':'.$password);
$header = array("Authorization: Basic $auth",
	'Content-type: application/x-www-form-urlencoded'
	);

$opts = array('http'&nbsp;=>
array(
'method' =>&nbsp;'POST',
'header' =>&nbsp;$header,
'content' =>&nbsp;$postdata,
'timeout' =>&nbsp;5000, //5 Sekunden
)
);

$context = stream_context_create($opts);
$result = file_get_contents($serverurl, false, $context);

header('Content-Type: text/html; charset=utf-8');
print $result;
exit();
?>

Wenn wir jetzt den Client wieder aufrufen:

http://localhost/client.php

erhalten wir:

Array ( [0] => 3 [1] => Test äöü [farbe] => rot )

Und mehr benötigen wir für heute nicht. Der Server hat also das Array richtig empfangen.

Im nächsten Teil werden wir dann unseren kleinen Server dazu nutzen, um einen WordPress-Artikel anzulegen.

Quick: SquirrelMail und XAMPP lokal installieren und testen

Quick: SquirrelMail und XAMPP lokal installieren und testen

Wer Applikationen programmiert, die auch Mails verschicken, möchte dies natürlich auch lokal testen. Dazu lohnt es sich, den Webmail Client »SquirrelMail« zu installieren. Dieser Artikel ergänzt mein XAMPP-Tutorial.

1. laden http://squirrelmail.org/download.php

2. entpacken nach »c:\Programme\xampp\htdocs\squirrelmail\« und anlegen von »c:\Programme\xampp\htdocs\squirrelmail\attach\«

3. kopieren der Konfigurationsvorlage »c:\Programme\xampp\htdocs\squirrelmail\config\config_default.php« nach »c:\Programme\xampp\htdocs\squirrelmail\config\config.php«

4. editieren von »c:\Programme\xampp\htdocs\squirrelmail\config\config.php«


$domain = 'localhost';

$data_dir = 'c:\\Programme\\xampp\\htdocs\\squirrelmail\\data\\';

$attachment_dir = 'c:\\Programme\\xampp\\htdocs\\squirrelmail\\attach\\';

$imapServerAddress = 'localhost';

$smtpServerAddress = 'localhost';

5. Testen

User anlegen in Mercury. In der Admin-Oberfläche: Configuration|Manage Local Users…|Add einen User anlegen. User in Mercury meint die eigentlichen Mail-Empfänger.

Einwählen: http://localhost/squirrelmail/src/login.php

Name: Username (ohne @localhost)

Passwort: (wie festgelegt)

Mail zusenden: http://localhost/xampp/mailform.php (Adressat=Ihr neuer Nutzer PLUS @locahost). Die Mail müsste augenblicklich in SquirrelMail erscheinen, eventuell müssen Sie noch »Check mail« klicken.