Seit einigen Wochen gelten bei Gmail / Googlemail (und ab Februar 2024 auch bei Yahoo) verschärfte Richtlinien gegen Spam: so berichteten etliche Kunden, Freunde und Bekannte, dass sie keine Mails mehr an Gmail-Adressen senden können, jeder Sendeversuch führt zu einer Fehlermeldung: 

Final-Recipient: rfc822; XXXXXX@gmail.com
Original-Recipient: rfc822;XXXXXX@gmail.com
Action: failed
Status: 5.7.26
Remote-MTA: dns; gmail-smtp-in.l.google.com
Diagnostic-Code: smtp; 550-5.7.26 This mail has been blocked because the sender
   is unauthenticated. 550-5.7.26 Gmail requires all senders to authenticate
   with either SPF or DKIM. 550-5.7.26  550-5.7.26  Authentication results:
   550-5.7.26  DKIM = did not pass 550-5.7.26  SPF [YYYYYY.at] with ip:
   [XX.XX.XXX.XX] = did not pass 550-5.7.26  550-5.7.26  To mitigate this
   issue, please visit Gmail's authentication guide 550-5.7.26 for
   instructions on setting up authentication: 550 5.7.26
   https://support.google.com/mail/answer/81126#authentication

Der Grund ist recht einfach – die Behebung des Problems auch: wahrscheinlich fehlt für die Domain des Absenders ein SPF-Eintrag! Aber der Reihe nach:

Weiterlesen

In den nächsten Tagen werden wohl viele WordPress-Websites im Dashboard eine php-Aktualisierung empfehlen: denn seit 28.11.2022 ist php 7.4. nun endgültig tot und wird nicht mal mehr mit den nötigsten Sicherheitsupdates versorgt. Eine Aktualisierung ist also empfehlenswert – aber wie macht man dieses php-Update? Und was überhaupt ist php?

Weiterlesen

Das Error-Log ist eine wichtige Hilfe, um die Ursache für Fehlermeldungen auf Websites herauszufinden. Der Server schreibt dort rein, welche Dateien welche Fehlermeldung verursacht haben. Beim Provider all-inkl werden aber normalerweise keine Log-Dateien angelegt, was die Fehlersuche anfangs etwas mühsam macht. Aber das kann man sehr einfach aktivieren – man braucht dazu lediglich FTP-Zugang auf den Server und sollte wissen, welche php-Version am Server läuft (7.x oder 8.x).

Weiterlesen

Heute stand ich vor der Aufgabe, die WordPress-Website eines Kunden per Duplicator-Plugin von World4you zur Weiterentwicklung auf einen Testserver zu überspielen. Das Erstellen des Archivs und des Installers funktionierte problemlos, allerdings spuckte der Server beim Versuch, die beiden Dateien herunterzuladen, eine Fehlermeldung aus: “Internal Server Error – The server encountered an internal error or misconfiguration and was unable to complete your request. Your administrator may not have enabled CGI access for this directory.”

Nach kurzer Suche war der Schuldige schnell gefunden: der Duplicator legt seine Dateien im Verzeichnis /wp-snapshots ab. Dort wird bei der Installation eine Datei namens .htaccess angelegt, deren Inhalt nur dafür sorgen soll, dass beim direkten Aufrufen des Verzeichnisses der Inhalt nicht aufgelistet werden kann. Und das mag der World4you-Server offenbar gar nicht, denn diese Einstellung kann man im Kundenbereich my.world4you.com unter “Webspace -> Einstellungen -> Weitere Server-Einstellungen” global für alle Verzeichnisse setzen: wenn hier “Directory Listing” auf AUS gesetzt ist, kann die .htaccess mit diesem Inhalt getrost entfallen.

Abhilfe also: Directory Listing im Kundenbereich auf AUS, .htaccess (NUR die Datei im Verzeichnis /wp-snapshots – NICHT die .htaccess im Hauptverzeichnis!!!!!) löschen – und der Download der Duplicator-Files klappt einwandfrei.

Interessanter Artikel letztens bei Sistrix: Want to slowly kill your content on Google? Simply use a directory structure with dates. Kurz zusammengefasst raten die Profis davon ab, in URLs das Datum einzubauen, wie es etwa in WordPress möglich ist. Denn derartige Artikel rutschen stetig im Ranking nach hinten, bis sie praktisch unfindbar werden. Ich kann ein Lied davon singen – da ich seit August 2000 blogge, gibts über 2000 Beiträge online, von denen allerdings ein Gutteil bereits so nach hinten gerutscht ist, dass sie kaum mehr aufgerufen werden. Ich hatte schon längere Zeit die URLs im Verdacht, daran mit schuld zu sein.

Also Umstellung der URLs auf ein Format, das Google mehr mag. Weiterlesen

Wenn man WordPress-Themes entwickelt oder den Auftrag zur Weiterbearbeitung bekommt, ist es oft wichtig herauszufinden, mit welcher Template-Datei die aktuell angezeigte Seite gerendert wird. Das lässt sich einfach herausfinden: einfach den folgenden Codeschnipsel in die Datei functions.php des verwendeten Themes kopieren, dann wird die verwendete Template-Datei für eingeloggte User in einem HTML-Kommentar im Header der Seite ausgegeben:
add_action('wp_head', 'show_template');
function show_template() {
global $template;
if(is_user_logged_in()) {
echo '\n\n<!--// Template: '; print_r($template); echo '//-->\n\n';
}
}

Ein durchaus gut gemeintes Feature seit WordPress 2.6 ist die Versionsverwaltung von Artikeln. Gut, wenn man jederzeit zu einer früher gespeicherten Version eines Artikels zurückkehren kann. Ausserdem speichert WordPress nun im 60-Sekunden-Intervall selbsttätig den Artikel, an dem man gerade arbeitet. So kommen allerdings rasch recht viele Versionen eines Artikels zustande – in den meisten Fällen sicherlich zu viele. Man kann die Versionsverwaltung und die Autosave-Zeit durch Einträge in der wp-config.php recht einfach anpassen:

// Limitiert die Anzahl der gespeicherten Versionen je Artikel auf 5 Stück
define('WP_POST_REVISIONS', 5);
// Je nach Lust & Laune den gewünschten Wert eintragen

// Setzt den Abstand zwischen den automatischen Speicherungen auf 600 Sekunden
define('AUTOSAVE_INTERVAL',600);
// Je nach Lust & Laune den gewünschten Wert in Sekunden eintragen

Mit folgendem Eintrag in der wp-config.php schaltet man die Versionsverwaltung ganz ab – es wird also nur der jeweils aktuelle Stand gespeichert und keine alten Versionen behalten:

// Versionsverwaltung abschalten
define('WP_POST_REVISIONS',false);

Sicherheitshalber mach bitte vor Änderungen eine Sicherheitskopie der wp-config.php!