Ein Verzeichnis in WordPress umzubenennen, weil man beispielsweise nicht auf den Ordner /wordpress verweisen möchte, ist relativ simpel.

Beispiel: www.meinesite.de/wordpress soll in www.meineseite.de/blog umbenannt werden.

Das Verzeichnis auf dem Server mittels dem ftp-Programm umbenennen. Die Pfade zum neuen Verzeichnis werden in der wp-config.php definiert, bzw. angepasst. Den Codeschnipsel hinzufügen,
define('WP_SITEURL', 'http://www.meineseite.de/blog');
define('WP_HOME', 'http://www.meineseite.de/blog');

wp-config.php hochladen.

In der Datenbank mittels php-admin sollte der Pfad unter wp-options ebenfalls angepasst werden. Danach sollte das blog oder die Seite unter www.meineseite.de/blog zu erreichen sein.

Wie eine WordPressseite von auf die sichere Verbindung https umgestellt wird, ist im Netz hinreichend beschrieben und ist, neben dem Zeitaufwand, kein wirklich großes Problem. Was ist aber, wenn man, aus welchen Gründen auch immer, zurück will zur unverschlüsselten Variante ?

Im Prinzip stellt die Rückführung von WordPress-Seiten auf http kein großes Hindernis da. Im Grunde sind die Schritte die gleichen, wie die Umstellung auf https, nur umgekehrt. Im Backend von WordPress unter Einstellungen den Url-Pfad ändern: Aus https://www.meineseite.de wird http://meineseite.de
Sollte das Eingabefeld ausgegraut sein, in der wp-config folgenden Code-Schnipsel eintragen:
define( 'WP_CONTENT_URL', 'http://meineseite.de/wp-content' );

Alle Links im Blog lassen sich am besten mit dem Script: Search and replace, oder dem gleichnamigen Plugin für WordPress anpassen.

So weit so gut, problematisch wird es mit den links, die von Google ausgegeben werden. Bis der Googlebot wieder vorbeikommt, sind alle Links der Seite mittels https aufgeführt. Die Umleitung, die wir von der Umstellung auf https kennen,
RewriteEngine On
RewriteCond %{HTTP_HOST} ^meineseite\.de [NC]
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://meineseite.de/$1 [R,L]

funktioniert nur in der Theorie.

Warum? Ganz einfach, bevor der Browser die Seite mit der möglichen Umleitung aufruft, prüft er das Zertifikat. Heißt: Noch vor der Umleitung warnt der Browser vor einer nicht sicheren Seite. Der sicherste Weg, Besucher in die Flucht zu schlagen 😉

Bei einer privaten Webseite mag das nicht schlimm sein; für Unternehmen ist das eine Katastrophe. Auf den Webmastertool Seiten der Suchmaschinen kann man die Bots auffordern die Seite nach Umstellung neu zu identifizieren; und hoffen das man danach wieder ohne Warmhinweis im Browser gefunden wird.

Das kann schon mal passieren: nach einem Update eines Plugins geht vermeintlich gar nichts mehr. Der Browser stürzt ab und WordPress zeigt entweder nur noch eine weiße Seite, oder es lässt sich die login.php nicht mehr, bzw. nur noch mit Fehlern aufrufen. Komme ich noch in die admin Oberfläche und auf die Plugin-Seite, ist der Fehler leicht zu beheben.

Einfach das Plugin der letzten Aktualisierung abschalten und schön dürfte WP wieder funktionieren. In allen anderen Fällen muss vom ftp-client (bspw. FileZilla) auf den Server zugegriffen werden. Der Plugin Ordner liegt im Ordner Admin im WP Verzeichnis.
Den Ordner, bzw. das Verzeichnis Plugins sichern (Download auf die eigenen Festplatte und anschließend den Ordner Plugins auf dem Server umbenennen oder löschen.

In beiden Fällen kann WordPress nicht mehr auf das beschädigte Plugin zurückgreifen und ich sollte mich ganz normal in WP anmelden können.

Manchmal zerschießt so ein Update allerdings wesentlich mehr. In dem Fall die neueste WP Version downloaden. und auf dem Server die beiden Systemdatei-Ordner wp-admin und wp-includes neu hochladen.

Danach sollte WordPress wieder funktionieren und ich kann die Plugins neu installieren. Bei der Gelegenheit macht es Sinn zu überprüfen, ob die vielen Plugins überhaupt noch gebraucht werden.

Auch der Weiterlesen-Link lässt eine individuelle Gestaltung zu. Dazu lässt sich das Plugin Better Font awesome nutzen.

Im Haupttemplate der Seite (meist index.php) nach "php the_content" suchen.

In der Klammer kann jetzt sowohl der Text als auch das Icon definiert werden.

Die Zeile „icon name“ definiert das Icon, in dem Fall ein Buch Icon, innerhalb des Links vom -more-tag, zusammen mit der Textzeile.

Innerhalb des Tags wechselt das Icon je nach Definition der css für Links auch entsprechend die Farbe.

Bei der Umstellung meines WordPressblogs randblog.de auf eine gesicherte Verbindung, habe ich mich komplett ausgeschlossen.

Gesicherte Verbindung heißt vereinfacht: der Client und der Server tauschen sich aus. Der Server authentifiziert sich mit einem Zertifikat und der Client prüft die Vertrauenswürdigkeit des Zertifikats.

Zu sehen ist das im Browser an der Kennung https. Soweit so gut, Zertifikat war eingerichtet und in den Einstellung im Admin-Bereich hatte ich https eingetragen.

Beim Aufruf meiner Seiten allerdings wollten Client und Server offenbar nicht zusammenarbeiten, der Browser meldete eine unsichere Seite und brach die Verbindung ab. Schlimmer noch, ich konnte mich in meine Admin-Oberfläche nicht mehr einloggen. Die Lösung musste also lauten, eine Zugriff trotz nicht autorisiertem Zertifikat zu erzwingen.

Nach einigem Suchen im Netz wurde ich bei klein-gedruckt.de fündig.

Ein Eintrag in die wp-config.php lassen die Seiten sowohl verschlüsselt, als auch unverschlüsselt aufrufen und administrieren. An der Stelle nochmal besten Dank, hier der php Schnipsel, 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ürlich durch den eigenen Blognamen zu ersetzen.

1

Die Fehler mit Zahlencode weisen meist auf ein Problem im Zusammenhang mit der Datenbank hin. Eine Anbindung oder eine Syntax falsch gesetzt und schon funktioniert die Seite nicht mehr. Besonders perfide: der Fehler 606 weist darauf hin, dass Cookies nicht akzeptiert werden und somit lässt sich die für die Anmeldung benötigte Cookie Erlaubnis eine Anmeldung eben nicht zu. ...Weiterlesen Fehler 606 Blocked