Wer also ohnehin plant, eine (Pro-)Lizenz zu kaufen: macht das JETZT, denn ab „early 2020“ kostet der Unlimited-Websites-Account 150% mehr als derzeit – pro Jahr! Die Lifetime-Lizenz gibts dann gar nicht mehr (siehe Bild unten).
Bestehende Lizenzen aus 2019 bleiben aber zu den derzeitigen Bedingungen gültig!

Website für reCaptcha v3 registrieren: Die API-Keys der Version 2 funktionieren nicht mehr. Also auch wer schon bisher reCaptcha 2 genutzt hat, muss seine Website neu registrieren. Melde dich in deinem Google-Konto an und geh auf die Verwaltungsseite für reCaptcha. In der Box „Neue Website registrieren“ trägt man den Namen der Website ein, hakt reCaptcha v3 an und gibt an, für welche Domain(s) der Key gelten soll. Hier reicht es, den Domainnamen ohne http oder www einzutragen, also in meinem Fall etwa egm.at – Subdomains sind automatisch mit inkludiert. Danach noch „Nutzungsbedingungen akzeptieren“ anhaken und auf „Registrieren“ klicken.

Keys abrufen & in der Website eintragen: im nächsten Bildschirm werden zwei Schlüssel angezeigt, der Website-Schlüssel und der Geheime Schlüssel. Diese beiden Schlüssel müssen nun im Admin-Bereich deiner Website unter Formulare -> Integration -> reCaptcha -> Setup Integration eingetragen werden.

Fertig – deine Formulare nutzen nun allesamt reCaptcha, um Einträge von Spam-Bots zuverlässig abzuwehren – ganz ohne „Ich bin ein Roboter“-Abfragen oder irgendwelche unleserlichen Zeichen, die man erst entschlüsseln muss. Die früher nötigen Formular-Tags [recaptcha] sind nicht mehr nötig und können entfernt werden. Ab Version 5.1 ersetzt Contact Form 7 diese Tags bei der Formularausgabe selbständig durch Leerzeichen.

Nachtrag 15.1.2020: ich selbst setze ReCaptcha auf Kundenwebsites bewusst NICHT oder nur auf ausdrücklichen Kundenwunsch ein. Das Tool lädt ziemlich viel JavaScript nach, das kann Websites deutlich ausbremsen!

Wie bei jeder Hauptversion von WordPress ist es auch diesmal empfehlenswert, mit dem Update noch etwas zu warten. Dazu ein kurzer Exkurs: Hauptversionen („Major Release“) sind an der ersten und zweiten Stelle der Versionsnummer erkennbar (auf 4.8 folgt 4.9 und darauf eben jetzt 5.0). Die Sicherheitsupdates („Minor Release“) erkennt man an der dritten Stelle der Versionsnummer (auf 4.9.7 folgte 4.9.8, die aktuellste 4er-Version). Sicherheitsupdates werden normalerweise automatisch eingespielt, sobald sie verfügbar sind. Das funktioniert einwandfrei, es ist also dringend anzuraten, diese Funktion eingeschaltet zu lassen!

WordPress-Hauptversionen werden nie automatisch eingespielt, sondern man muss das Update manuell starten. Bei jeder Hauptversion gibt es ein Thema, auf das die Entwickler besonders Wert gelegt haben – bei Version 5.0 ist es die Implementierung des neuen Editors. Dieser ist zum früheren Editor inkompatibel, auch viele Themes und Plugins vertragen sich noch nicht damit, weil die jeweiligen Autoren mit den Anpassungen an Gutenberg bis zuletzt gewartet haben. Die Chance ist also hoch wie nie, dass nach dem Update auf 5.0 manche Teile eurer Website nicht mehr wie vorher funktionieren oder aussehen oder dass die Bearbeitung eurer Inhalte nicht mehr funktioniert!

Wartet also getrost noch bis ins neue Jahr ab, bevor ihr das Update auf 5.0 installiert – es entgeht euch nix. Denn Sicherheitsaktualisierungen bekommt ihr weiterhin auch für die bestehenden WordPress-Versionen automatisch eingespielt (das nächste Update für die aktuelle Version wird die Versionsnummer 4.9.9 tragen), meist werden auch wesentlich ältere WordPress-Versionen bis hinunter zu 3.7 noch zeitnah mit sicherheitskritischen Updates versorgt, sollten gravierende Lücken entdeckt werden. Plugins & Themes könnt ihr auch weiterhin regelmäßig aktualisieren, da die Autoren derzeit ohnehin auch noch mit dem alten Editor kompatibel bleiben werden.

Wer es dennoch eilig hat, auf 5.0 zu wechseln: zuerst ein Komplettbackup machen, das ihr im Notfall auch selbst wieder einspielen könnt. Dann sicherheitshalber das Plugin Classic Editor installieren, mit dem im Bedarfsfall der alte Editor wieder aktiviert werden kann. Danach Plugins & Themes aktualisieren, am Schluss erst WordPress auf 5.0 updaten. Zuletzt noch eine letzte Kontrolle, ob es weitere Plugin-Updates gibt, die erst verfügbar angezeigt werden, wenn WordPress aktualisiert wurde. Sollte irgendetwas nicht wie gewohnt funktionieren: Classic Editor aktivieren und nochmal testen. Im Notfall Backup einspielen und mit dem Update noch warten.

Meine Kunden mit Wartungsvertrag brauchen sich um all das nicht zu kümmern: ich entscheide für jede Website gesondert, ab wann ein Update gefahrlos möglich ist. Daher kann es durchaus sein, dass in den nächsten Wochen das WordPress-Kernupdate NICHT erledigt wird, weil die auf der jeweiligen Website verwendeten Plugins oder Themes noch dagegen sprechen.

Bei Fragen schreibt mir, hinterlasst einen Kommentar  oder ruft mich an! :-)

Aber der Reihe nach: Bisher war für die Aktualisierungen der Benutzername und ein API-Key erforderlich, also sowas wie ein „Passwort“ zur Programmierschnittstelle von Envato. Man konnte im Benutzerkonto unter „Settings -> API-Keys“ einen solchen Zugriffscode generieren (einfach eine sehr lange Zeichenfolge) und diesen gemeinsam mit dem Benutzernamen in den Theme-Einstellungen hinterlegen. Diese sogenannten „Legacy API Keys“ funktionieren jedoch für Theme-Updates künftig nicht mehr.

Envato hat nun auf sogenannte API-Token umgestellt – das Grundprinzip bleibt gleich: man erstellt das Token online, kopiert es und trägt es in den Theme-Einstellungen ein, damit sich WordPress allfällige Updates von den Envato-Servern holen darf. Der Vorteil bei den neuen API-Token: man braucht den Envato-Benutzernamen nicht mehr eintragen und man kann gezielt festlegen, welche Zugriffsberechtigungen das Token haben soll.

Das Enfold-Update von 4.4 auf 4.5 funktioniert also folgendermaßen:

• den alten Enfold-Ordner /wp-content/themes/enfold/ umbenennen z.b. auf /wp-content/themes/enfold_alt/
• aktuelle Version von Enfold von Themeforest runterladen, entpacken und den Ordner /enfold per FTP auf den Server kopieren
• Funktionstest – wenn alles funktioniert, kann man den Ordner /wp-content/themes/enfold_alt/ löschen

Damit künftige Updates wieder aus dem Admin-Bereich durchgeführt werden können, muss man nun noch unter https://build.envato.com/create-token/ ein neues Token generieren. Zuerst mit Envato-Benutzername und -Passwort einloggen (= deine Zugangsdaten von Themeforest!).

• Token Name: hier den Namen der Website eintragen, für die das Token verwendet werden soll
• Permissions needed: welche Berechtigungen soll das Token haben? Für Theme-Updates müssen folgende Berechtigungen angekreuzt werden:
  • View and search Envato sites
  • View the user’s Envato Account username
  • View the user’s email address
  • Download the user’s purchased items
  • Verify purchases of the user’s items
  • List purchases the user has made
• Ebenfalls ist anzukreuzen, dass Du die Geschäftsbedingungen akzeptierst: I have read, understood and agree to the Terms And Conditions
• Nun auf „Create Token“ klicken – wenn alles funktioniert hat, wird das API-Token angezeigt. Achtung: das Token wird nicht gespeichert, man muss es JETZT in diesem Fenster markieren und kopieren (STRG-C)! Danach kann man anhaken, dass man den Key gespeichert („I confirm that I have copied this key and stored it safely…“) hat und mit Klick auf „Woohoo! Got it.“ das Anzeigefenster wieder schließen.
• Das API-Token muss nun noch in den Enfold-Theme-Einstellungen eingetragen werden: dazu in den Admin-Bereich deiner Website wechseln, und in den Theme-Optionen zum Punkt „Theme Update“ wechseln.  Ins Eingabefeld „Enter a valid Envato private token“ das soeben kopierte Token einfügen (STRG-V) und auf den Button „Check the private token“ klicken.
• Wenn alles geklappt hat, zeigt Enfold eine entsprechende Meldung an: „We checked the token on 2018/xx/xx xx:xx and we were able to connect to Envato and could access the following information: Your purchases, Your username: xxx, Your E-Mail: xxx@xxx.at“

Zukünftig sollten Theme-Updates wieder im Admin-Bereich unter „Aktualisierungen“ durchführbar sein. Ganz einfach, wenn mans weiß.

Bereits erstellte Token kann man unter https://build.envato.com/my-apps/ auflisten, die Berechtigungen und den Namen bearbeiten und ggf. löschen – man muss sich also nirgends anders eine Liste anlegen oder mitschreiben. Das Token selbst wird allerdings nirgends gespeichert, es kann also auch kein zweites Mal abgerufen werden (deshalb sagte ich vorhin: JETZT markieren & kopieren)! Wenn mans also neu eintragen muss – einfach das betreffende Token im Envato-Konto löschen und ein neues anlegen.

Fragen? Ab in die Kommentare damit!

Des Rätsels Lösung: der Kunde bereitet die Bilder in Photoshop vor, indem er das vorige Bild nimmt, den neuen Inhalt reinkopiert und das Resultat als JPG ohne Ebenen speichert. Photoshop schreibt dabei jedesmal in die Metadaten unter der Bezeichnung photoshop:DocumentAncestors je eine Zeile pro ursprünglicher Quelldatei rein, mit einer mindestens 32-stelligen ID. Wenn man das oft genug macht (und der Kunde betreibt ein Nachrichtenportal, wo viele Bilder so generiert werden), so hat man dann halt in einer Datei 27.000 Zeilen Metadaten drin. Die Metadaten als Textdatei weggespeichert hatten alleine 1.8 MB – daher kam also der rätselhafte Überhang der Größe.

Wie kann man prüfen, ob eine JPG-Datei diese Daten eingebettet hat?

Datei in Photoshop öffnen und unter „Datei -> Dateinformationen -> RAW-Daten“ oben im Suchfeld „ancestors“ eingeben.  Unterhalb dieser Zeile finden sich dann etliche Zeilen, die mit <rdf:li> beginnen – jede davon ist ein Eintrag. In meinem Screenshot konnte man so 27.000 Zeilen(!) weit runterscrollen. Eine weitere Möglichkeit ist mit Adobe Bridge eine komplette Sammlung durchsuchen: „Bearbeiten -> Suchen -> Kriterien: alle Metadaten -> enthält“ und photoshop:DocumentAncestors eingeben.

Wie wird man die Metadaten photoshop:DocumentAncestors wieder los?

Es gibt mehrere Möglichkeiten, diese Metadaten wieder loszuwerden. Leider bietet Photoshop meines Wissens nach keine eigene Einstellungsmöglichkeit, um das Mitprotokollieren abzuschalten. Aber es gibt dennoch Abhilfe:

Lösung 1: Metadaten in einzelner Datei mit Photoshop Script entfernen

Mit diesem Script kann man die Daten aus einer einzelnen Datei entfernen. Zeilen kopieren, in einen Texteditor kopieren und mit der Dateiendung .jsx speichern (oder das fertige Script hier herunterladen). Die Bilddatei in Photoshop öffnen, unter „Datei -> Skripten -> Durchsuchen“ das gespeicherte Script aufrufen. Danach Bilddatei speichern.

function deleteDocumentAncestorsMetadata() {
whatApp = String(app.name);//String version of the app name
if(whatApp.search("Photoshop") > 0)  { //Check for photoshop specifically, or this will cause errors
//Function Scrubs Document Ancestors from Files
if(!documents.length) {
alert("There are no open documents. Please open a file to run this script.")
return;
}
if (ExternalObject.AdobeXMPScript == undefined) ExternalObject.AdobeXMPScript = new ExternalObject("lib:AdobeXMPScript");
var xmp = new XMPMeta( activeDocument.xmpMetadata.rawData);
// Begone foul Document Ancestors!
xmp.deleteProperty(XMPConst.NS_PHOTOSHOP, "DocumentAncestors");
app.activeDocument.xmpMetadata.rawData = xmp.serialize();
}
}
//Now run the function to remove the document ancestors
deleteDocumentAncestorsMetadata();

Lösung 2: Metadaten automatisch beim Öffnen, Schließen oder Exportieren von Dateien entfernen

Das Script lässt sich auch automatisiert aufrufen, dann werden die Metadaten bei jedem Öffnen, Speichern und Exportieren einer Bilddatei entfernt. Einfach das Script per Scriptereignis-Manager (zu finden unter „Datei -> Scripts -> Scriptereignis-Manager“ ans Öffnen, Speichern und Exportieren von Dateien binden (siehe Screenshot)

Lösung 3: mit exiftool die Metadaten automatisiert aus allen Bildern in einem Ordner entfernen

Mit dem kostenlosen Kommandozeilenwerkzeug exiftool (gibts für Linux, Mac und Windows) kann man die Daten automatisiert aus allen Bildern in einem Ordner entfernen und vorher ein Backup der Datei anlegen:

exiftool -r -XMP-photoshop:DocumentAncestors= '/mac/pfad/zum/ordner'

Alternativ ohne Backup (für Mutige):

exiftool -r -overwrite_original -XMP-photoshop:DocumentAncestors= '/mac/pfad/zum/ordner'

In Windows statt einfacher Anführungszeichen doppelte “ verwenden und den vollständigen Pfad zur Datei oder zum Ordner eintragen (z.B. „C:\Users\XXX\Pictures“). Bei dieser Methode kam es bei mir allerdings bei den vom Server berechneten Vorschaubildern zu Fehlermeldungen und diese wurden nicht verkleinert.

Lösung 4: mit Photoshop-Script aus allen Dateien eines Ordners entfernen (nicht an PNG-Dateien anwenden!)

Dieses Script entfernt aus allen JPG,TIF oder PSD eines Ordners die Metadaten photoshop:DocumentAncestors, ohne die Dateien in Photoshop öffnen zu müssen (auf eigene Gefahr verwenden, nicht getestet!)

// https://forums.adobe.com/message/9671488#9671488
#target photoshop;
var inputFolder= Folder.selectDialog ("Please select folder to process");
if(inputFolder != null){
var fileList  = inputFolder.getFiles(/\.(jpg|tif|psd)$/i);
for(var a in fileList){delFileAncestorsMeta(fileList[a]);}
}
function delFileAncestorsMeta(selectedFile) {
if (ExternalObject.AdobeXMPScript == undefined) ExternalObject.AdobeXMPScript = new ExternalObject("lib:AdobeXMPScript");
var xmpFile = new XMPFile( selectedFile.fsName, XMPConst.FILE_UNKNOWN, XMPConst.OPEN_FOR_UPDATE | XMPConst.OPEN_USE_SMART_HANDLER );
var xmp = xmpFile.getXMP();
xmp.deleteProperty(XMPConst.NS_PHOTOSHOP, "DocumentAncestors");
if (xmpFile.canPutXMP(xmp)) {
xmpFile.putXMP(xmp);
xmpFile.closeFile(XMPConst.CLOSE_UPDATE_SAFELY);
}
};

Lösung 5: mit Script für Adobe Bridge einen eigenen Menübefehl fürs Entfernen der Metadaten einfügen

Mit diesem Script hat man einen neuen Menübefehl in Adobe Bridge zur Verfügung, um die Metadaten zu entfernen. Zeilen kopieren, in einen Texteditor kopieren und mit der Dateiendung .jsx speichern (oder das fertige Script hier herunterladen). Das Script in den Ordner für die Startup-Scripts von Bridge kopieren (am einfachsten zu finden über „Bearbeiten -> Voreinstellungen -> Startscripts -> EIgene Startscripts anzeigen“). Danach Bridge neu starten, nun gibts unter Werkzeuge den neuen Menübefehl „Clear DocumentAncestors in metadata“. Ein Bild auswählen, Menübefehl auswählen – fertig. Natürlich kann man auch mehrere Bilddateien auswählen, allerdings läuft das Script unsichtbar und man weiß nie recht, wann es fertig ist. Es funktioniert prinzipiell aber sehr gut und ist die von mir bevorzugte Methode.

// https://forums.adobe.com/thread/290238    
// https://forums.adobe.com/thread/1880847    
// https://forums.adobe.com/thread/2340460    
//#target bridge // let EntendScript know what app the script is for    
clearDocumentAncestors = {};// create an object    
clearDocumentAncestors.execute = function(){// create a method for that object    
 var sels = app.document.selections;// store the array of selected files    
  for (var i = 0; i < sels.length; i++){//loop though that array    
    var md = sels[i].synchronousMetadata;// get the metadata for the file    
     md.namespace = "http://ns.adobe.com/photoshop/1.0/";// set the namespace    
     md.DocumentAncestors = "";  
  }     
app.document.chooseMenuItem("Rotate90CW");  
app.document.chooseMenuItem("Rotate90CCW");  
};    
//refresh cache  
app.document.chooseMenuItem("PurgeCacheForSelected");   
// this script only works in bridge    
if (BridgeTalk.appName == "bridge"){    
  //creage the munuItem    
  var menu = MenuElement.create( "command", "Clear DocumentAncestors in metadata", "at the end of Tools");    
  menu.onSelect = clearDocumentAncestors.execute;    
};  

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.

Also Umstellung der URLs auf ein Format, das Google mehr mag.
Man kann bei WordPress unter „Einstellungen -> Permalinks“ die URL-Struktur ja recht einfach ändern: einfach statt /%year%/%monthnum%/%postname%/ nur mehr /%postname%/ eintragen. Leider laufen dadurch ALLE links von Google vorerst ins Leere, es geht also nicht ohne Nacharbeit. Netterweise hat Joost de Valk (der Autor des SEO-Plugins Yoast) dazu einen Artikel geschrieben: How to change your WordPress Permalink structure – und dort findet sich ein Tool namens Permalink Helper, mit dem man automatisiert die entsprechende Zeile für die .htaccess erzeugen lassen kann, die dafür sorgt, dass die „alten“ URLs mit Datum zuverlässig auf die „neuen“ URLSs umgeleitet werden. Diese Zeile kopiert man ganz an den Anfang der .htaccess, damit die Umleitung schon greift, bevor die WordPress-eigenen Umleitungen zu wirken beginnen.

Getestet – funktioniert. Danke, Joost :-)

(Und wer bei der Umstellung Hilfe braucht, der weiß, wen er fragen sollte ;-) )

Allerdings ist das Update aktuell nicht ganz unproblematisch: es wird in Foren und Diskussionsgruppen derzeit von vielerlei Detail-Problemen nach dem Update auf 4.5 berichtet.

Viele ältere Versionen von Plugins und Seitenvorlagen verwenden die Funktion get_currentuserinfo(), obwohl Entwicklern schon seit längerem empfohlen wurde, ihre Plugins und Themes auf die neuere Funktion  wp_get_current_user() umzustellen. Und nun in WordPress 4.5 ist die Funktion endgültig rausgeflogen. Wenn nun ein Plugin oder eine Seitenvorlage installiert ist, das die Funktion nutzt, so zeigt die Website im besten Fall Fehlermeldungen an, im schlimmsten Fall bleibt die Website funktionslos.

Daher mein Tipp: ausnahmsweise noch nicht updaten. Oder nur dann, wenn ein funktionsfähiges Backup der Website und der Datenbank existiert, das im Notfall zurückgespielt werden kann!

Ist meine Website betroffen? Steckt get_currentuserinfo() in einem der Themes oder Plugins?

Per FTP ein Backup der Website-Daten vom Server holen und mit grep (unter Windows z.b. mit AstroGrep) den Ordner /wp-content/ nach get_currentuserinfo durchsuchen. So lässt sich herausfinden, in welchem Plugin bzw. in welchem Theme möglicherweise eine böse Überraschung lauert.

Wenn man sich nicht drum kümmern kann oder will: ich erledige das Update gerne!

Allerdings werde ich damit noch einige Tage zuwarten, bis die Entwickler der populärsten Themes & Plugins ebenfalls ihre Anpassungen zum Update ins Netz gestellt haben :-)

Ein professionelles Update beinhaltet:

• Sicherung der bestehenden Website inkl. Datenbanksicherung
• Einspielen der aktuellen WordPress-Version 4.5
• Update oder Anpassen Ihrer bestehenden Seitenvorlage auf Änderungen im System
• Update aller WordPress-Zusatzprogramme (Plugins)
• umfassende Funktionsprüfung
• Zusammenfassung und Handlungsempfehlungen (z.B. Ersatz veralteter Plugins, nötige oder mögliche technische Verbesserungen, Ideen für Arbeit sparende Funktionen…)

Einfach bei mir melden – ich schau mir an, wie IHR Update bestmöglich und kostenschonend erledigt werden kann!

/* Erster Schritt: Der Auszug des Beitrags wird auf Übersichtsseiten angezeigt */
function egm_excerpt_protected( $excerpt ) {
if ( post_password_required() )
{
$post = get_post();
$excerpt=$post->post_excerpt;
}
return $excerpt;
}
add_filter( 'the_excerpt', 'egm_excerpt_protected' );

/* Zweiter Schritt: eingeloggte User kriegen den Inhalt auch ohne Passwort zu sehen */
function egm_protected_posts_for_loggedin_users( $content ) {	
if ( post_password_required() && is_single() && is_user_logged_in ()) {
	$post = get_post();
	$content = wpautop($post->post_content);
    return do_shortcode($content);
}
else return $content;
}
add_filter( 'the_content', 'egm_protected_posts_for_loggedin_users', 10 );

Nachdem ich bereits einige Jahre gebloggt hatte, begann die damals verwendete Blogsoftware Sunlog an ihre Grenzen zu stoßen. Eines der Hauptprobleme war, dass zu dieser Zeit Kommentarspam begann, ernsthaft zu einem Problem zu werden. Ich musste manuell 20, 30, manchmal 50 Kommentare pro Woche händisch löschen (aktuell sinds auf diesem Blog 400, die automatisch gefiltert werden – pro TAG!).  Weiters wurde die Datenbank immer fetter, das Blog wurde immer langsamer. Als schließlich der Entwickler von Sunlog die Weiterentwicklung endgültig einstellte, war ich auf der Suche nach einer Alternative. Die pragmatische Lösung war, alle damals verfügbaren Kandidaten (ich erinnere mich an WordPress, MovableType, Textpattern und Serendipity) auf meinem Server installiert und probiert, wo die bisherigen Sunlog-Einträge am elegantesten zu importieren wären. Dass es WordPress wurde, war aber letztlich eine Bauchentscheidung. Nach einigen Wochen Herumprobieren, bis ich die Template-Logik halbwegs begriffen hatte, habe ich am 22.2.2006 mein altes Weblog mit Sunlog vom Netz genommen und WordPress freigeschaltet.

Lange Zeit blieb allerdings das Weblog der einzige Bereich meiner Website, der mit WordPress betrieben wurde – die Kundenprojekte gingen halt immer vor. Im Laufe der Jahre lernte WordPress neue Dinge, für viele davon bin ich ziemlich dankbar. Etwa den Menü-Editor – es war am Anfang etwas umständlich, Menüs in den Seitenvorlagen zu definieren. Und bei mehreren Menüs wars überhaupt ziemlich mühsames Gefrickel. Auch die automatischen Updates des WordPress-Kerns haben anfangs nicht immer reibungslos funktioniert und führten zu weißen Websites – sonst wurde nix mehr angezeigt. Mittlerweile kann man sich ruhig trauen, diese Funktion eingeschaltet zu lassen, denn wenn es tatsächlich Sicherheitsupdates gibt, werden diese so automatisch installiert. Ich hatte seither nie mehr(!) Einbrüche in WordPress-Websites, die über Lecks im Kern stattgefunden haben! Dafür, dass manche Plugin-Entwickler Blödsinn verzapfen, kann WordPress nix ;-)

Mittlerweile sind es weit über 200 WordPress-Websites, an denen ich arbeiten durfte: als Komplettdienstleister, als Programmierer, als Webdesigner oder auch als Pannenhelfer nach Einbrüchen oder Server-Crash. Die besten Ideen, was man mit WordPress alles machen kann, kamen von meinen Kunden – herzlichen Dank dafür. Durch eure Anregungen und Ideen bin ich tief in die Eingeweide von WordPress abgetaucht, mittlerweile gibts kaum eine Herausforderung, die ich damit nicht lösen könnte (mit Ausnahmen – siehe FAQ).

Ich freue mich auf DEINE Anfrage: Frag mich, vielleicht gehts!