Ich hatte oft das Problem unter Linux-Mint, dass bei Anschluss eines USB-Sticks oder des Handys über USB, Linux entweder „einfror“ oder sonst wie rumzickte, bis hin zur totalen Verweigerung mein Handy als Laufwerk unter USB anzuerkennen.

Ich vermute es liegt daran, dass verschiedene Anwendungen gleichzeitig bei Anschluss an den USB Port zugreifen wollen; entsprechend gibt es dann natürlich Konflikte.

Bei mir hat die Installation des Pakets mtpfs bei angeschlossenem Handy und/oder folgende Einstellungen im Audioplayer Banchee geholfen.

Banshee öffnen → Tab Bearbeiten → Einstellungen → Tab Erweiterungen →
die ersten 3 Häkchen Geräteunterstützung für ...Apple ...Massenspeicher ...MTP-Mediengeräte entfernen.

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.

In Linux gibt es die Möglichkeit Ordner und Dateien mit einem Schreib- und Kopierschutz zu versehen. Mit dem Konsolenbefehl chattr setzt man entsprechende Attribute für Ordner oder Dateien. Zu erkennen ist das an einem kleinen Schloss an der Datei, bzw. an einem Ordner.

Beispiel: Die Datei Einladung.odt im Ordner Test, der sich auf dem Desktop [Schreibtisch] befindet, soll schreibgeschützt werden.

Terminal aufrufen, mit cd in das Verzeichnis wechseln oder Ordner mit Rechtsklick im Terminal öffnen und mit Chattr +i den Schreibschutz setzten. Zu beachten ist die Klein – und Großschreibung und die Befehlsangabe als sudo.

user@lenovo-mint ~/Schreibtisch/test $ sudo chattr +i Einladung.odt

Zu entfernen ist der Schreibschutz mit dem Befehl -i. Ausführliche Beschreibung und die verschieden möglichen Attribute hier: wiki.ubuntuusers.de

Unter Linux lassen sich relativ einfach Webseiten sperren, die der Browser nicht anzeigen soll. Dazu einfach im Terminal mit Hilfe des Editors die Hosts Datei aufrufen. Also z.b.

Direkt unter dem localhost und dem Computernamen sind die Seiten einzutragen, die gesperrt werden sollen. Der Eintrag muss mit 127.0.0.1 beginnen, gefolgt von der Adresse der zu sperrenden Seite. Anschließend mit Strg und O speichern, weiß erscheinenden Eintrag mit Eingabetaste bestätigen, Terminal schließen – das war's.

Der Browser zeigt zukünftig bei Aufruf der gesperrten Seite entweder nichts oder eine Fehlermeldung an.

Für Windows kann die Datei unter %systemroot%\system32\drivers\etc\hosts mit Hilfe des Editors (Als Administrator ausführen) geöffnet werden.

Gestern zickte plötzlich Chromium beim Aufruf meiner https Seite. Meine Blogseite wollte der Browser nicht anzeigen, angeblich wegen einer unsicheren Verbindung. Alle anderen Browser hatten das Problem nicht. Weitere Nachforschungen ergaben, dass Seiten mit einem Symantec Zertifikat betroffen waren.

Offensichtlich ein Bug nach einem Update des Browsers, denn bisher funktionierte meine https-Verbindung auch in Chromium tadellos. Ebay war genau so betroffen wie Amazon; hier lud Chromium die Stylesheets nicht und bei ebay zeigte Chromium ebenfalls eine unsichere Verbindung.

Im Ubuntu Forum dann gegen 19.00 Uhr der erste Hilferuf eines Users mit demselben Problem. Irgendetwas musste wohl im Chromium Browser die Symantec Zertifikate ausgesperrt haben. Jedenfalls wusste User "axt" die Lösung, die darin liegt, das in Firefox bestehende Symantec Zertifikat zu exportieren und in Chromium zu importieren.

Hier die Anleitung:

Firefox starten
Site "about:preferences#advanced".
Tab "Certificates / Zertifikate anzeigen".
Button "View Certificates / zertifiezierungsstellen
Tab "Authorities".
Das Zertifikat "VeriSign, Inc./Symantec Class 3 Secure Server CA - G4".
Button "Export".
Sichern als "X.509 Certificate (PEM)".
Chromium starten.
Site "chrome://settings/".
Mit "Show advanced settings… / Erweiterte Einstellungen" erweitern.
Punkt "HTTPS/SSL"/"Manage certificates…/ HTTPS/SSL Zertifikate verwalten".
Tab "Authorities" / Zertifizierungsstellen.
Button "Import".
Gespeichertes Exportiertes Zertifikat importieren.
"Trust this certificate for identifying websites / Diesem Zertifikat zur Identifizierung von Websites vertrauen" anklicken und nur das.
Zertifikatsmanager schließen.
Gewünschte Website neu laden.

Bei mir hat's funkioniert

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.