Kategorie: Wordpress

Ein Pro­blem mit dem man bei Word­Press häu­fig zu tun hat, ist das Log­in Redi­rect Phä­no­men. Word­Press lässt einen trotz rich­ti­ger Ein­ga­be des Benut­zer­na­mens und Kenn­wort nicht mehr ins Backend. Es wird ein­fach immer die Log­in-Sei­te neu prä­sen­tiert und das ohne Feh­ler­mel­dung. Oft ist ein Plug­in schuld oder die Brow­ser­ein­stel­lun­gen las­sen kei­ne Coo­kies zu. 

Bei mir war es eine Wei­ter­lei­tung auf eine ande­re Domain, die logi­scher­wei­se dazu führ­te, dass WP zwar in der rich­ti­gen Kon­fi­gu­ra­ti­on aber unter ande­rer Domain dazu ver­an­lass­te, den Zugang zu sperren.

Abhil­fe schafft ein klei­ner Ein­trag in die WP-Con­fig. Hier ein­fach die Sei­ten URL mit nach­fol­gen­dem Code ergänzen:

define(‘WP_HOME’,‘http://xyz.de’);
define(‘WP_SITEURL’,‘http://xyz.de’);

xyz.de ist natür­lich mit der aktu­el­len URL zu ersetz­ten. WP-Con­fig wie­der auf den Ser­ver laden und schon müss­te Word­Press den Zugang freigeben.

Falls es nicht eine neue Domain sein soll­te, mit der Word­Press nichts anzu­fan­gen weiß, ist meist ein feh­ler­haf­tes Plug­in Schuld. In dem Fall per ftp alle Plug­ins löschen, anschlie­ßend ein­log­gen und ein Plug­in nach dem ande­ren wie­der instal­lie­ren. Bei jedem Plug­in neu ein­log­gen. Irgend­wann soll­te so der Übel­tä­ter aus­fin­dig gemacht wer­den können. 

In Word­Press gibt es die Export/ Import­funk­ti­on für Bei­trä­ge aus einem ande­ren Blog, mög­lich ist damit natür­lich auch eine Siche­rung, die beim Crah neu ein­ge­spielt wer­den kann. Auch gibt es zahl­rei­che Plug­ins für die Daten­si­che­rung der Arti­kel, Bil­der und Kom­men­ta­re. Die ein­fachs­te Metho­de scheint mir das Expor­tie­ren und Impor­tie­ren der gesam­ten Daten­bank über phpMyAdmin. 

Dazu die Ziel­da­ten­bank beim Hos­ter über phpMy­Ad­min auf­ru­fen, in der Menü­zei­le auf expor­tie­ren kli­cken und die Back­up-Datei als .sql auf dem PC spei­chern. Im Anschluss kann dann die Back­up-Datei in die neue Daten­bank ein­ge­pflegt werden. 

Die her­un­ter­ge­la­de­ne Datei mit einem Text­edi­tor öff­nen und unter der Zei­chen­fol­ge CREATE DATABASE %Daten­bank­na­me% oder USE %Daten­bank­na­me den Namen der neu­en Daten­bank ein­tra­gen und abspeichern

Dann die neue Daten­bank unter phpMy­Ad­min auf­ru­fen, im Menü auf Impor­tie­ren kli­cken und die geän­der­te .sql Datei aus­wäh­len. Der Vor­teil ist, dass in der Regel tat­säch­lich alle Bei­trä­ge, Bil­der und Kom­men­ta­re über­nom­men werden. 

Wenn alles funk­tio­niert, kann die alte Daten­bank gelöscht wer­den. Die­se Vor­ge­hens­wei­se emp­fiehlt sich übri­gens auch bei einem Update der MySQL-Version.

Klei­ne Ursa­che, gro­ße Wir­kung. Eini­ge Brow­ser (Chro­me, IE, Ope­ra) zei­gen die über die Style­sheets ein­ge­bun­de­nen Schrif­ten nicht an, wenn nicht sicher­ge­stellt ist, dass der Import­be­fehl, also beispielsweise:
@import url('https://fonts.googleapis.com/css?family=Work+Sans:200,300&subset=latin-ext');

als ers­te Anwei­sung in der style.css des child-the­mes steht. 

Für den Auf­ruf der Web­sei­te ohne das www wird in der Regel in der .htac­cess-Datei eine Umlei­tung festgelegt.

Mit dem Codeschipsel:

RewriteEngine on
RewriteCond %{HTTP_HOST} ^www\.peter-lohren\.de$
RewriteRule ^(.*)$ https://peter-lohren.de/$1 [L,R=301]

soll­te auf die Sei­te peter-lohren.de ohne das läs­ti­ge www umge­lei­tet werden. 

Die .htac­cess muss dabei im root Ver­zeich­nis der Web­sei­te lie­gen. Bei mir aller­dings funk­tio­nier­te die Umlei­tung mit­tels .htac­cess nicht, Word­Press zeig­te nach Auf­ruf eine Sei­te mit Umlei­tungs­feh­ler. War­um auch immer.

Statt der .htac­cess ist es aller­dings auch mög­lich, mit­tels der config.php den Auf­ruf der Web­sei­te ohne www zu rea­li­sie­ren. Dazu ein­fach die url in der config.php defi­nie­ren, die es denn sein soll:

/**
* Webseite ohne www
*/
define('WP_HOME','https://peter-lohren.de');
define('WP_SITEURL','https://peter-lohren.de');

Bei mir jeden­falls hat das funk­tio­niert. Bei Auf­ruf von www.peter-lohren.de lei­ten alle Brow­ser sofort auf die Vari­an­te ohne www um. 

Manch­mal möch­te man sei­nen Word­Press Blog in einem ande­ren Ver­zeich­nis haben, also z.b. www.meineseite.de/blog. Das stellt kein gro­ßes Pro­blem dar. Die ein­fachs­te Vari­an­te ist, per ftp-cli­ent, zb. File­zil­la sämt­li­che Datei­en vom Ser­ver in ein zuvor ange­leg­ten Ord­ner /blog her­un­ter zu laden.

Anschlie­ßend die Datei­en im Haupt­ver­zeich­nis auf dem Ser­ver löschen und den Ord­ner /blog als Gan­zes wie­der ins Haupt­ver­zeich­nis hoch­la­den. Im Anschluss auf der Sei­te des Anbie­ters die Daten­bank auf­ru­fen wp_optionen auf­ru­fen und in den Tabel­len siteurl und home die Pfad­an­ga­be ent­spre­chend ändern. Bei­spiels­wei­se von www.meinedomain.de in www.meinedomain.de/blog.

Bei Ver­wen­dung eines Child-The­mes ist in der funktions.php bzw. in den style­sheets die Pfad­an­ga­be auch noch zu ändern. Zu guter Letzt noch die Per­ma­links ein­mal auf ein­fach stel­len, spei­chern und anschlie­ßend wie­der auf die gewünsch­te Ein­stel­lung und abspei­chern. das soll­te es gewe­sen sein. 

Das „wei­che“ Erschei­nungs­bild bei Auf­ruf einer Sei­te, Bil­dern oder ande­ren Ele­men­ten ist schnell und ein­fach umge­setzt. Zunächst muss der Brow­ser die grund­sätz­li­che Anwei­sung erhal­ten, näm­lich das ange­ge­be­ne Ele­ment oder die Sei­te in einer bestimm­ten Zeit von unsicht­bar auf sicht­bar zu schal­ten. Das geht mit dem Code:

@keyframes fadein{from{opacity:0;}to{opacity:1;}}@-moz-keyframes fadein{from{opacity:0;}to{opacity:1;}}@-webkit-keyframes fadein{from{opacity:0;}to{opacity:1;}}@-o-keyframes fadein{from{opacity:0;}to{opacity:1;}}

Die­ser Code ist ganz unten in die Style­sheets (style.css) einzufügen.

Wer den Fade Effekt für sei­ne gan­ze Web­sei­te haben möch­te, gibt nun für den Typ-Selek­tor body die fol­gen­de CSS-Anwei­sung an:

animation:fadein 0.5s;-moz-animation:fadein 1.0s;-webkit-animation:fadein 0.5s;

Die Anwei­sung bewirkt die Dau­er des Fade-Effekts. Die Unter­schie­de erge­ben sich bei moz-ani­ma­ti­on aus der unter­schied­li­chen Dar­stel­lung der Brow­ser. Die Zeit­dau­er kann natür­lich auch ent­spre­chend ver­län­gert wer­den. Für die­se Sei­te habe ich alle Wer­te 1 Sekun­de ver­län­gert. Aber auf­ge­passt – trotz des schö­nen Effekts; Besu­cher wol­len in ers­ter Linie etwas sehen und nicht von Effek­ten über­rascht wer­den. Es macht Sinn, den Fade Effekt zeit­mä­ßig so ein­zu­stel­len, wie die Sei­te zum Laden braucht. Dann sieht es gut aus und nervt auch nicht. Wenn die Web­sei­te aller­dings län­ger als drei vier Sekun­den lädt, nützt der schöns­te Fade-Effekt nichts. 

Das Script habe ich auf der Sei­te fastwp.de gefun­den. Der Sei­ten­be­trei­ber hat sich der Per­for­mance von Word­Press ver­schrie­ben, er hat noch eini­ge lesens­wer­te Tipps und Tricks zur Opti­mie­rung von Word-Press-Blogs. Sei­ne Sei­te lädt übri­gens in sagen­haf­ten 0,2 Sekunden. 

Der Stan­dart­be­nut­zer­na­me nach der Instal­la­ti­on in Word­Press ist admin. Die meis­ten las­sen es erst ein­mal dabei, so dass ein Groß­teil der WP-User sich mit die­sem Benut­zer­na­men anmel­det. Das wis­sen aber auch poten­zi­el­le Kri­mi­nel­le, damit muss also „nur“ noch das Pass­wort geknackt wer­den und schon hat der Angrei­fer die Mög­lich­keit, bspw. Schad­code in den Quell­text der Blog-Sei­te zu infil­trie­ren. Wenn das Pass­wort dann auch noch weni­ge Zei­chen oder eine Zah­len­fol­ge ent­hält, ist es nur Sache von weni­gen Minu­ten bis mit­tels einer Brut-Force Angriffs der Blog geknackt ist. 

Lei­der ist es aber auch so, dass Word­Press nicht die Mög­lich­keit bie­tet im Admin­be­reich den Benut­zer­na­men schnell zu ändern. Zwar besteht die Mög­lich­keit, einen neu­en Benut­zer mit ent­spre­chen­den Admin-Rech­ten zu erstel­len und den Benut­zer­na­men so zu ändern. Dabei muss aller­dings das Pass­wort und die E‑Mail Adres­se eben­falls erneu­ert, da man sich als ers­ten Benut­zer erst löschen kann, wenn man sich sel­ber als neu­en Nut­zer (Admin) ein­ge­tra­gen hat. 

Ein­fa­cher geht das gan­ze über die Daten­bank auf dem Ser­ver, wo die WP-Instal­la­ti­on liegt. Die Ände­run­gen müs­sen über die Benut­zer­ober­flä­che der Daten­bank bei MyS­QL-Daten­bank erfolgen.

Die Daten­bank aus­wäh­len, in der Word­Press instal­liert ist, Tabel­le wp_users auf Bear­bei­ten kli­cken, anschlie­ßend im Feld user_login den Namen „admin“ wie gewünscht ändern. Sobald das mit ok oder spei­chern bestä­tigt ist, ist die Anmel­dung mit dem alten Pass­wort (sofern nicht auch geän­dert) in der log­in Ober­flä­che möglich. 

BTW: das gan­ze eig­net sich natür­lich auch dazu, ver­ges­se­ne Benut­zer­na­men aus­zu­le­sen, sofern Benut­zer­na­me und Pass­wort des Hos­ters nicht auch ver­ges­sen wor­den sind 😉

Manch­mal pas­siert es bei Word­Press, dass Sei­ten nach einem Update bei Auf­ruf nur noch die 404 Sei­te prä­sen­tie­ren. Nach­weis­lich sind die Sei­ten da, jedoch bei Auf­ruf, auch aus dem Admin-Bereich ver­weist WP auf eine Fehlerseite. 

Kein Grund zur Panik, in den aller­meis­ten Fäl­len ist ein­fach die Per­ma­link Struk­tur durch­ein­an­der gera­ten. Das lässt sich leicht behe­ben. Im Admin-Bereich Ein­stel­lun­gen → Per­ma­links die Struk­tur auf Ein­fach stel­len, spei­chern und tes­ten ob es funk­tio­niert. Wenn es funk­tio­niert, kann danach die benut­zer­de­fi­nier­te Per­ma­link Struk­tur wie­der ange­klickt und gespei­chert werden. 

Ein Ver­zeich­nis in Word­Press umzu­be­nen­nen, weil man bei­spiels­wei­se nicht auf den Ord­ner /wordpress ver­wei­sen möch­te, ist rela­tiv simpel. 

Bei­spiel: www.meinesite.de/wordpress soll in www.meineseite.de/blog umbe­nannt werden. 

Das Ver­zeich­nis auf dem Ser­ver mit­tels dem ftp-Pro­gramm umbe­nen­nen. Die Pfa­de zum neu­en Ver­zeich­nis wer­den in der wp-config.php defi­niert, bzw. ange­passt. Den Code­schnip­sel hinzufügen,
define('WP_SITEURL', 'http://www.meineseite.de/blog');
define('WP_HOME', 'http://www.meineseite.de/blog');
wp-config.php hochladen.

In der Daten­bank mit­tels php-admin soll­te der Pfad unter wp-opti­ons eben­falls ange­passt wer­den. Danach soll­te das blog oder die Sei­te unter www.meineseite.de/blog zu errei­chen sein.