Remote Bypass API – A wordpress API plugin

I was in need of a remote API to access my WordPress blog for writing, updating, deleting etc. of my posts driven by MySQL statements.

I tried to make head or tails out of the official Rest API plugin but got annoyed by too much overhead and stuff to learn. I needed a solution NOW!

So I decided to program my own server API to suite my needs.

It’s pretty easy to handle. You can use every build in WordPress function as you are used to.

The server is secured by apache’s basic authentication (.htpasswd/.htaccess). Communication is encrypted by SSL (if installed). There is also a checksum to make sure that no bit of the command is lost during sending.

All you have to do is download the automatically generated small client code which includes the function „call_server„. This function will send your command to the API server and wait for the result(s) coded in a handy json generated string.

Example:

This will call the server. Parameters are name of function („get_users„) and an argument’s array as defined in https://codex.wordpress.org/Function_Reference/get_users.

This is the result in the brower’s source code view:

See, this plugin bypasses the WordPress function, hence the name.

DOWNLOAD

Use at your own responsibility. No guarantee, no support.

remote-bypass-api

Changelog

  • 0.4. (2017-02-15) (API Version 4)
    • hiding and randomizing basefolder
    • now accepting all kind of parameter arrays
  • 0.3 (2017-02-15) (API Version 3)
    • now handles pure strings as arguments as well
  • 0.2 (2017-02-11) (API Version 2)
    • checksumm check
    • Communication between client and server is crypted when ssl
  • 0.1 (2017-02-11) (API Version 1)
    • first version.

Eine simple API für WordPress, Teil 4

Wir wissen jetzt, wie wir mit Hilfe unserer kleinen API einen Artikel anlegen und wie wir ihn mit einem Bild versorgen. Nun fügen wir einige Metadaten hinzu. Dazu benötigen wird die Funktion „add_post_meta„. Diese verlangt folgende Parameter:

  • post_id – Die eindeutige Artikel-ID aus Teil 2
  • meta_key – Der Name des Metadaten-Feldes
  • meta_value – Der Wert des Metadaten-Feldes

Wir packen also wieder einen Befehlsaufruf für unseren Server zusammen:

Und natürlich müssen wir auch unseren Server wieder ein wenig ergänzen.

Diese 3 Zeilen erweitern unseren Server um die Fähigkeit, mit Hilfe der Funktion „add_post_meta“ Artikel mit beliebigen Metadaten zu versorgen.

Und so sieht dann das neue benutzerdefinierte Feld aus.

Zusammenfassung

Server

Client

 

Eine simple API für WordPress, Teil 3

Kommen wir nun zum wichtigen Thema: Wie füge ich dem Artikel ein Bild bei?

Auch das wird in vielen Beiträgen im Internet gerne angerissen, aber mal ein paar schnelle, praktikable Lösungen werden selten präsentiert. Dabei ist es nicht so schwer, wenn man weiß, was zu tun ist.

Der Ablauf

Im Grunde müssen folgende Schritte abgearbeitet werden:

  1. Wir erzeugen einen Artikel und merken uns die ID (siehe Teil 2)
  2. Wir laden ein Bild per FTP auf den WordPress-Server
  3. Wir verbinden Artikel und Bild mit Hilfe der Funktionen: wp_generate_attachment_metadatawp_insert_attachment und set_post_thumbnail

Damit das funktioniert, müssen wir unseren Server gleich zweimal bemühen: Beim Erzeugen des Artikels und beim Verbinden des Bildes mit ersterem.

Der Upload per FTP

Keine Angst, das ist per PHP einfacher, als man denkt.

Zunächst benötigen wir auf dem WordPress-Blog einen Zielordner. Den kann man per Konsole oder FTP anlegen:

Auf diesen Server werden die Bilder (oder was immer man später mit den Artikeln verknüpfen möchte: ZIP-File, E-Book, PDF etc.) zwischengespeichert. Man sollte darauf achten, dass die Dateinamen dabei immer einzigartig sind, denn sonst werden sie gnadenlos überschrieben. Erreichen kann man das z.B. durch eine Ergänzung mit einer Time-id und einer laufenden Nummer.

Wir erweitern den Client um einige Zeilen:

Damit wird die Datei „bild.jpg“ vom lokalen Verzeichnis „/var/upload/bilder/“ auf das entfernte Verzeichnis „/var/www/domain.tld/wp-content/uploads/maschine/“ des Servers „domain.tld“ kopiert. Wenn Sie nicht wissen, wie das entfernte Verzeichnis lautet, fragen Sie ihren Provider.

Bevor wir nun an den Client gehen, packen wir dessen Kernaufgabe in eine Funktion, damit wir sie mehrfach benützen können.

Diese Funktion sendet ein Array an unseren Server und gibt dessen Antwort wieder zurück.

Die Aufgaben des Servers werden jetzt erweitert. Er kann nicht nur Artikel anlegen, sondern auch Bilder verarbeiten. Das geschieht durch folgende Zeilen:

Zeile 1 ermittelt den Mime-Type der Datei (hier: „image/jpeg“), das Array mit den Meta-Daten (Titel, eindeutiger Bezeichner etc.) wird automatisch gefüllt. Natürlich können Sie den Titel des Bildes auch aus den eigenen Daten erzeugen.

Zeile 10 fügt dann das eben hochgeladene Bild der Mediendatenbank des Blogs hinzu. Von nun an finden Sie das Bild dort, aber es ist noch nicht mit einem Artikel verbunden. Das erledigen wir gleich.

Zeile 12 versorgt das Bild in der Mediendatenbank mit den soeben festgelegten Metadaten und legt die einzelnen Vorschaubilder in den verschiedenen Größen an, die in den Medien-Einstellungen von WordPress festgelegt sind.

Zeile 14 macht die Magie: Das Bild wird mit dem Artikel verbunden.

Zusammengefasst

Der Server

Der Client

Das war ja nicht so schwer, wenn man weiß, wie es geht – aber das gilt wohl für alles im Leben. Im nächsten Schritt lernen wir, unseren Artikel nachträglich mit Daten anzureichern.

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„.

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:

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.

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

Der neue Server

Beim Server hat sich ein wenig mehr getan.

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

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:

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:

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.

ssdeep Funktionen für PHP installieren

Wer folgende ssdeep-PHP-Funktionen

  • ssdeep_fuzzy_compare
  • ssdeep_fuzzy_hash_filename
  • ssdeep_fuzzy_hash

nutzen möchte, der muss sie zunächst für PHP installieren. Dazu werden verschiedene Pakete und Bibliotheken benötigt. Ich skizziere hier einmal den Schnelldurchgang.

Die Funktionen selbst sind hier beschrieben: http://php.net/manual/en/ref.ssdeep.php

Search and replace inside zip with PHP

Ever wanted to search and replace inside a zip container with PHP?

WordPress Quick: Place addthis manually

You like the addthis plugin for WordPress? But prefere to place it manually?

Open your template file, e.g. „single.php“, and place this where you want:


<?php do_action( 'addthis_widget', $url, $title, 'share_counter');? >

You can replace „share_counter“ with any other stile you like. It’s just the button style I like most.

XAMPP – Entwicklungsumgebung für Apache, MySQL, PHP auf Windows – Tutorial

XAMPP ist eine Distribution von Apache, MySQL, PHP und Perl, die sich (fast) per Knopfdruck installieren und wenig Wünsche übrig lässt.

Ich zeige hier eine kleine Anleitung, die ich selbst auch nutze bei Neuinstalationen. Den Abschluss bildet eine Sammlung von Links Hinweisen zu nützlichen Ergänzungen.

Schritt 1 – Installation

Xampp-Home Xammp-Windows

Ich empfehle die EXE-Datei. Wir können beruhigt nach c:\programme\xampp installieren. Es ist nicht notwendig, dass C-Verzeichnis vollzumüllen. Alle Programme und zusätzliche »Addons« laufen dort problemlos: Eine Fehlermeldung (»xampp component status check failure«) beim Aufruf des XAMPP Control Panel kann ignoriert werden. Wen diese Meldung nervt, kann Folgendes tun:

  1. Registry Editor starten und den Schlüssel
  2. HKEY_LOCAL_MACHINE\SOFTWARE\xampp\Install_Dir aufrufen
  3. Den dort eingetragenen Wert ändern zu: »C:\xampp«. Damit sollte die unglückselige Fehlermeldung nicht mehr auftauchen.

Die Meldungen der Firewall sollten sie akzeptieren, sonst tauchen Sie immer wieder auf. Warum die Firewall von Microsoft Zugriffe auf den eigenen Rechner unterbindet, kann wohl nur Bill Gates selbst erklären.

Schritt 2 – Es geht los

Wir starten das XAMPP Control Panel. Die Funktionen dort sollten selbsterklärend sein. Wenn man die wichtigsten Komponenten Apache und MySQL gestartet hat, kann man das Control Panel in den Hintergrund bzw. in die Systray wegklicken.

Die Konfiguration von XAMPP und seinen Komponenten erfolgt in verschiedenen Konfigurationsdateien. Eine Auflistung findet sich weiter unten.

Wir prüfen jetzt, ob alles erstmal geklappt hat. Dazu starten wir Apache, MySQL und Mercury. Mercury ist ein Mailserver, den man nicht unbedingt braucht, aber die Funktionsfähigkeit sollte wenigstens einmal getestet werden.

Nehmen Sie ihren Browser und laden Sie die URL »http://localhost«. »Localhost« ist eine Abkürzung für ihren eigenen Rechner bzw. für die Adresse ihres eigenen Rechners. Sie können auch »http://127.0.0.1« eingeben.

Wenn der erste Aufruf erfolgreich war, dann würde ich jetzt einige Änderungen in der php.ini (der Konfigurationsdatei für den PHP-Interpreter) vornehmen. Die Datei befindet sich unter »C:\Programme\xampp\php\php.ini«.

Passen Sie dort an bzw. entkommentieren folgendes:

  • short_open_tag = On
  • extension=php_curl.dll
  • variables_order = „EGPCS“
  • error_reporting = E_ALL

Damit die Änderungen Wirkung zeigen, muss Apache natürlich neu gestartet werden. Das erledigen Sie über das Control Panel.

Sie sollten auch nicht vergessen, den Sicherheitscheck auszuführen. Die Punkte dort sind selbsterklärend. Im Allgemeinen sollte es aber reichen, wenn Sie für MySQL einen root-Nutzer anlegen.

Schritt 3 – Warm werden mit XAMPP

Einige wichtige Standardprogramme bzw. Webapplikationen werden schon mitgeliefert. Am Anfang dürfte das wichtigste wohl phpMyAdmin sein. Hierbei handelt es sich um den am weitesten verbreiteten Web-Client zur Verwaltung von MySQL-Servern. Bei XAMPP wird er gleich mit ausgeliefert http://localhost/phpmyadmin/.

Den »root«-Nutzer sollte man tunlichst nur nehmen, um Datenbanken oder neue Nutzer anzulegen. Für neue Projekte, bspw. WordPress, erzeugt man einen Nutzer und wählt die Option »Erstelle eine Datenbank mit gleichem Namen und gewähre alle Rechte«.

Schritt 4 – Einrichtung des Mailserver Mercury

Diesen Mailserver kann man nutzen, wenn man Applikationen schreibt, die Mails verschicken, z.B. Newsletter. Allerdings ist dieser Server – wie das gesamte XAMPP-Projekt auf Windows – nur für Entwicklungsumgebungen ausgelegt. Auf Produktivsystemen sollte man m.M. nach lieber auf Linux bzw. LAMPP zurückgreifen.

Bei richtiger Programmierung sollte man ohne Probleme alle Skripte in PHP auf allen System, egal ob Windows mit Internet Information Server (IIS) oder Linux mit Apache nutzen können.

Den Admin-Bereich von Mercury erreicht man über den Admin-Button in XAMPP Control Panel. Hier gehen wir folgende Schritte durch:

  1. Mercury-Webserver deaktivieren: Mercury|Configuration|Protocol Modules|MercuryB HTTP Haken entfernen und Mercury Neu starten
  2. Configuration|Mercury Core Modul|General Internetname for this system: localhost
  3. local mailbox directory path: C:\PROGRAMME\XAMPP\MERCURYMAIL\MAIL\~N
  4. Username of Postmaster: Admin
  5. Configuration|Mercury Core Modul local domains: localhost, localhost.net, localhost.com, localhost.org
  6. Configuration|Mercury Core Modul|General: Suppress validation of »FROM« field (Haken setzen)
  7. Configuration|MercuryS SMTP Server|General: Listen on TCP/IP Port:25
  8. IP-Interface to Use: 127.0.0.1
  9. Configuration|MercuryS SMTP Server|Connection Control: Add restriction: Allow Connections 127.0.0.1-127.0.0.1 (keine Haken setzen)
  10. Configuration|MercuryS POP Server|General: Listen on TCP/IP Port:110
  11. IP-Interface to Use: 127.0.0.1
  12. Configuration|MercuryS POP Server|Connection Control: Add restriction: Allow Connections 127.0.0.1-127.0.0.1 (keine Haken setzen)
  13. Configuration|MercuryI IMAP4 Server|General: Listen on TCP/IP Port:143
  14. IP-Interface to Use: 127.0.0.1
  15. Configuration|MercuryI MAP4 Server|Connection Control: Add restriction: Allow Connections 127.0.0.1-127.0.0.1 (keine Haken setzen)

Auch wenn Mercury nicht danach verlangt, sollte man nach Änderungen in der Konfiguration den Server nochmal neu starten.

Damit nun über XAMPP auch tatsächlich Mails verschickt werden können, muss man in der php.ini noch etwas nachtragen.

Suchen Sie nach »[mail function]« und ergänzen folgendes:

  • SMTP=localhost
  • smtp_port=25
  • sendmail_from = admin@localhost

Schritt 5 – Wohin mit den Dateien?

Wenn Sie ein neues Web-Projekt starten, dann legen Sie einen neuen Ordner in »c:\Programme\xampp\htdocs\« an und kopieren dorthin alle ihre Dateien.

Anhang

Wichtige Programme

  • Notepad++ – Ein sehr guter  Gratis-Editor mit Projektverwaltung
  • HeidiSQL – Ein Desktop-Client der ein schnelleres Arbeiten mit MySQL-Datenbanken ermöglichkeit als phpMyAdmin
  • mysqldumper – Skriptsammlung zum Sichern und Einspielen kompletten MySQL-Datenbanken

Die wichtigsten Konfigurationsdateien

Den genauen Standort der einzelnen Dateien finden Sie auch unter http://localhost/xampp/phpinfo.php

  • \xampp\apache\conf\httpd.conf – Apache Konfiguration
  • \xampp\MercuryMail\mercury.ini – Mercury Konfiguration
  • \mysql\bin\my.ini – MySQL Konfiguration
  • \xampp\php\php.ini – PHP Konfiguration
  • \xampp\phpMyAdmin\config.inc.php – phpMyAdmin Konfiguration
  • \xampp\sendmail\sendmail.ini – Sendmail, als alternative zu Mercury

Die wichtigsten Pfade

  • \xampp\htdocs
  • \xampp\MercuryMail\MAIL
  • \xampp\mysql\data

Fehlersuche

Es empfiehlt sich – wie überall – die Logfiles zu checken. Nützlich ist dabei eine Software wie mtail, die Logfiles beobachtet und nur die Änderungen in Echtzeit anzeigt.

Die wichtigsten Logfiles

  • \xampp\apache\logs\error.log
  • \xampp\FileZillaFTP\Logs
  • \xampp\MercuryMail\LOGS\
  • \xampp\mysql\data\mysql.err
  • \xampp\sendmail\sendmail.log

Wenn es noch Fragen gibt, immer her damit.

Give feedback on errors with the WordPress Settings API

After working with the WordPress Settings API I first found no easy way out to give feedback on errors.

As a lot of you I was reading the tutorials from David Gwyer, Ozh, BobGneu and Otto, but none of them gave proper information on how to pass the error messages to the user when theie values fail the validation test.

BUT…. I found a somehow quick but practicable way to bypass the lack of user validation information.

Take the sanitize function you call from register_setting which is responsible to check the values:

Now go to the function which creates the settings form (most called via add_options_page) and check with $_GET[’settings-updated‘].

That’s it.

Alle Informationen über eine Website auf einen Blick: webmastercoffee.com

Mein Tipp des Tages (und kein Aprilscherz) ist webmastercoffee.com.

Dort kann man sich auf Deutsch und sehr ausführlich mit Erklärungen dokumentiert alle öffentlich zugänglichen Informationen über eine Website auf einen Blick anschauen:

  • verwendeter Server
  • verwendetes CMS
  • verwendete Skriptsprache
  • nachgeladene Javascript-Bibliotheken (mit Erläuterungen)
  • verwendete Plugins (bei WordPress!)
  • aktivierte Schnittstellen (z.B. Pingback oder RSD)
  • Sitemaps, Feeds
  • Cookies
  • Google Informationen (AdSense, Tracker Codes)
  • Provider
  • Keywords und Keyword-Dichte

Vor bestimmten Schwachstellen, z.B. im Klartext lesbare E-Mail-Adressen, wird auch rot hervorgehoben gewarnt.

Ein schönes Tool, das eine erste Übersicht bietet als Anlaufstelle für tiefere Analysen.

Webmastercoffee - aufführliche Websiteinformationen