Archiv

Archiv für die Kategorie ‘Blog’

WordPress Fehlermeldungen nach Update auf Version 4.6

21. August 2016 Keine Kommentare

Grade das neue Update auf WordPress Version 4.6 installiert und feststellen müssen, dass anschließend Fehler-/Warnmeldungen auf der Seite und im Admin-Panel angezeigt werden. In der wp-config.ini nachgesehen, ob hier falsche Einstellungen vorliegen, aber daran lag es schonmal nicht:

@ini_set('display_errors', 0);
define('WP_DEBUG', false);

Nach etwas Suchen bin ich dann aber auf WordPress.org fündig geworden. Im Ticket #37680 wurde der Fehler erfasst und auch ein funktionierender Workaround veröffentlicht.

Nach den vorgeschlagenen Änderungen an der Datei load.php ist das Problem behoben. Mit dem nächsten Update auf 4.6.1 soll der Wordaround auch offiziell verteilt werden, aber bis dahin kann es noch ein paar Tage dauern.

Alternativ kann man auf seinem Server auch in der php.ini die Nutzung von ini_get_all() aktivieren, sofern man die Möglichkeit hat. Hier auf Pytal kann man die Einstellungen nicht eigenständig ändern, sondern ist auf den Serverbetreiber angewiesen.

WordPress – Wartungsmodus nach fehlgeschlagenem Update

7. Juni 2012 Keine Kommentare

Aus aktuellem Anlass, da mir das grad selbst passiert ist: Führt man, bequem wie man ist, direkt in WordPress ein Update durch, schaltet sich WP für die Dauer des Updates in den Wartungsmodus. Ruft man während dieser Zeit eine beliebige Seite des Blogs auf, erhält man lediglich die Meldung „Für kurze Zeit nicht verfügbar um eine regelmäßige Instandhaltung durchzuführen. Prüfe in einer Minute nochmals.

Eigentlich eine super Sache, damit niemand Änderungen an der DB vornehmen kann (Kommentar, neuer Artikel, etc.), während diese womöglich grade aktualisiert wird. Blöd nur, wenn die Meldung nicht wieder verschwinden will. Das Update für ein kleines, einfaches Plugin wird kaum mehrere Minuten Zeit in Anspruch nehmen, so dass man sich schnell die Frage stellt, wie man diesen Zustand wohl wieder beseitigen und den normalen Betrieb des Blogs wieder herstellen kann.

Nach kurzer Suche bin ich bei Vanderelbe fündig geworden. Zur Lösung des Problems benötigt man FTP-Zugang. Dann sucht man im Hauptverzeichnis von WordPress nach der Datei .maintenance und löscht selbige. Fertig, die Seite funktioniert wieder wie gewohnt.

Sollte man grad kein FTP-Programm zur Hand haben oder hinter einem Proxy sitzen, der keine FTP-Verbindungen zulässt, so ist es äußerst hilfreich, wenn der Hoster den Zugang via WebFTP anbietet. Oder man installiert auf seinem Space eine eigene Lösung, z.B. den phpXplorer.

WordPress Kontaktformular ohne Mail Versand

13. April 2012 Keine Kommentare

Möchte man für Besucher seiner Seite schnell und einfach erreichbar sein, bietet man ihnen einfach ein Kontaktformular an. Für diese Aufgabe gibt es auch unzählige Plugins. Dumm nur, wenn die Mail-Funktionen des Servers gesperrt sind. Pytal verbietet grundsätzlich erstmal den Versand, will man doch die eMail Funktion, so muss man betteln gehen. Einmal hab ich schon solch eine Anfrage gestellt, sogar nach den Vorgaben und Richtlinien im Forum, diese wurde aber trotzdem kommentarlos abgelehnt.

Daher musste nun erstmal ein Kontaktformular her, das in der Lage ist, die Formulardaten auf dem Server zu speichern, statt sie zu versenden. Recht zufrieden bin ich bisher mit MM Forms Community, da es dieer Aufgabe sehr gut nachkommt und wahlweise auch noch zusätzlich den Mailversand durchführen kann. Sobald die Funktion freigeschaltet sein sollte, kann ich also mit nur einem Klick in den Einstellungen wechseln, ohne mir ein neues Plugin suchen zu müssen.

Allerdings hat das Plugin auch einen kleinen Haken, zumindest temporär. Version 2.2.5 funktioniert im aktuellen WordPress nämlich nicht ganz fehlerfrei. Möchte man sich empfangene Nachrichten im Backend ansehen, erhält man lediglich eine Fehlermeldung. Die Anzeige der Nachrichten im Frontend hingegen funktioniert tadellos, nur geht deren Inhalt niemanden außer meiner einer etwas an 😉

Drum musste ein kleines Script her, welches in der Lage ist zu erkennen, ob grad jemand angemeldet ist und zudem noch über Admin-Rechte verfügt. Im WordPress Forum bin ich fündig geworden und hab die entsprechende Funktion gleich auf der Kontakt-Seite umgesetzt.

<?php global $current_user; get_currentuserinfo(); ?>
<?php if ($current_user->user_level == 10 ) { ?>
  [fοrmdata 1 "Kontaktformular"]
<?php } else {   ?>
  [fοrm 1 "Kontaktformular"]
<?php } ?>

Jetzt kann man mir unkompliziert Nachrichten senden und ich kann auf der selben Seite sehen, worum es denn überhaupt geht. Das einzige, was jetzt noch etwas skeptisch macht, ist das Captcha… das sieht mir etwas zu einfach aus, als das es wirklich effizient Spam-Bots abhalten könnte. Aber das wird sich erst noch zeigen müssen.

Mehr Sicherheit für WordPress

29. März 2012 Keine Kommentare

Nachdem ich mich in letzter Zeit ein wenig mit SEO beschäftigt habe, und die Seite dahingehend etwas optimiert habe, kam mir nun das Thema Sicherheit in den Sinn. Aber da dies mein erster Blog ist, kann ich diesbezüglich auf keinen allzu großen Wissenschatz zurückgreifen, sondern muss mich an den Hinweisen und Empfehlungen anderer orientieren. Als hilfreich habe ich dabei die foldenden Seiten empfunden:

Ich werde aber selbst auf die aus meiner Sicht wichtigsten Punkte nochmal genauer eingehen. Ich gehe dabei von einer vorhandenen Installation mit der Version 3.3.1 aus.

 
1. Admin-Account sinnvoll benennen

Der bei der Blog-Installation angelegte Admin-Account sollte nicht admin heißen! Ideal wäre ein Name, der nicht im direkten Zusammenhang mit der URL oder dem Thema des Seite steht. Der eigene Nickname sollte ebenfalls nicht genutzt werden. Hat man sich daran schon bei der Installation gehalten, kann man den folgenden Absatz überspringen, andernfalls weiterlesen.

Lege einen neuen Benutzer mit Admin-Rechten an, vergebe einen passenden Namen und nutze ein sicheres Passwort. Anschließend mit dem neuen Account einloggen und den alten Account löschen. Man wird gefragt, was mit den vorhandenen Inhalten des Benutzers passieren soll, hier wählt man die Übernahme auf den neuen Account.

Wähle im Profil auf jeden Fall aus, dass der angezeigte Name nicht der Benutzername ist.

Eine Sache fehlt aber noch: die ID des Accounts in der Datenbank hat nun noch immer die 1 oder, wenn es keine anderen Benutzer gibt, die 2. Das wissen auch potentielle Angreifer. Daher sollte man diese ID auf einen zufälligen Wert ändern. Dazu läd man sich entweder ein Plugin wie Search & Replace, öffnet phpMyAdmin oder greift sonst wie auf die Datenbank zu.

Es muss in 4 Tabellen je ein Wert geändert werden, und zwar in wp_users, wp_usermeta, wp_posts und wp_links. Im folgenden SQL-Statement nehme ich exemplarisch die ID 194, diese Zahl sollte aber jeder selbst festlegen. Die aktuelle ID muss selbstverständlich auch angepasst werden.

UPDATE wp_users    SET ID          = 194 WHERE ID          = 1;
UPDATE wp_usermeta SET user_id     = 194 WHERE user_id     = 1;
UPDATE wp_posts    SET post_author = 194 WHERE post_author = 1;
UPDATE wp_links    SET link_owner  = 194 WHERE link_owner  = 1;

 
2. Tabellen-Präfix != wp_

Was bei der Installation dem Benutzernamen das admin ist dem Tabellen-Präfix das wp_. Auch hier sollte man eine Änderung in Betracht ziehen. Je nachdem, wie viele Tabellen man noch in seiner Datenbank hat, kann es sinnvoll sein, das Präfix mit bestimmten Zeichen beginnen zu lassen, um die Position der WordPress-Tabellen bei der Sortierung zu beeinflussen.

In der Basisinstallation umfasst dies 11 Tabellen, die ich nachfolgend schon mal als fertiges SQL-Statement vorbereitet habe. Das Präfix wird für dieses Beispiel auf 19a7Z4_ gesetzt.

RENAME TABLE wp_commentmeta        TO 19a7Z4_commentmeta;
RENAME TABLE wp_comments           TO 19a7Z4_comments;
RENAME TABLE wp_links              TO 19a7Z4_links;
RENAME TABLE wp_options            TO 19a7Z4_options;
RENAME TABLE wp_postmeta           TO 19a7Z4_postmeta;
RENAME TABLE wp_posts              TO 19a7Z4_posts;
RENAME TABLE wp_terms              TO 19a7Z4_terms;
RENAME TABLE wp_term_relationships TO 19a7Z4_term_relationships;
RENAME TABLE wp_term_taxonomy      TO 19a7Z4_term_taxonomy;
RENAME TABLE wp_usermeta           TO 19a7Z4_usermeta;
RENAME TABLE wp_users              TO 19a7Z4_users;

Wenn man Plugins installiert hat, können es auch durchaus mehr Tabellen sein. Diese müssen dann ebenfalls umbenannt werden.

Damit allein ist es aber noch nicht getan, es sind noch weitere Schritte notwendig, damit WordPress weiterhin fehlerfrei seinen Dienst verrichtet. In der Tabelle 19a7Z4_options und evtl. auch in 19a7Z4_usermeta müssen noch Einträge abgeändert werden.

UPDATE 19a7Z4_options  SET option_name = REPLACE(option_name,'wp_','19a7Z4_');
UPDATE 19a7Z4_usermeta SET meta_key    = REPLACE(meta_key,   'wp_','19a7Z4_');

Zu guter letzt muss die Datei wp-config.php bearbeitet werden, damit WordPress das neue Tabellen-Präfix auch bekannt ist.

$table_prefix  = '19a7Z4_';

 
3. Verzeichnisschutz für wp-content und wp-includes

In diesen Verzeichnissen liegt nichts, worauf ein Besucher direkt zugreifen müsste, außer vielleicht den Uploads. Daher sollte man sie auch entsprechend absichern. In jedes Verzeichnis kommt eine .htaccess mit folgendem Inhalt:

Order Allow,Deny 
Deny from all 
<Files ~ ".(css|jpe?g|png|gif|js|svg)$"> 
  Allow from all 
</Files>

Grundsätzlich wird der Zugriff auf alle Dateien in diesen Verzeichnissen verboten, mit Ausnahme bestimmter Dateiendungen, die man individuell anpassen und ergänzen sollte.

 
4. Verzeichnisschutz für wp-admin oder nur wp-login.php ?

Diese Frage ist auf Playground sehr gut beantwortet und erläutert worden. In vielen Anleitungen wird dazu geraten, den kompletten Ordner wp-admin via .htaccess und .htpasswd zu schützen. Da WordPress aber auch außerhalb des Backends auf die Dateien in dem Verzeichnis zugreifen kann, wäre ein reibungsloser Betrieb für normale Besucher nicht gewährleistet. Daher wird nur die Datei wp-login.php zusätzlich geschützt.

# protect wp-login.php
<files wp-login.php>
  AuthType Basic
  AuthName "Admin-Bereich"
  AuthUserFile /absoluter-serverpfad/.htpasswd
  require valid-user
</files>

Ein doppelter Login also. Muss man aber nur machen, wenn man seinen für WordPress gewählten Benutzernamen und das Passwort für unzureichend hält… aber ob dann ein zusätzlicher Schutz mit ähnlich schwachen Daten die Situation großartig verbessert, darf angezweifelt werden.

Aus meiner Sicht nicht notwendig, für Sicherheitsfanatiker aber garantiert eine tolle Option 😉

 
5. Umgang mit fehlerhaften Login-Versuchen

Man kennt es von vielen Seiten, x-mal das Password falsch eingegeben, schon kann man sich erstmal Kaffee kochen gehen oder gleich den Support anrufen. WordPress bietet diesen Luxus von Haus aus nicht, aber er lässt sich leicht über Plugins nachrüsten. Limit Login Attempts oder Login LockDown sind zwei Vertreter dieser Plugin-Gattung, die Konfiguration sollte selbsterklärend sein.

 
6. Fehlerhinweise auf der Login-Seite ausblenden

Es ist immer wieder schön, wenn man die Zugangsdaten vergessen hat, und einem die Seite genau sagt, wo der Fehler liegt. So macht es auch WordPress und sagt einem genau, ob der Benutzername oder nur das Passwort falsch sind. Für einen selbst eine tolle Hilfe, aber leider auch für jeden anderen, der Zugang haben will.

Daher sollte man auch hier entweder mit Plugins wie WSD security arbeiten oder selbst die entsprechenden Änderungen im Quelltext vornehmen. Bei iNove zeigt das Plugin jedenfalls keine Wirkung, aber das kann durchaus am Theme liegen.

Man öffne also die Datei functions.php im iNove-Verzeichnis und kopiere folgende Zeile an den Anfang der Datei:

add_filter('login_errors',create_function('$a', "return null;"));

 
7. Versionsnummer nicht mehr ausgeben

WordPress gibt seine aktuelle Versionsnummer immer als meta-Tag aus. Eine wertvolle Information, weiß man so doch gleich, ob WordPress aktuell ist und welcher Exploit am ehesten Erfolg haben kann. Also weg mit der Information. Auch zu diesem Zweck gibt es wieder viele Plugins (erneut sei WSD security genannt) oder die Möglichkeit, händisch vorzugehen.

Man muss dafür im Theme-Verzeichnis entweder in der header.php oder der index.php die Zeile, in welcher der meta-Tag erzeugt wird, löschen.

<meta name="generator" content="WordPress <?php bloginfo('version'); ?>" />

Da die Version aber auch im RSS-Feed angegeben wird, und einige Funktionen und Plugins diese Information auch benötigen, kann man die Versionsnummer leider nicht ganz löschen. Das Ausblenden via Plugin scheint daher am flexibelsten.

Zudem sollte man noch den Zugriff auf zwei Dateien unterbinden, in denen die Versionsnummer ebenfalls nachzulesen ist: liesmich.html und readme.html. Einige Seiten empfehlen deren Löschung, was man dann aber nach jedem Update wiederholen darf. Als eine langfristige Lösung scheint mir hier der Einsatz von .htaccess hilfreich zu sein.

# protect liesmich.html
<files liesmich.html>
  Order deny,allow
  deny from all
</files>

# protect readme.html
<files readme.html>
  Order deny,allow
  deny from all
</files>

 
Fazit

Mit ein paar relativ einfachen Aktionen kann man die Sicherheit von WordPress ein gutes Stück erhöhen, auch wenn es zugleich etwa schade ist, dass man als normaler Nutzer überhaupt an sowas denken muss, denn einige Dinge könnten bereits voreingestellt ausgeliefert werden.

Aber so hat man zumindest immer mal wieder etwas neues, um sich zu beschäftigen ^^

Server wieder erreichbar

2. März 2012 Keine Kommentare

Da hat man grad erst mit einem Blog angefangen, schon wird man im Schreibwahn abrupt ausgebremst. Als ich nach meinem Kurzurlaub am Dienstag wieder online war, musste ich feststellen, dass diese Seite nicht mehr erreichbar ist. Und obwohl ich bisher noch nicht allzu viel geschrieben habe, hatte ich dennoch etwas Sorge, dass die Inhalte futsch sein könnten. Schließlich weiß man nie, was man von einem Free-Hoster nun genau halten und erwarten soll, wenn es um Themen wie Datensicherheit und Datensicherung geht.

Keine Ahnung, ob das Problem schon vor Dienstag bestand, aber es dauerte immerhin bis zum heutigen Freitag (also mindestens 3 Tage), bis die Seite wieder erreichbar war. Laut Pytal waren die Server Opfer einer großen DDoS-Attacke, was man wohl so hinnehmen muss, auch wenn es schwer fällt zu glauben, dass jemand solchen Aufwand betreibt, nur damit ein paar private Webseiten nicht mehr erreichbar sind.

Egal, nun funktioniert ja alles wieder und ich habe eine wertvolle Lektion gelernt: Mach gefälligst Backups! Denn hätte ich ein Backup gehabt, würde die Seite jetzt nicht mehr bei Pytal laufen, sondern ich wäre spätestens Mittwoch zu einem anderen Anbieter umgezogen, vorzugsweise einem, wo man auch ohne großen Umstand die Mail-Funktion nutzen kann…

Von den ersten 10k fertiggestellter Raspberry Pi habe ich leider erwartungsgemäß keinen abbekommen, ansonsten wäre die Frage nach einem Hoster inzwischen hinfällig gewesen. Mal schauen, wie es Ende März läuft, da wird wahrscheinlich die nächste Ladung unters Volk gebracht.

WordPress personalisieren

9. Februar 2012 Keine Kommentare

Das Blog installieren und sich bei Bedarf noch ein fertiges Theme im Internet suchen, schon ist der Großteil der Benutzer zufrieden. Allerdings gehöre ich nicht zu dieser Gruppe. Da Design nicht grade eine meiner Stärken ist, werde ich zwar darauf verzichten, irgendwann ein eigenes Theme zu erstellen, und mich auf fertige Vorlagen stützen, aber dennoch muss dieser Blog ein wenig personalisiert werden. Einiges ist halt aus meiner Sicht nicht ganz optimal in der Standardkonfiguration.

 
Das richtige Design

Ich bin ein Freund von relativ einfachen Designs, zu viel Informationen auf engem Raum und agressive Farben überlasse ich gerne anderen.

Zwei Themes kamen bei der Suche in die engere Auswahl: zBench und iNove. zBench war mein ursprünglicher Favourit, da es wie ich finde einen etwas harmonischeren Eindruck macht. Allerdings störte mich das vollständige Fehlen eines typischen Headers dann doch so sehr, dass meine Wahl letztlich auf iNove viel. Zwar hat das Theme mit der Darstellung von CSS Dropdown-Menüs Probleme, aber das wird ja vielleicht noch in einer der späteren Versionen behoben. Außerdem brauche ich diese Funktion vorerst eh nicht.

 
Login im Header

Die erste wichtige Anpassung betrifft das An- und Abmelden am System. In der Standard-Seitenleiste rutscht dieser Punkt im Laufe der Jahre bei aktiver Blog-Nutzung immer weiter nach unten und ein extra Lesezeichen dafür halte ich für Verschwendung, also muss daran was geändert werden. Da mir die Seitenleiste aber derzeit so wie sie ist ganz gut gefällt, muss eine andere Lösung her.

Der Header. Man kennt es von vielen Seiten, oben rechts stehen die immer gleichen Links. Ob das auch bei WordPress geht? Klar, und zwar sehr einfach über den Admin-Bereich:

Design -> Aktuelle Themen Optionen -> Banner

In dem Eingabefeld kann man den Inhalt des Headers einfügen und mit HTML und CSS formatieren. Allerdings ist es damit noch nicht getan, denn selbst mit Plugins kann man in dem Feld keinen PHP-Code platzieren, was aber unverzichtbar ist, wenn man einen dynamischen Link zum An- und Abmelden haben möchte. Über das Feld kann man nur statische Links vorgeben.

Also muss man direkt in der entsprechenden Datei Änderungen vornehmen. Zu finden ist diese beim iNove-Theme in folgendem Verzeichnis:

/wp-content/themes/inove/templates/header.php

Hier fügt man nun an der markierten Stelle den zusätzlichen Code ein:

<!-- header START -->
<div id="header">

	<!-- banner START -->
	<?php if( $options['banner_content'] && (
		($options['banner_registered'] && $user_ID) || 
		($options['banner_commentator'] && !$user_ID && isset($_COOKIE['comment_author_'.COOKIEHASH])) || 
		($options['banner_visitor'] && !$user_ID && !isset($_COOKIE['comment_author_'.COOKIEHASH]))
	) ) : ?>
		<div class="banner">
			<?php wp_loginout(); ?> 
			<?php echo($options['banner_content']); ?>
		</div>
	<?php endif; ?>
	<!-- banner END -->

Diese Zeile bewirkt, dass oben rechts im Header ab sofort immer der An- oder Abmelden Link angezeigt wird, allerdings nur, wenn im Admin-Bereich auch der Haken zum Banner anzeigen gesetzt ist. Alle Eingaben in dem Textfeld des Banners werden nun hinter dem An- / Abmelden-Link angezeigt.

Möchte man jetzt abschließend noch die Link-Farbe ändern, ohne dass die Änderung gleich im ganzen Blog gültig wird, muss der Code nochmals leicht angepasst werden:

<?php echo str_replace('">','" style="color:#CCCCCC">',wp_loginout(false,false)); ?> 

Das ist die schlichteste Variante, natürlich kann man ebenso eine neue ID vergeben und die CSS Datei des Themes anpassen. Wäre sauberer, mir aber grad etwas zu viel unnötiger Arbeit.

 
Mehr Funktionen durch Plugins

SyntaxHighlighter Evolved
Sehr hilfreich, wenn man in den Beiträgen Code veröffentlichen und Syntax-Highlighting zur besseren Lesbarkeit einsetzen möchte.

Exclude Pages from Navigation
Seiten werden, wenn es das Theme unterstützt (im Falle iNove horizontal neben dem Home-Button) automatisch aufgelistet und verlinkt. Wenn man aber nicht jede erstellte Seite dort stehen haben möchte, ist dieses Plugin sehr hilfreich. Beim Erstellen einer Seite kann man nach der Installation festlegen, ob diese Seite aufgelistet werden soll oder nicht.

Contact Form 7
Da die Rechtsprechung bezüglich Webseiten inzwischen kaum noch durchschaubar ist (ab wann ist eine private Seite nicht mehr als privat anzusehen? Braucht man ein Impressum?) und keiner diese Fragen zu beantworten vermag, sollte man sich überlegen, ob man nicht lieber auf Nummer Sicher geht und seine Seite um ein kleines Impressum und ein Kontaktformular ergänzt. Kostet auf jeden Fall weniger als eine mögliche Abmahnung eines dieser parasitären Geschwüre der Gesellschaft.

Allow PHP in posts and pages
Eigener Code innerhlab eines Artikels oder einer Seite, die mit WordPress erstellt wurde. Kein Problem, mit diesem Plugin ist es möglich. Bei Interesse kann man so den Inhalt seiner Artikel dynamisch generieren, eigene Datenbanken einbinden, etc.

Akismet
Wird von WordPress mitgeliefert, und das aus gutem Grund. Wer keine Lust auf Spam hat, sollte sich das Plugin mal näher ansehen.

Und wieder ein neuer Blog…

7. Februar 2012 Keine Kommentare

So, nach langem hin und her, ob nun Webseite oder Blog, ist die Entscheidung gefallen, es wird langfristig beides geben.

Da die Webseite bisher nur als grobes Konzept existiert, nehme ich vorerst nur den Blog in Betrieb.  In der Anfangszeit noch auf Pytalhost, aber sobald der Röddelkiste auf meinen Schultern was brauchbares eingefallen ist, wird auf einen eigenen Server mit TLD umgezogen.

Wenn alles so klappt, wie ich mir das vorstelle, dann wirds hier regelmäßig neues zu lesen geben…allerdings nicht speziell zu einem bestimmten Thema, sondern alles, was mir so in den Sinn kommt. Spezialisierte Webseiten gibt es schon genug, da muss auch Platz für etwas Chaos und Unordnung sein 😀