Archiv der Kategorie: Tutorial

Eine simple API für WordPress, Teil 2

Wir kommen nun dazu, mit Hilfe unserer kleinen API einen WordPress-Artikel anzulegen.

Dazu müssen wir uns kurz mit den internen Funktionen beschäftigen, die WordPress für dieses Unterfangen zur Verfügung stellt.

Es ist zunächst die Funktion „wp_insert_post„.

wp_insert_post( array $postarr, bool $wp_error = false )

Mit ihrer Hilfe kann man Artikel (oder auch Seiten) anlegen und bearbeiten.

Es gibt viele Parameter. Wir betrachten zunächst die wichtigsten:

  • post_content – der Inhalt des Artikels
  • post_title – die Überschrift des Artikels
  • post_status – der Status des Artikels und

Stellen wir uns ein simples Array zusammen:

$postarr => array(
	'post_content' => '<p>Das ist ein <b>Test äöüß</b><br>Und noch eine Zeile</p>',
	'post_title' => 'Meine erste Überschrift',
	'post_status' => 'publish'
	)

Die Werte sollten sich von selbst erklären. Ich empfehle, wenn immer möglich beim Testen Umlaute zu nutzen, um später keine bösen Überraschungen zu erleben.

Ich setze „post_status“ auf „publish„, da ich die Artikel sofort veröffentliche. Wer aber noch händisch nachkontrollieren oder erstmal sichergehen möchte, der setzt „post_status“ auf „draft„.

Der neue Client

Der Client muss entsprechend angepasst werden.

<?php
$username='mueller';
$password='geheim';
$serverurl='http://domain.tld/maschine/';
$postdata_array=array(
	'function' => 'wp_insert_post', 
	'wp_post_array' => array(
		'post_content' => '<p>Das ist ein <b>Test äöüß</b><br>Und noch eine Zeile</p>',
		'post_title' => 'Meine erste Überschrift',
		'post_status' => 'publish'
		)
	);

$postdata = http_build_query(
	array(
		'postdata_string' => serialize($postdata_array)
	)
);

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

$opts = array('http' =>
	array(
		'method'  => 'POST',
		'header'  => $header,
		'content' => $postdata,
		'timeout' => 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();
?>

Der Aufbau hat sich nicht sehr gegenüber Teil 1 verändert.

Der neue Server

Beim Server hat sich ein wenig mehr getan.

<?php
define('WP_USE_THEMES', false);
header('Content-Type: text/html; charset=utf-8');
if (count($_GET)>0) $postdata_array=unserialize(array_shift($_GET));
if (count($_POST)>0) $postdata_array=unserialize(array_shift($_POST));

require('../wp-load.php');

if ($postdata_array['function']=='wp_insert_post') {
	print wp_insert_post($postdata_array['wp_post_array']);
}
exit();

Wir müssen nun die Verbindung unseres Servers zu WordPress herstellen. Das passiert ganz einfach durch die Zeile:

require('../wp-load.php');

Die Datei „wp-load.php“ die sich im Hauptverzeichnis des Blogs befindet, stellt automatisch alle Daten und Komponenten zur Verfügung, die wir für den Umgang mit WordPress benötigen.

Die Zeile:

define('WP_USE_THEMES', false);

Sorgt noch dafür, dass wir keine Komponenten laden, die lediglich für das Frontend des Blogs benötigt werden.

Der Rest dürfte sich von selbst erklären. Interessant ist Zeile 10, in der der eigentliche Befehl zum Anlegen ausgeführt wird und als Ergebnis die ID des neuen Artikels (WordPress-Jargon: Post) an den Client zurückgegeben wird. Diese ID ist wichtig und sollte irgendwo auf Seiten des Clients gespeichert werden, denn später werden wir sie benötigen, um Artikel zu korrigieren, zu löschen oder mit anderen Daten anzureichern. Die ID ist immer eindeutig und wird niemals doppelt vergeben.

Rufen wir den Client auf:

http://localhost/client.php

Das Ergebnis gibt uns die ID 4025 zurück.

Und schauen wir mal ins Backend des Blogs.

Voilà – Das ist unser Artikel.

Bis dahin war es noch nicht ganz so schwer. Bisher hatten wir nur die Pflicht, jetzt folgt die Kür. Im nächsten Teil werde ich zeigen, wie man dem Artikel auch ein Bild zuordnet.

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.

Und es geht doch: Linux, Skript ausführen beim Herunterfahren

Geradezu abenteuerlich sind die Aussagen einiger selbsternannter Experten beim Thema „Skripte ausführen beim Herunterfahren“. Von „Linux fährt man nicht herunter“ bis zu „ist überhaupt nicht möglich“ habe ich alles schon lesen dürfen.

Dabei ist es ganz einfach. Ich benutze diese Methode auf meiner virtuellen Entwicklungsmaschine, um Dateien und Datenbanken nach einem Arbeitstag auf dem Host zu sichern.

Hier also meine schnelle: „Klicken-und-vergessen“-Methode für

  • Oracle VM VirtualBox Manager
  • Host: Windows 7 64 Bit
  • Gast: Ubuntu Linux 14.04.1 – 64 Bit (Hostname: minlux)
  • Netzwerk: AVM FRITZ!Box 7390, Host über WLAN verbunden

Die auszuführenden Dateien befinden sich in /etc/init.d/.

Wir legen ein Skript an, das nichts anderes macht, als eine leere Datei namens goodbye.txt ins Home-Verzeichnis des Users zu schreiben. Das Skript, das das erledigen soll, erhält den Namen custom-shutdown.sh.

echo -e '#!/bin/sh\ntouch /home/'$USER'/goodbye.txt' | sudo tee /etc/init.d/custom-shutdown.sh

Wir machen die Datei ausführbar:

sudo chmod +x /etc/init.d/custom-shutdown.sh

Prüfen, ob alles geklappt hat:

ls -l /etc/init.d/custom-shutdown.sh
cat /etc/init.d/custom-shutdown.sh

Nun legen wir in /etc/rc0.d/ einen Link zum Skript. Beachte: das Präfix K04 vor dem Dateinamen, ohne das geht es nicht.

sudo ln -s /etc/init.d/custom-shutdown.sh /etc/rc0.d/K04custom-shutdown.sh

Fertig. Nun starten wir die Maschine neu

sudo reboot

Test, ob goodbye.txt auch wirklich angelegt wurde:

ls -l ~

Man beachte, dass die Datei für den Nutzer root angelegt worden ist, falls man noch irgendetwas damit plant.

Skript beim Hochfahren ausführen

Wer möchte, kann Skripte auch ausführen lassen beim Hochfahren des Rechners. Dann muss der Link aber nicht in rc0.d sondern in rc6.d platziert werden.

echo -e '#!/bin/sh\ntouch /home/'$USER'/hello.txt' | sudo tee /etc/init.d/custom-start.sh
sudo chmod +x /etc/init.d/custom-start.sh
sudo ln -s /etc/init.d/custom-start.sh /etc/rc6.d/K04custom-start.sh

WICHTIG: Server neu starten

Wenn man Datenbanksicherungen beim Herunterfahren anlegen möchte, so muss man natürlich beachten, dass die Datenbank schon längst selbst heruntergefahren ist. Also muss man diese kurz wieder starten:

#!/bin/sh
date >> /media/sf_share/shutdown.log # das ist mein geteiltes Verzeichnis mit dem Host
sudo /etc/init.d/mysql start # hier wird MySQL wieder gestartet
exec /etc/webmin/mysql/backup.pl --all >> /media/sf_share/shutdown.log # mit Hilfe eines Webmin-Skriptes wird das Backup angestoßen
sudo /etc/init.d/mysql stop # und hier müssen wir MySQL natürlich wieder sauber beenden

Mein Dank geht an http://ubuntu.flowconsult.at/linux/ubuntu-14-10-shutdown-script-with-rc0-d-rc6-rcd/ und https://unix.stackexchange.com/questions/34963/running-script-before-shutdown-seemingly-not-working. Mehr Informationen zum Runlevel: https://en.wikipedia.org/wiki/Runlevel#Ubuntu

WordPress: Send Administrator E-Mails to all you users with Email Users 2 Plugin (Emu2)

Tested with WordPress 3.2.1!

Now schedule your mails.

WordPress: Send email to users, manually or on schedule (digest of newest posts). Users can send emails to each other. Export function included. A plugin for wordpress which allows you to send an email to the registered blog users. Users can send personal emails to each other. Power users can email groups of users and even notify group of users of posts. With ability to schedule mails of the newest post in digest form.

STILL BETA!!!

Download from WordPress repository

FAQ

Do you have other plugins?

Check out my other WordPress Plugins.

My provider/host/server does not seem to work with your plugin

OK, there are some administrator outside which treat their services very strict. Mass mailing can always be misused for spamming. That’s why you should ask your admin for current restrictions on mail sending. Pass their answers to me. And by the way, if you are starting a serious business than you should not put your website on a cheap mass web host without any personal support.

Problems with automatic sending. Why are some mails send by the hour instead daily or even three times in a row?

The build in scheduler of WordPress which I use in this plugin is not 100% reliable. This seems to be a bug. It’s already an issue in the bug tracking system of the WordPress developers. Have a look: http://core.trac.wordpress.org/. Emu2 is still beta. If you don’t want to get into trouble with your users I advice you to turn this automatic function off until the bug is fixed.

How can I give certain users the ability to use EMU2?

Scroll down in settings menu and you will find the different capabilities. You can assign them to different roles, hence to your users. I would advice you to use the plugin [User Role Eitor].

Where do I post my feedback?

Here

How can I support you?

That is nice of you. Donation link: https://1manfactory.com/donate

Will there ever be a real manual?

I don’t know. Maybe.

Changelog

0.83b (23.11.2011)

  • adding spanish version – Thanks to Pablo Olave from Chile

0.82b (06.07.2011)

  • tested with WordPress 3.2 -> ok
  • fixed HTML link problem in visual editor

0.81b (10.06.2011)

  • not sending empty mail without digest
  • sending success mail to admin

0.80b (09.06.2011)

  • NEW: Schedule a digest mail of the newest posts
  • Put sender into to field when sending problems (optional)
  • editing of templates moved to additional section

0.73b (30.05.2011)

  • Bugfixing on sending of test mails

0.72b (30.05.2011)

  • Test with WordPress 3.1.3 -> ok
  • Bugfixing on missing Url information in sent mails
  • changed default values from 0 to NULL to prevent possible errors

0.71b (24.04.2011)

  • enhancing administration of user capabilities

0.70b (16.04.2011)

  • some bug fixing with invalid from field values
  • bcc limit variable
  • choose your own sender name and address
  • more translations

0.65b (07.04.2011)

  • setting Return-Path
  • setting Message-Id

0.64b (05.04.2011)

  • implementing debug mode
  • tested with WordPress 3.1

0.63b (09.02.2011)

  • tested with WordPress 3.0.5
  • additional translation

0.62b (04.02.2011)

  • Translation of user roles

0.61b (04.02.2011)

  • Debug Info in subject line removed (sorry for that)

0.60b (03.02.2011)

  • UTF-8 Bug with german Umlauts fixed
  • Ability to chose between server mail function and wordpress mail function
  • new icon

0.54b (02.02.2011)

  • Solving Dashboard Folding Bug

0.53b (02.02.2011)

  • Some new translating.
  • Improving Error messages when using different roles

0.52b (01.02.2011)

  • fixed redeclare of function error

0.50b (27.01.2011)

  • using build in wordpress function so sent mail
  • adding screenshots
  • translation update
  • now with traceless deinstallation routine

0.42b (26.01.2011)

  • HTML-Editor: fixing problems with media upload

0.41b (26.01.2011)

  • Fixing small HTML-Editor bug

0.40b (22.01.2011)

  • Using HTML-Editor (TinyMCE)
  • Fixing small mail sending bug
  • making screenshots

0.32b (10.01.2011)

  • UTF-8

0.31b (10.01.2011)

  • PLEASE UPDATE!!!

0.3b (10.01.2011)

  • PLEASE UPDATE!!!
  • wrong folders

0.2b (10.01.2011)

  • first version, please test before productive using
global $qrcodetag; echo $qrcodetag->getQrCodeUrl($content, $size, $encoding, $ecc, $margin, $version);

Unbekannte Zeichensätze finden mit „WhatTheFont“

Heute war ich auf der Suche nach einem bestimmten Zeichensatz.

Leider hatte ich nur ein Bild von der Schrift aus dem Internet.

Und da habe ich WhatTheFont entdeckt.

Dort lädt man einen möglichst genauen und scharfen Ausschnitt des Textes als Bild hoch, kontrolliert, ob die Zeichen auch korrekt erkannt worden sind. Und am Ende spuckt die Website möglichst gut passende Zeichensätze raus.

Was will man mehr?