Von https und zurück

Wie eine Word­Press­sei­te von auf die siche­re Ver­bin­dung https umge­stellt wird, ist im Netz hin­rei­chend beschrie­ben und ist, neben dem Zeit­auf­wand, kein wirk­lich gro­ßes Pro­blem. Was ist aber, wenn man, aus wel­chen Grün­den auch immer, zurück will zur unver­schlüs­sel­ten Variante ?

Im Prin­zip stellt die Rück­füh­rung von Word­Press-Sei­ten auf http kein gro­ßes Hin­der­nis da. Im Grun­de sind die Schrit­te die glei­chen, wie die Umstel­lung auf https, nur umge­kehrt. Im Backend von Word­Press unter Ein­stel­lun­gen den Url-Pfad ändern: Aus https://www.meineseite.de wird http://meineseite.de
Soll­te das Ein­ga­be­feld aus­ge­graut sein, in der wp-con­fig fol­gen­den Code-Schnip­sel eintragen:
define( 'WP_CONTENT_URL', 'http://meineseite.de/wp-content' );

Alle Links im Blog las­sen sich am bes­ten mit dem Script: Search and replace, oder dem gleich­na­mi­gen Plug­in für Word­Press anpassen. 

So weit so gut, pro­ble­ma­tisch wird es mit den links, die von Goog­le aus­ge­ge­ben wer­den. Bis der Goo­gle­bot wie­der vor­bei­kommt, sind alle Links der Sei­te mit­tels https auf­ge­führt. Die Umlei­tung, die wir von der Umstel­lung auf https kennen,
RewriteEngine On
RewriteCond %{HTTP_HOST} ^meineseite\.de [NC] RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://meineseite.de/$1 [R,L]

funk­tio­niert nur in der Theorie. 

War­um? Ganz ein­fach, bevor der Brow­ser die Sei­te mit der mög­li­chen Umlei­tung auf­ruft, prüft er das Zer­ti­fi­kat. Heißt: Noch vor der Umlei­tung warnt der Brow­ser vor einer nicht siche­ren Sei­te. Der sichers­te Weg, Besu­cher in die Flucht zu schlagen 😉

Bei einer pri­va­ten Web­sei­te mag das nicht schlimm sein; für Unter­neh­men ist das eine Kata­stro­phe. Auf den Web­mas­ter­tool Sei­ten der Such­ma­schi­nen kann man die Bots auf­for­dern die Sei­te nach Umstel­lung neu zu iden­ti­fi­zie­ren; und hof­fen das man danach wie­der ohne Warm­hin­weis im Brow­ser gefun­den wird. 

Plugin Update zerschießt WordPress

Das kann schon mal pas­sie­ren: nach einem Update eines Plug­ins geht ver­meint­lich gar nichts mehr. Der Brow­ser stürzt ab und Word­Press zeigt ent­we­der nur noch eine wei­ße Sei­te, oder es lässt sich die login.php nicht mehr, bzw. nur noch mit Feh­lern auf­ru­fen. Kom­me ich noch in die admin Ober­flä­che und auf die Plug­in-Sei­te, ist der Feh­ler leicht zu beheben. 

Ein­fach das Plug­in der letz­ten Aktua­li­sie­rung abschal­ten und schön dürf­te WP wie­der funk­tio­nie­ren. In allen ande­ren Fäl­len muss vom ftp-cli­ent (bspw. File­Zil­la) auf den Ser­ver zuge­grif­fen wer­den. Der Plug­in Ord­ner liegt im Ord­ner Admin im WP Verzeichnis.
Den Ord­ner, bzw. das Ver­zeich­nis Plug­ins sichern (Down­load auf die eige­nen Fest­plat­te und anschlie­ßend den Ord­ner Plug­ins auf dem Ser­ver umbe­nen­nen oder löschen. 

In bei­den Fäl­len kann Word­Press nicht mehr auf das beschä­dig­te Plug­in zurück­grei­fen und ich soll­te mich ganz nor­mal in WP anmel­den können. 

Manch­mal zer­schießt so ein Update aller­dings wesent­lich mehr. In dem Fall die neu­es­te WP Ver­si­on down­loa­den. und auf dem Ser­ver die bei­den Sys­tem­da­tei-Ord­ner wp-admin und wp-includes neu hochladen. 

Danach soll­te Word­Press wie­der funk­tio­nie­ren und ich kann die Plug­ins neu instal­lie­ren. Bei der Gele­gen­heit macht es Sinn zu über­prü­fen, ob die vie­len Plug­ins über­haupt noch gebraucht werden. 

Tag gestalten

Auch der Wei­ter­le­sen-Link lässt eine indi­vi­du­el­le Gestal­tung zu. Dazu lässt sich das Plug­in Bet­ter Font awe­so­me nutzen.

Im Haupt­tem­p­la­te der Sei­te (meist index.php) nach “php the_content” suchen.

In der Klam­mer kann jetzt sowohl der Text als auch das Icon defi­niert werden.

Die Zei­le „icon name“ defi­niert das Icon, in dem Fall ein Buch Icon, inner­halb des Links vom ‑more-tag, zusam­men mit der Textzeile. 

Inner­halb des Tags wech­selt das Icon je nach Defi­ni­ti­on der css für Links auch ent­spre­chend die Farbe. 

WordPress und https

Bei der Umstel­lung mei­nes Word­Press­blogs randblog.de auf eine gesi­cher­te Ver­bin­dung, habe ich mich kom­plett ausgeschlossen. 

Gesi­cher­te Ver­bin­dung heißt ver­ein­facht: der Cli­ent und der Ser­ver tau­schen sich aus. Der Ser­ver authen­ti­fi­ziert sich mit einem Zer­ti­fi­kat und der Cli­ent prüft die Ver­trau­ens­wür­dig­keit des Zertifikats. 

Zu sehen ist das im Brow­ser an der Ken­nung https. Soweit so gut, Zer­ti­fi­kat war ein­ge­rich­tet und in den Ein­stel­lung im Admin-Bereich hat­te ich https eingetragen.

Beim Auf­ruf mei­ner Sei­ten aller­dings woll­ten Cli­ent und Ser­ver offen­bar nicht zusam­men­ar­bei­ten, der Brow­ser mel­de­te eine unsi­che­re Sei­te und brach die Ver­bin­dung ab. Schlim­mer noch, ich konn­te mich in mei­ne Admin-Ober­flä­che nicht mehr ein­log­gen. Die Lösung muss­te also lau­ten, eine Zugriff trotz nicht auto­ri­sier­tem Zer­ti­fi­kat zu erzwingen. 

Nach eini­gem Suchen im Netz wur­de ich bei klein-gedruckt.de fündig.

Ein Ein­trag in die wp-config.php las­sen die Sei­ten sowohl ver­schlüs­selt, als auch unver­schlüs­selt auf­ru­fen und admi­nis­trie­ren. An der Stel­le noch­mal bes­ten Dank, hier der php Schnip­sel, der den Zugriff ermöglicht.

/* Zugriff über SSL-Proxy ermöglichen */
if( isset( $_SERVER['HTTP_X_FORWARDED_SERVER'] ) ) {
# Zugriff mit SSL-Proxy
$_SERVER['HTTPS']='on';
$_SERVER['HTTP_HOST'] = 'ssl-account.com';
$_SERVER['REQUEST_URI']='/randblog.de'. $_SERVER['REQUEST_URI'];
define('COOKIE_DOMAIN', 'ssl-account.com');
define('COOKIEPATH', '/randblog.de/');
define('WP_SITEURL', 'https://randblog.de');
define('WP_HOME', 'https://randblog.de');
} else {
# Zugriff ohne SSL-Proxy
define('COOKIE_DOMAIN', 'randblog.de');
define('WP_SITEURL', 'https://randblog.de');
define('WP_HOME', 'https://randblog.de');
}

*randblog.de ist natür­lich durch den eige­nen Blog­na­men zu erset­zen.

Fehler 606 Blocked

Die Feh­ler mit Zah­len­code wei­sen meist auf ein Pro­blem im Zusam­men­hang mit der Daten­bank hin. Eine Anbin­dung oder eine Syn­tax falsch gesetzt und schon funk­tio­niert die Sei­te nicht mehr. Beson­ders per­fi­de: der Feh­ler 606 weist dar­auf hin, dass Coo­kies nicht akzep­tiert wer­den und somit lässt sich die für die Anmel­dung benö­tig­te Coo­kie Erlaub­nis eine Anmel­dung eben nicht zu.… wei­ter im Text