Der Default-Editor, welcher mit WordPress daherkommt, ist recht mager zu nennen, reicht jedoch bis auf die fehlende Verlinkungsmöglichkeit aus. Als ich nun diese Verlinkungsmöglichkeit nachinstallieren bzw aktivieren oder freischalten wollte, bin ich auf den CKeditor als Alternative gestoßen.
Also habe ich ein Backup dieses Blog angelegt und diesem Editor eine Installationschance gegeben.
Einfache Installation des CKeditors auf WordPress 3.0
Nach nur drei Schritten
- Über die Adminoberfläche von WordPress das CKeditor Plugin gesucht
- installiert und dann
- aktiviert
war der WYSIWYG Editor eingespielt.
Wenn ich da an den HackMack bei Serendipity denke, mit getrenntem Upload auf den Server, überschreiben von Dateien, verändern von Konfigurationsdateien, etc dann bin ich echt beeindruckt.
Ein großes PLUS für WordPress im Vergleich zu Serendipity als Blog-Programm.
Als ich mir heute einmal den HTML-Code eines WordPress Artikels in diesem Blog angesehen habe, war ich zunächst einmal wie vor den Kopf gestoßen. Im Header stand kein “meta-name=description“!
Es mag ja sein, dass die Suchmaschine Google mehr und mehr davon Abstand nimmt, diesen Meta-Tag auszuwerten, aber da dies in der Regel der Text ist, den ein Internetsurfer beim Treffer angezeigt bekommt, hat dieser Text nach wie vor seine Berechtigung, denn man möchte nicht nur gefunden, sondern letztendlich auch angeklickt werden. Und der Internetnutzer trifft seine Entscheidung meist auf Grund der vorhandenen Beschreibung unterhalb der Trefferüberschrift, eben der “Description”.
Wie sich schnell herausstellte, liegt dieses Manko nicht am WordPress Programm, sondern am verwendeten Design-Theme.
Unterhalb des Artikels kann man im Textfeld, das mit ”Auszug” übertitelt ist, die gewünschte Beschreibung (Description) für den Text hinterlegen. Das ist zwar noch keine Garantie dafür, dass Google diesen Text dann auch anzeigen wird, aber meistens ist dies der Fall.
Und dann sollte man
Design > Editor
aufrufen und die Datei
header.php
des Design-Themes anpassen und die folgende Zeile im Kopfbereich hinzufügen:
<meta name=”description” content=”<?php echo (get_the_excerpt()); ?>” />
Heute erfolgte die Umstellung des Perfect Knowhow Blogs von Serendipity nach WordPress.
Anlass für die Umstellung war primär ein Serverwechsel.
Serendipity hat mit Garvin Hicking einen absolut guten Programmierer, der zudem noch total engagiert ist und kostenlose, schnelle Unterstützung in dem Serendipity-Forum gibt. Das Buch von ihm “Serendipity – Individuelle Weblogs für Einsteiger und Profis” erschienen im open source Press Verlag ist mit Abstand das beste und ausführlichste Entwicklerhandbuch, welches ich mir in den vergangenen Jahren gekauft habe und ich lege dieses Buch jedem ans Herz, der einen Blog auf Serendipity-Basis aufsetzen möchte.
Aber, WordPress ist nun einmal DAS Mainstream Blog System und ein Mann kann letztendlich nicht die Masse an Drittprogrammen und Themes liefern, die es für WordPress gibt, sei er noch so engagiert.
Tags: Migration, Serendipity, WordPress
Ziele eines Permanent Redirects
- Einfangen von Domain-Vertippern
Es ist heutzutage sehr schwer geworden, noch einen freien Domainnamen zu finden. Ich habe es mir angewöhnt, neben der richtigen Schreibweise auch Domain-Namensvariationen und Vertippmöglichkeiten gleich mitzureservieren. Diese zusätzlichen Domains bedeuten zwar permanente, finanzielle Zusatzkosten, sind aber günstiger als später ein Rechtsstreit gegen Trittbrettfahrer. Neben reinen Domain-Namens-Vertippern, sollte man hierbei auch an evtl. mögliche Schreibweisen mit Bindestrich bzw. ohne Bindestrich denken. - Berücksichtigung der Domain Schreibweise mit und ohne “www.”
Dies ist wohl einer der klassischen Anwendungsgründe warum man einen “Permanent Redirect” verwendet, weil man ansonsten eine Google-Abstrafung wegen “Duplicate Content” riskiert.
Mein Stufenplan
Ich empfehle eine mehrstufige Vorgehensweise:
- Die Nameserver-Einträge bzw. DNS Einträge auf die gewünschte Haupt-/Zieldomain setzen.
- Auf der Hauptdomain die entsprechenden Serveraliase für die www.domainname.tld Variante und die Domainnamensvariationen anlegen.
- Durch einen Rewrite Befehl auf dem Apache Server eine HTTP-Permanent-Redirect Antwort absetzen.
Begründung
zu Punkt 1:
Durch den entsprechenden Nameserver bzw. DNS Eintrag genügt eine einfache Domainregistrierung.
Es ist kein Webhostingpaket pro Domain erforderlich.
zu Punkt 2:
Durch die Serveraliase werden die erhaltenen Domainnamen erkannt und mit der Zieldomain verknüpft, dieser zugeordnet.
zu Punkt 3:
Wichtig, damit die Domain-Namensvariationen für Google keine Abstrafung wegen “Duplicate Content” nach sich ziehen.
Permanent Redirect
Je nachdem den Möglichkeiten, die man zur Verfügung hat oder nach der jeweiligen Vorliebe ist an einer der Stellen
- http.conf (Apache Konfigurationsdatei)
- .htaccess (auf Verzeichnisebene)
- vhost.conf (Plesk Konfigurationsdatei)
der entsprechende mod-rewrite Code abzusetzen:
RewriteEngine On
RewriteCond %{HTTP_HOST} !www.domain.tld
RewriteRule (.*) http://www.domain.tld/$1 [R=301,L]
Bei Plesk das abschließende
/usr/local/psa/admin/sbin/websrvmng –reconfigure-vhost –vhost-name=yourDomainname.de
/etc/init.d/apache2 restart
nicht vergessen.
Tags: Apache, Duplicate Content, Permanent Redirect, Plesk
In der Regel hat man die Auswahl, ob man eine Anwendung direkt auf Root-Ebene oder in ein Unterverzeichnis installieren möchte. Die Installation in ein Unterverzeichnis hat den “Charme”, dass die Programminstallationen voneinander sauber getrennt sind (z.B. ein Ordner blog, ein Ordner cms, ein Ordner forum, …) und die verschiedenen index.php und index.html u.s.w. nicht miteinander konkurrieren.
Manchmal möchte man jedoch die ursprüngliche Installation verändern, sei es, eine Root-Installation zu einer Unterordnerinstallation machen oder umgekehrt.
Im folgenden möchte ich für Contao die Stellen kurz aufführen, die es bei einer solchen Aktion zu betrachten und ggf. zu verändern gilt:
- ggf. Apache Document-Root (zwei Stellen Document-Root und Verzeichnisschutz)
- ggf. Apache Rewrite-Anweisungen (http.conf)
- ggf. Plesk vhost.conf (falls Plesk als Admin-Oberfläche verwendet wird)
- ggf. Rewrite-Anweisung in der Datei .htaccess im Hauptordner der Installation (Hauptordner ist hier Root oder der gewählte Unterordner)
- Datei /system/config.localconfig.conf (Parameter: websitePath)
Ich habe die Liste bewußt nicht weiter kommentiert. Die Liste ist als Checkliste gedacht. Beim Lesen muss es bei dem Admin im Kopf klingeln und er muss sofort um die Hintergründe wissen. Laien sollten die Finger davon lassen.
Tags: CMS, Contao, Root, Unterverzeichnis
Dateien werden in der Regel in der Art
meinDokument.doc
meinText.txt
meinBild.png
abgespeichert, also mit einem Namen und einer kurzen Datei-Extension (∗.doc, ∗.png, ∗.txt).
Anhand der Extension kann Windows leicht erkennen, welches Programm beim Doppelklicken auf den Dateinamen zusammen mit der Datei aufgerufen werden muss, damit diese korrekt angezeigt wird. Im Falle von ∗.doc wäre es z.B. eine Microsoft Word Version bis 2007, bei ∗.txt ein Texteditor und bei ∗.png ein Bildverarbeitungsprogramm.
Windows ist so konfiguriert, dass in der Grundeinstellung die Datei-Extensions (∗.doc, ∗.png, ∗.txt) automatisch nicht angezeigt werden, wenn dieser Dateityp dem System bekannt ist.
Damit geht jedoch dem Anwender eine wichtige Information verloren und führt oft bei Umbenennungen der Datei zu Problemen.
Aktivierung der Anzeige bei Windows Server 2008
Beim Betriebssystem Windows Server 2008 kann man die Grundeinstellung für die Anzeige von Dateien verändern, indem man den
- Windows Explorer aufruft
- sich auf eine Laufwerkskennung (z.B.: Local Disk C:/ ) stellt und
- das Dropdown-Menü unter Organize öffnet und dann
- die Folder Options verändert.
Tags: Windows Server
Ausgangssituation
Domains mit der Verwaltungsoberfläche Plesk 9.3 eingerichtet.
Wenn man für eine Domain einen externen Mailserver verwenden möchte, dann ist der DNS-Eintrag auf den Nameservern entsprechend zu setzen. Dies funktioniert soweit bei E-Mail, die von außerhalb gesendet werden, auch recht gut.
Problem
Wird jedoch auf der Internetseite selbst eine E-Mail an eine interne Adresse versendet, z.B. an kontakt@meineDomain.de, so erhält man eine Fehlermeldung der Art
Hi. This is the qmail-send program at n1.meineDomain.de.
I’m afraid I wasn’t able to deliver your message to the following addresses.
This is a permanent error; I’ve given up. Sorry it didn’t work out.
This address no longer accepts mail.
Lösung
Die Fehlermeldung kommt, weil auf der Domainebene kein E-Mail Account angelegt wurde. Das ist ja aber gerade auch erwünscht und soll so bleiben. Da jedoch die Domain auf diesem Server lokal angelegt ist, versucht das System die E-Mails zuzustellen.
Man muss nocheinmal explizit den Mail-Service deaktivieren.
Also Mail-Settings (E-Mail Einstellungen) anklicken und das Häkchen aus dem Ankreuzfeld nehmen.
Problem: Zeitintervall der AWSTATS Statistikaufbereitung zu groß
Oft möchte man sich im Tagesverlauf die auf den aktuellen Tag bezogenen Besucherströme für eine Webseite anzusehen. Leider wird von Plesk die Statistik nur einmal am Tag aktualisiert, so dass es recht unbefriedigend ist, um 15:00 Uhr zu sehen, dass bis 0:05 Uhr (verständlicherweise) nur 20 Besucher auf der Internetseite waren.
Lösung: Cronjob für AWSTATS einrichten
Da bei vielen Servern heutzutage Plesk als Server-Verwaltungsoberfläche eingesetzt wird, möchte ich die Vorgehensweise für Plesk 9.3 beschreiben, um das Aufbereitungsintervall für die Statistik zu verkürzen.
Den Anstoß für die Aufbereitung der AWSTATS-Statistik unter Plesk gibt das Programm
-r-x — — root root /usr/local/psa/admin/sbin/statistics
Wie man sehen kann, darf nur der Benutzer ROOT dieses Programm ausführen.
Das ist wichtig zu wissen.
Trägt man bei Plesk bei irgendeinem anderen Benutzer den Cronjob ein, so würde dieser Cronjob ins Leere laufen und nichts würde passieren.
1. Schritt: Plesk Verwaltungsoberfläche aufrufen
Rufen Sie zunächst unter dem Menüpunkt HOME die SYSTEM USER auf, und suchen Sie den Benutzer root.
Ein alternativer Zugang zu der Einstellungsmaske ist hierbei
HOME / Settings / Scheduled Tasks
2. Schritt: Neuen Crontab Eintrag anlegen
Eigentlich hat man das Schwierigste, die richtige Stelle für seinen Eintrag zu finden, mit dem 1. Schritt schon erledigt. Der rechtsstehende Screenshot zeigt den anzulegenden Eintrag.
Um einen neuen Cronjob anzulegen, ist auf den “Add New Tasks” Schaltfläche oben zu klicken.
Bei Stunden, Minuten, Tag und Monat einfach die gewünschten Werte in die Felder eintragen und beim auszuführenden Programm
/usr/local/psa/admin/sbin/statistics >/dev/null 2>&1
Problem
Beim Abschicken eines Formulars kommt es zu einer SAFE_MODE Fehlermeldung.
Warning: mkdir() [function.mkdir]: SAFE MODE Restriction in effect. The script whose uid is 10001 is not allowed to access /var/www/vhosts/domain.de/httpdocs/…/tmp owned by uid 0 in /root/domain.de/httpdocs/verzeichnis/…/Cache.php on line 271
Ein phpinfo() zeigt
safe_mode=On
Hintergrund
Gerade bei virtuellen Hostern wird der PHP-Parameter SAFE_MODE gerne auf ON gesetzt. Das mag zwar zunächst einmal richtig sein, da man damit den bösen Buben das Leben erschwert, aber im Grunde genommen ist diese Sicherheitseinstellung mehr hinderlich als nützlich.
- Die Sicherheitseinstellung bringt nur etwas, wenn der Angreifer PHP verwendet. Weicht er aber dann auf z.B. Perl als Skriptsprache aus, dann bringt diese restriktive Einstellung gar nichts.
- Ab PHP-Version 5.3.0 ist die PHP-Einstellung SAFE_MODE als DEPRICATED gekennzeichnet, sollte also nicht mehr verwendet werden.
- Die SAFE_MODE=ON Einstellung behindert die PHP-Skripte Verzeichnisse zu erstellen und zu benutzen (die angelegten Verzeichnisse werden dem WWW-Server Benutzer zugeordnet und nicht dem Besitzer der PHP-Skripte)
Lösung
PHP-SAFE_MODE als Domainowner deaktivieren.
Anmerkung: Der Admin eines virtuellen Servers hat die Möglichkeit seinen Kunden das Recht zum PHP SAFE_MODE Management einzuräumen oder auch nicht.
Der Domain-Administrator kann unter dem Menüpunkt WEB HOSTING SETUP den PHP-Parameter ‘save_mode’ für seine Domain verändern (siehe Anmerkung zum virtuellen Server Admin). 
