Weniger Arbeit durch Optimierung.

Indem ich den BLOG hier in das Projektnetzwerk integriere, erspare ich mir eine ganze Menge an Arbeit. Zum Beispiel das Up-to-Date sein des Blog selbst sowie dessen Plugins entfällt damit in sofern, das ich dass dann nur noch 1mal für das gesamte Projektnetzwerk mache.

WordPress Plugins werden eben so dann nur noch 1mal aktualisiert, was mir eben so bisherige doppelte Arbeit erspart. Denn mitunter ist ech lästig gewesen immer zu die gleichen Arbeitsschritte doppelt oder damals gar dreifach zu machen. Und das nur weil jedes Blogprojekt als eigenen Installation lief und somit jeweils für sich genommen EXTRA Aufwand generierte und gepflegt werden musste.

EINE GROßE DATENBANK…

Wenn dann alle Blogprojekte von mir in einer WordPress Installation laufen, ergibt sich dadurch auch EINE GROßE DATENBANK was durchaus auch Gefahren birgt.

Abgewägt habe ich das Nutzen zu Gefahren -Potenzial schon mehrfach und bin zu dem Entschluss gekommen das ich dem bisher gut vorgebeugt habe und durch weitere Sicherheitsmaßnahmen dem ganzen noch weiter Vorbeugen kann. Wobei es natürlich immer zu nur eine 99.9% Sicherheit gibt aber das ist ja bei allen Dingen so denn 100% Sicherheit sind reine Illusion!

Redundante Sicherheit.

Doppelt und Dreifach habe ich bisher meine Daten gesichert, sei es meine persönliche Datenbestände auf dem Rechner zu Hause oder die Datenbestände meiner Projekte im Internet. Immer zu habe ich darauf geachtet das meine Datenbestände REDUNDANT gesichert waren, am besten Redundant im Internet mit Kryptischer Verschlüsselung als auch zu Hause lokal ebenfalls kryptisch verschlüsselt.

Im Internet wird die Redundante Sicherung meiner Datenbestände auf der einen Seite durch den Hoster sichergestellt und zudem durch mich mittels Auslagerung der Datenbestände als Kryptische Verschlüsselung im Netz selbst was NeuDeutsch dann Cloud heißt.

Lokale Redundanz!

Zu Hause befindet sich eine Western Digital My Book World Edition II
welche sich gegenseitig spiegeln. Ein Art von Mini-NAS oder dergleichen ist das für mich persönlich.

Zudem existieren von den, für mich wichtigsten Datenbeständen, auch noch als Sicherungen auf einer kleineren SSD/FlashHDD welche knapp 100GB Speicherkapazität umfasst. Diese kleine “Schatztruhe” ist kryptisch verschlüsselt und gut versteckt, wobei dessen Daten nur 1-2 pro Jahr aktualisiert beziehungsweise Synchronisiert werden.

ALLES SYNCHRONISIERT!

ALLE Datenbestände werden beständig synchronisiert und das mittlerweile zu 95% Vollautomatisch vom Rechner und jeweils auch untereinander. Die aktuelle Generation von Festplattensystem und NAS und dergleichen macht es möglich für vergleichsweise wenig finanzielle Investitionen seinen Datenbestände mit sehr hoher Sicherheit und Redundanz lokal zu sichern.

Schlimmster Fall.

Den für mich bisher schlimmsten Fall hatte ich schon mal, das alle für mich damaligen Datenbestände unwiderruflich gelöscht waren. Seit diesem Tag investiere ich beständig einen Teil meiner Einnahmen in effiziente sowie optimierte Redundante Backup-Lösung!

[red_box]Meine Daten sind mir wichtig, den diese mehr oder weniger teilweise sehr persönlichen Daten von Mir sind das quasi Zahlungsmittel in der heutigen Digitalisierten Welt und manchmal sogar wichtiger als Geld.[/red_box]

Erst mal bin ich froh das dass Upgrade von der letzten WordPress Version auf die aktuelle WordPress Version 3.2 ohne Probleme funktioniert hat. Dennoch hatte ich wie üblich ein manuelles Backup der Datenbank vor dem Upgrade gemacht. Nur für alle Fälle eben, falls ETWAS passiert wäre bei dem Upgrade von WordPress auf die aktuelle und NEUE Version. 

Nachdem Upgrade ist vor dem Upgrade, irgendwie so heißt es doch. Vor der neuen WordPress Version 3.2 funktionierte WordPress eher etwas träge und stellenweise recht langsam, zumindest war das Zeitweise so mein eigener subjektiver Eindruck. Doch nachdem Upgrade von WordPress scheint es so als ob WordPress einen Geschwindigkeitsschub bekommen hat.

Mindestvoraussetzungen…

PHP 5.2.4 und MySQL 5 sind nun nämlich die Mindestanforderungen für WordPress und somit sollte neben der Sicherheit auch die Geschwindigkeit merklich gestiegen sein. Die ersten paar Minuten nach der Installation sind für mich und meinen subjektiven Eindruck zumindest sehr erfreulich. Denn WordPress scheint in der aktuellen 3.2 Version wirklich noch mal mächtig zugelegt zu haben was die Geschwindigkeit angeht.

Neue Optik mit WordPress Version 3.2

Das Backend von WordPress war vor dem Upgrade schon gut, meiner Ansicht nach, wenn auch teilweise etwas arg komplex beziehungsweise umständlich strukturiert. Nun mit der WordPress Version 3.2 ist es im Backend von WordPress endlich mal etwas aufgeräumter und klarer strukturiert geworden, was mir sehr gut gefällt.

Ein etwas anderer Blauer oder Grauer Farbton ist das jetzt im Backend von WordPress, was das gesamte Backend von WordPress etwas froher und lebendiger erscheinen lässt wie ich finde. Zudem wurden die Schriftarten im internen von WordPress etwas aufgewertet, genau so wie einzelne Bereiche in der Seitlichen Haupt-Navigation und eben so in den Bereichen für die Widgets!

Alles in allem ist die neue WordPress Version 3.2 sehr gelungen finde ich.

Die Veränderungen im Detail von WordPress in Version 3.2 werde ich wohl erst in den nächsten Tagen und Wochen genauer mitbekommen, beim Arbeiten mit WordPress eben. Sobald mir dann etwas neues in der WordPress Version 3.2 auffällt, im Vergleich zu vorher, werde ich meine Eindrücke dazu in Wort und Bild festhalten sowie als Beitrag veröffentlichen.

Sofern Du selbst Benutzer eines WordPress Blog bist, würde mich an dieser Stelle mal interessieren was DU genau von der aktuellen WordPress Version 3.2 hältst!

Zudem habe ich aktuell nur 2GB RAM im Macmini verbaut und nicht 4GB RAM wie beim damaligen iMac noch. Na ich werde es spätestens dann merken, ob das StarCraft2Beta auf meinem Macmini funktioniert, wenn ich das Spiel starte.

Es sei denn Blizzard war so schlau und hat eine spezielle Check-Routine mit eingebaut, innerhalb des Prozess der Installation des Spiel, welche die Hardware prüft. Weil dann würde das Installationspaket selber herausfinden und mir bescheid geben wenn die Hardware nicht die nötigen Anforderung erfüllt.

Manch einer wird nun vielleicht wieder meckern, weil es doch nur “Views” also normale Seiten-Ansichten und keine “eindeutigen Besucher” sind, wie man es von Google Analytics bisher gewohnt ist.

Da ich kein Google Analytics nutze und auch nicht in Zukunft nutzen werden, stelle ich als Alternative dazu mal die Daten von Semmelstatz gegenüber, welche die bisherigen Statistik-Daten meines Blog weiter untermauern.

Ein kleines Problem mit der Datenbank im allgemeinen, kostete mich dann Einen Statistischen Wert in Semmelstatz, was jedoch nicht weiter schlimm ist.

Wie gewohnt nun im Anhang die üblichen Bildschirm-Fotos vom Statistik-Plugin von WordPress plus der neuen Bildschirm-Fotos von den Semmelstatz Statistiken.

Monate-Übersicht als Diagram (WordPress-Statistik-Plugin)

Monate und Jahre Übersicht als Zahlen (WordPress-Statistik-Plugin)

Die letzten 7 Monate (Semmelstatz-Plugin)

96 Tage zurück (Semmelstatz-Plugin)

30 Tage zurück (Semmelstatz-Plugin)

Die 2 Einbrüche in den Statistik-Daten vom Semmelstatz-Plugin sind wie schon beschrieben, die Folgen eines Problems mit der Datenbank und einer Unsachgemäß durchgeführten Lösung von mir.

Davon mal abgesehen, wäre es langsam aber sicher mal an der Zeit meiner Meinung nach, das sich die Werte irgendwie mal stabilisieren auf einer Ebene.

Bin gespannt wie der November 2009 wird, ob es weiter über den 10.000 Wert hinaus geht oder erstmalig wieder etwas nach unten.

Wie siehst du diese Entwicklung und was ist deine Meinung dazu?

Nun ist der erste Schritt vollbracht, mein Blog ist von der alten Domain auf die neue Domain umgezogen in der Nacht. Lediglich ein Problem gab es bei dem Umzug, nämlich das mein Hoster oder besser gesagt dessen Support einfach mal meine “.htaccess” gelöscht hatte wodurch dann keine Umleitung bzw. Weiterleitung mehr stattfand.

Warum das so passiert ist von meinem Hoster aus, das bin ich noch am abklären.

Für alle die das selbe vor haben erkläre ich hier ein mal wie ich vorgegangen bin dabei. Das ganze basiert auf einer Anleitung von Frank Helmschrott dessen Kommentarfunktion aber leider für den Artikel mit der Anleitung deaktiviert ist was ich persönlich sehr schade finde.

Nachfolgend nun die Anleitung.

Als ersten Schritt macht man ein Backup seiner Dateien und Ordner sowie seiner Datenbank.

Zum sicher meiner Daten vom Server nutze ich als Mac OS X Nutzer Transmit in der aktuellen Version. Geht damit sehr gut von statten und hat mir bisher sehr gute Dienste geleistet.

Den mysqldumper nutze ich zum sichern meiner Datenbank und auch zum wiederherstellen sowie zum bearbeiten selbiger. Das schöne am mysqldumper ist der Punkt, das man auch sehr große Datenbanken damit sichern und wiederherstellen kann trotz der eventuell vorhandenen Verbindungsbeschränkungen vom Server oder dergleichen.

Nachdem dem sicher aller Daten/Ordner und dem Datenbank Backup auf der lokalen Festplatte konnte ich mich dann dem nächsten schritt zuwenden.

Unter der neuen Domain erst einmal den mysqldumper frisch installieren und danach das zuletzt gemachte Backup der Datenbank dort einpflegen.

In meinem Fall mache ich das manuell in dem ich in den Ordner “/mysqldumper/work/backup/” aufrufe von der lokalen Sicherung und mir dort das passende Backup raussuche.

Danach packe ich dann das passende Backup in den mysqldumper auf der neuen Domain, wobei der Pfad wieder “/mysqldumper/work/backup/” sein sollte. Je nachdem ob der Ordner noch “mysqldumper” heisst oder nicht muss man das dann anpassen.

Sofern das Datenbank Backup nun an der richtigen Stelle innerhalb des neu installieren mysqldumper liegt und der mysqldumper auch funktioniert geht man dann zum nächsten Schritt über. Das Übertragen der Daten/Order -Sicherung auf die neue Domain.

In meinem Fall also per FTP Client angemeldet auf dem Server und den passenden Ordner gesucht. Dann anschliessen alle Datenbestände von WordPress in den passenden Ordner kopiert, welcher zum Beispiel “neue_Blogdomain” heisst oder dergleichen.

Konfiguration anpassen

Wenn das kopieren der Dateien/Ordner abgeschlossen ist kommt die “config.php” innerhalb vom Hauptverzeichnis von WordPress dran. Dort müssen manuell die Angaben für die Datenbank sowie für den Datenbankbenutzer geändert werden.

Anbei am besten noch mal die Rechte der einzelnen Dateien/Ordner sowie der “config.php” überprüfen. Genaue angaben zum setzten der korrekten Rechte findet man Hier!

Jetzt fehlt noch die Anpassung der URL in der Datenbank für den Blog. Wenn man das nicht manuell machen möchte oder nicht weiss wo man das macht, dann kann man auch auf einen SQL-Query zurückgreifen der wie folgt lautet:

UPDATE wp_options SET option_value = replace(option_value, ‘http://www.alte-blog-url.de/blog’, ‘http://neue.blog.url’) WHERE option_name = ‘home’ OR option_name = ‘siteurl’;

Somit sollte der Blog schon mal wieder erreichbar sein im Browser. Am besten sofort überprüfen ob es funktioniert oder nicht. Die Links der einzelnen Artikel/Beiträge oder auch der eingebundenen Bilder funktionieren wahrscheinlich noch nicht. Dazu gleich mehr!

Permalinks updaten

Alle Permalinks von WordPress Blog müssen nun noch endsprechend angepasst werden. Dazu verwendet man am besten wieder einen SQL-Querry:

UPDATE wp_posts SET guid = replace(guid, ‘http://www.alte-blog-url.de/blog’,'http://neue.blog.url’);

Ein zusätzlicher Schritt könnte eventuell noch nötig sein. Im Adminbereich unter “Einstellungen –> Permalinks” die Werte einfach noch mal speichern. Danach sollte dann auch die Links zu den Beiträgen/Artikeln im neuen Blog funktionieren.

Bilder und Links in Artikeln/Beiträgen reparieren

Durch das wechseln der Domain kann es zu Problemen innerhalb der Verzeichnisse kommen, was Bilder und Links angeht. Deshalb muss man auch hier etwas reparieren und richten mit einem SQL-Querry:

UPDATE wp_posts SET post_content = replace(post_content, ‘http://www.alte-blog-url.de/blog’, ‘http://neue.blog.url’);

Wie Frank es schon beschrieben hat, ist je nach Situation eine Anpassung dieser Datenbankabfrage nötig. Man sollte das abklären, zum Beispiel mit dem Support des eigenen Hoster bevor man da dran geht, sofern man NICHT weiss was man da macht.

Umleitung der Aufrufe

Die lieben Suchmaschinen sind für einen Blogger das Salz in der Suppe und von daher sollte man sich mit denen gut stellen nach dem Umzug. Gleiches gilt auch für die eigenen Stammleser, welche man entsprechend um lotsen muss.

Laut der Beschreibung von Frank ist der beste Weg dazu ein HTTP-Redirect (Permanent – 301) für Google und Konsorten. Das ganze sieht dann in der “.htaccess” Datei wie folgt aus:

RewriteEngine on
RewriteRule (.*) http://helmschrott.de/blog/$1 [R=301,L]

Diese “.htaccess” legt man dann in alten Ordner unter der alten Domain.

Das ganze sofort mal ausprobieren am besten, ob alles richtig funktioniert. Am besten funktioniert das mit alten Artikel/Beitrags URL’s welche dann im Idealfall 1zu1 umgeleitet werden. Die Sache mit Google und Konsorten ist immer ein Stück weit ein Spiel mit dem Feuer, wie Frank das treffend beschrieben hat.

Der Support meines Hoster hatte noch ein paar Anmerkungen was die Umleitung angeht. Das ganze würde besser funktionieren wenn man es wie folgt in der “.htaccess” eintragen würde:

RewriteEngine On
RewriteRule ^(.*)$ http://www.blog.kranzkrone.de/index.php [R]

Wobei man allerdings auch das ganze einfacher haben kann:

Redirect / http://www.blog.kranzkrone.de

Beides zusammen in einer “.htaccess” funktioniert auch, aber das wäre dann doppelt gemoppelt. Wobei die Frage für mich persönlich dabei bleibt ob das dann schlimm ist in irgendeiner form, sprich irgendwelche bösen Nebenwirkungen ergibt oder dergleichen.

Anpassung von statischen Links sowie Plugins und anderer Dienste

Wenn man in seinem WordPress Theme / Template irgendwelche manuellen Anpassungen in puncto Links vorgenommen hat, dann muss man diese nun nur noch anpassen.

Die Optionen diverser Plugins sollte man dann noch kontrollieren, da es unter Umständen Plugins gibt die ihre Einstellungen auf dem Server speichern. Die Feed-URL sollte man dann noch anpassen, sofern man den Feedburner von Google nutzt.

Abschliessend sollte man den Inhalt des alten Ordner löschen unter dem der Blog bisher lief.

Wichtig dabei ist, das man die dort angelegt “.htaccess” nicht mit löscht da sonst keine Umleitung/Weiterleitung stattfindet und die Besucher/Leser ins Leere laufen.

Schlusswort und Anmerkungen

Alles hat soweit wie in der original Anleitung von Frank super funktioniert, womit die Anleitung selber auf jeden Fall bis auf weiteres gültig ist. Lediglich das Problem mit meinem Hoster und die Löschung der “.htaccess” durch den Support oder wen auch immer bei meinem Hoster war das einzige Problem. Sowas sollte man im Vorfeld abklären, wenn man es denn weiss das der Support vom Hoster einfach mal sowas tut ohne einem Bescheid zu geben.

Am besten wäre es, wenn man einen kleinen Artikel verfasst für seine Leser das man demnächst umzieht mit dem Blog und es dadurch zu Störungen bei der Domain kommen kann.

Vielleicht anbei die neue Domain dann Zeitnah an die Leserschaft weitergeben oder dergleichen. Eine andere Lösung wäre die Erstellung einer statischen “index.php/html” wo man in einem Satz darauf hinweist wie man zur neuen Domain folgen kann.

Dieser Artikel ist eine Warnung von mir vor einem Plugin das bei meinem Blog ein paar sehr böse Nachwirkungen hinterlassen hat. Es handelt sich dabei um ein Plugin womit man Benutzer freischalten kann, noch bevor ein Eintrag in der Datenbank selber erfolgt.

Was nicht bei der Plugin Beschreibung steht, ist dass das besagte Plugin das Registrieren unmöglich macht für neue Benutzer, wenn man das Plugin wieder abschaltet.

Neue Benutzer können sich nicht mehr anmelden nach dem Sie sich registriert haben, da das Passwort nicht mehr vom System angenommen wird. Selber ist es mir beinahe auch so ergangen als Administrator, also mich kurz mal ausgeloggt hatte.

Allerdings funktioniert bei mir selber das zurücksetzten des Passwort und somit konnte ich mich wieder einloggen in den Blog, was bei allen anderen aber nicht funktioniert. Nun werde ich das besagte Problem mal im Forum vom WPD darlegen und auf eine Lösung hoffen.

Somit ist es nun nämlich erst mal nicht mehr möglich sich nach der Registrierung in meinem anzumelden, was in puncto Spambenutzer durchaus auch Vorteile hat. Denn diese bleiben seither komplett aus, was mich ein wenig freut auch wenn es nur ein Schwacher Trost ist.

Also lasst am besten die Finger von dem besagten Plugin.