WP-Upgrade und Konfiguration

WordPress muss regelmäßig geupdatet werden, einfach aus Sicherheitsgründen. Geht relativ fix, ich mache es immer manuell.
Zuerst ein Backup, alle Dateien und die Datenbank. Die Datenbank lässt sich aus phpmyadmin heraus exportieren oder von der Konsole aus mit einem mysqldump-Befehl. Letzteres bietet sich bei größeren Datenbanken an:

mysqldump -u username -p passwort datenbankname > xyz.sql

Damit lässt sich dann alles wieder zurückspielen, falls etwas schief geht.

Dann können die Dateien aus dem Hauptverzeichnis gelöscht werden, außer wp-config, außerdem alle weiteren Verzeichnisse außer wp-content.

Die aktuelle WP-Version muss heruntergeladen werden und dann in das WP-Verzeichnis kopiert werde.

Als letzten Schritt muss aus dem Admin-Bereich per Klick noch die Datenbank aktualisiert werden.

Wichtig ist noch zu wissen welche Verzeichnis- bzw. Dateirechte WP braucht. Gehört nicht zum Update-Prozess, ist einfach wichtig

Hauptverzeichnis: schreibbar durch Nutzeraccount

wp-admin: schreibbar durch Nutzeraccount

wp-includes: schreibbar durch Nutzeraccount

wp-content: schreibbar durch Nutzeraccount und Webserver

So können die Rechte automatisch gesetzt werden:
Für Verzeichnisse:
find /path/to/your/wordpress/install/ -type d -exec chmod 755 {} \;

Für Dateien:
find /path/to/your/wordpress/install/ -type f -exec chmod 644 {} \;

Dies ist der Seite Hardening WordPress entnommen. Dort gibt es noch mehr Empfehlungen.

k-braungardt.de wegen phishing-content heute kurzfristig gesperrt

Hosteurope hat, einmalig in der Geschichte von k-braungardt.de, die Site gesperrt wegen phishing-content. Zuvor hatte ich bereits einen freundlichen Hinweis von Google erhalten. Das Zeugs war im wp-content/upload-Folder untergebracht, gestern laut timestamp.
HE hat mich aufgefordert die Dateien zu entfernen, WP zu updaten und alle Rechner mit FTP-Zugang einem Virenscan zu unterziehen.
Alles getan, mal schaun, ob da noch was nachkommt.

Subblog Registrations on WordPress 3.3.1

On WordPress Multisite it is not possible per default for users to register for sub-blogs. You are automatically redirected to the main blog.

This is how you can solve the problem in wp-login.php:

Sub Blog Setting is „Users can Register“: 1

Changes in wp-login.php:

1) In the Main part in case ‚register‘ two lines should be commented out: wp_direct and
exit. These are the lines responsible for redirecting to wp-sign-up with the Main Blog.
If the redirect does not take place, users can register with the Sub Blog.

case ‚register‘ :
// Multisite uses wp-signup.php
//wp_redirect( apply_filters( ‚wp_signup_location‘, site_url(‚wp-signup.php‘) ) );
//exit;

With these changes users can register only once for one Sub Blog. For another Sub Blog
they would have to log in with a new account. To allow students to register with multiple
Sub Blogs further changes have to be made in wp-login.php.

2) For multiple Sub Blog Registration the function „register_new_user“ is supplemented
by the following request: If a user is already registered username and email both have to
be existent. If they both exist, the user is added as a subscriber to the blog:
Following the line: $user_email = apply_filters( ‚user_registration_email‘, $user_email );
these lines are added:

if( username_exists( $sanitized_user_login ) && email_exists( $user_email ) )
{

$userid = username_exists($sanitized_user_login);
$blogid = $GLOBALS[‚current_site‘]->site_id;
add_user_to_blog($blogid, $userid, „subscriber“);
}
else
{

The closing bracket is placed before return $user_id;

3. What does the user get? The user goes to register for the Sub Blog and fills in his or her
username and email adress. With first time registering a password is sent to the person’s
email adress. If already registered, there is no password sent. So it would be nice to read
this somewhere on the screen too.
In the Main part in case ‚register‘ following the line
the message can be changed to: A password will be e-mailed to you, if you register for the
first time.

4. Users are registered with default role as subscriber. Roles can be easily changed in the
Blog Settings.

WordPress upgrade auf 2.8.4

Nach dem Upgrade funzten die Umlaute auf einmal nicht mehr. Toll. Eine Suche im Netz ergab keine Spur. In den WordPress-Einstellungen fand ich nichts. Neue Einträge waren nicht betroffen. Ich habe einen Blick in die Datenbank geworfen und dort als collate „latin1_german2_ci“ gefunden. In der config-datei stand Folgendes:

define('DB_CHARSET', 'utf8'); // Der Datenbankzeichensatz sollte nicht geändert werden
define('DB_COLLATE', '');

Die Zeilen habe ich den Tatsachen angepasst:

define('DB_CHARSET', 'latin1_german2_ci'); // Der Datenbankzeichensatz sollte nicht geändert werden
define('DB_COLLATE', 'latin1_german2_ci');

Das hat funktioniert, d.h. den CHARSET und COLLATE auf die Werte setzen, die tatsächlich in der Datenbank stehen.