WordPress Bilder Upload schlägt immer wieder fehl – Die Verarbeitung des Bildes ist fehlgeschlagen

Wenn du seit dem Upgrade auf WordPress 6.2 beim Upload mehrerer Bilder diesen Fehler siehst:

“Die Verarbeitung des Bildes ist fehlgeschlagen. Der Server ist möglicherweise ausgelastet oder hat nicht genügend Ressourcen zur Verfügung. Eventuell hilft es, wenn du ein kleineres Bild hochlädst. Die vorgeschlagene Maximalgröße ist 2500 Pixel.”

dann kann das Problem realtiv einfach gelöst werden. In der Regel liegt es daran, dass php eine zu kurze maximale Laufzeit eingestellt bekommen hat. Du kannst den Wert für “max_execution_time” einfach höher setzen (ich habe mal 300 genommen), und damit erledigt sich das Problem.

Das kannst du entweder direkt über die php.ini Datei machen, oder aber (beim Einsatz von Apache2 als Webserver) per htaccess, evtl sogar direkt in der wp-config.php. Der maximale Wert wird allerdings von deinem Hoster festgelegt. Evtl musst du also mit dem Support Kontakt aufnehmen.

Falls du das offizielle WordPress Docker Image verwendest, dann geht es relativ einfach:

Lege eine datei wordpress.ini mit den Anpassungen an, die du in der php.ini gerne machen möchtest:

file_uploads = On
memory_limit = 256M
upload_max_filesize = 64M
post_max_size = 64M
max_execution_time = 300
max_input_time = 1000

Das mal als Beispiel.

Beim Docker run command mountest du diese Datei dann einfach in den Pfad “/usr/local/etc/php/conf.d/” innerhalb des Containers, also z.B. so:

docker run -d -p 8080:80 \
-v ./wordpress.ini:/usr/local/etc/php/conf.d/wordpress.ini \
-e WORDPRESS_DB_HOST="db:3306" \
-e WORDPRESS_DB_PASSWORD="P@ssw0rd2" \
wordpress

Diese direktiven in der ini Datei überschreiben dann die Default-Werte, die in der php.ini gesetzt wurden.

MacOS Update Probleme auf Monterey mit APFS

Zu meiner Schande muss ich gestehen, dass mein privates Macbook irgendwann auf MacOS Mojave hängen geblieben ist. Ich hatte vor ein paar Monaten mal ein Upgrade auf Big Sur probiert, allerdings war der Rechner danach unbrauchbar, weil er nicht mehr gebootet hat. Nach einem ca. 8h oder so andauernden Recovery mittels Timemachine war er wieder einsatzbereit, aber mir war die Lust auf Updates vergangen.

Dieses Problem wollte ich nun endgültig mit dem Umstieg auf MacOS Monterey angehen und lösen. Also habe ich den Installer runtergeladen und wollte die Installation starten – als ich direkt die Fehlermeldung bekam, dass für die Installation ein Datenträger mit APFS notwending ist.
APFS ist ein alternatives Dateisystem, welches von Apple mit MacOS High Sierra verteilt wurde. Eigentlich sollte in Mojave der Datenträger automatisch dahin konvertiert werden (was sogar on-the-fly) gehen sollte, aber irgendwie ist das bei mir nicht passiert. Warum auch immer.

Um die Conversion nachträglich machen zu können, muss man den Mac im Recovery Modus starten, dann das Disk-Utility/Festplattendienstprogramm starten. Dort wirft man die Mac Festplatte aus, markiert sie und klickt dann auf Edit/Bearbeiten und “convert to apfs”. Anschließend wird das System umgestellt. Blöd nur, dass genau das den Fehler verursacht, dass man anschließend nicht mehr booten kann (Stichwort: “Running bless to place boot files failed”). Man könnte MacOS nach der Konvertierung nochmal drüber installieren, aber da Mojave nicht mehr installiert werden kann ging auch das nicht mehr für mich 😂

Die Lösung habe ich dann hier gefunden: https://www.tecklyfe.com/boot-failures-after-converting-macos-ssd-to-apfs/

Ich vermute mal dass das Problem irgendwie mit UEFI oder so zusammen hängt, jedenfalls muss man ein Pre-Boot Environment von Hand anlegen, damit der Bootvorgang wieder reibungslos funktioniert. Und das geht so:

  • Den Mac mit gedrückter Command+R Tastenkombi starten
  • Utilities > Terminal
  • diskutil apfs list ausführen und schauen, welche Nummer und welche UUID die Festplatte eures Macs hat – sie sollte “Macintosh HD” oder so heißen
  • Anschließend (natürlich ohne die eckige Klammer, als z.B. disk2:
    diskutil apfs addVolume disk[Festplatten-NUMMER] apfs Preboot -role B
  • Anschließend dieses Verzeichnis anlegen, wobei die xxx… durch die UUID, die ihr euch in Punkt 3 angesehen habt hier eintragt:
    mkdir -p /Volumes/Preboot/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/System/Library/CoreServices
  • cp -RP /Volumes/MACINTOSH HD/System/Library/CoreServices /Volumes/Preboot/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/System/Library/CoreServices
  • Mittels folgendem Commands repariert ihr nun den Pre-Boot-Eintrag. Ersetz hier das disk2s1, falls deine Partition eine andere Nummer hat:
    diskutil apfs updatepreboot disk2s1
  • Abschließend kannst du nun mit Bless den Boot-Eintrag setzen lassen:
    bless --folder /Volumes/MACINTOSH HD/System/Library/CoreServices --bootefi --verbose
  • Neu starten

Cyberpunk 2077 Glitch: Takemura ruft an

Nach meinem anfänglichen Reinfall mit der Xbox Version von Cyberpunk 2077 und dem anschließenden Umstieg auf einen richtigen Gaming PC zocke ich das Spiel nun sehr gerne. Bisher wurde ich von heftigen Bugs verschont, aber nun hat es mich getroffen.

Und zwar geht es um die Mission „Down the Road“, bei der wir auf einen Anruf von Takemura warten. Sein Anruf kam bei mir direkt nach einer anderen Mission, allerdings wurde er automatisch angenommen und dann passierte: nichts. Takemura starte mich die ganze Zeit an (siehe Screenshot), aber sagte keinen Ton. Für das Spiel war die ganze Zeit das Telefonat aktiv, sodass man nicht speichern konnte, das Handy konnte nicht verwendet werden und so einige andere dinge waren gesperrt. Sprich, das Spiel wurde nahezu unspielbar.

 

 

Nach einer erweiterten Recherche im Netz gab es Hinweise, dass man ein Savegame möglichst weit vor diesem Event laden sollte und dann eben nochmal spielen sollte, in der Hoffnung, dass der Bug nicht nochmal auftritt. Aber mehrere Stunden Spiel zu wiederholen um dann trotzdem das Risiko zu haben, dass der Fehler erneut passiert? Da hatte ich keine Lust drauf 😂

Irgendwann habe ich dann einen workaround gefunden: man muss mehrere Nebenmissionen durchführen, bis scheinbar irgendwann eine dabei ist, bei der auch jemand anruft. So richtig hab ich es auch nicht herausgefunden. Es bietet sich wohl an in der Wüste im östlichen Teil der Karte daran zu arbeiten.

Jedenfalls habe ich dort mehrere Nebenmissionen gemacht und irgendwann auch Panam besucht und siehe da – genau als ich sie ansprach verschwand Takemura auf einmal und das Spiel war wieder bedienbar. Das ist der ungefähre Weg aus diesem Problem, so ähnlich hatte es der Typ auch beschrieben, bei dem ich diese Lösung gefunden habe. Ich hoffe es hilft weiteren Leuten 🙂

Und bevor jemand mit Patches usw kommt: das Ganze passierte bei mir auf Patch 1.1, also der aktuellsten Version 🤷🏻‍♂️

Nach Mac OS Catalina Update – Mail App Suchfunktion ist kaputt

Das Update auf Mac OS Catalina lief bei mir eigentlich ohne Probleme durch, aber heute fiel mir dann auf, dass die Suchfunktion in der Mail App sich sehr komisch verhielt bzw. einfach kaputt war.

Mir war natürlich gleich klar, dass der Suchindex wahrscheinlich einen Treffer hatte, da ich die App ja trotzdem normal bedienen und Mails senden/empfangen konnte.

Um das Problem zu beheben, musste ich also den Suchindex der Mail App zurücksetzen und neu aufbauen lassen. Dazu sind folgende Schritte nötig:

  1. Mail App beenden
  2. Im Finder den Ordner ~/Library/Mail/V7/MailData öffnen (mit CMD+SHIFT+G)
  3. Alle Dateien, die mit „Envelope Index“ beginnen löschen (oder in einen Backup-Ordner schieben)
  4. Mail App wieder starten. Es empfängt euch ein Screen, der mitteilt, dass Mail sich selbst reparieren muss. Anschließend werden die Mails neu indiziert, in dieser Zeit ist Mail nicht benutzbar.

Nginx Docker Reverse Proxy wirft 404 Fehler ab dem zweiten Request

Als großer Fan von “nackten Servern” auf denen nur Docker Container laufen, nutze ich Nginx als Reverse Proxy – im Speziellen das großartige Setup von jwilder/nginx-proxy in Kombinantion mit dem Let’s Encrypt Addon. Effektiv läuft das Teil passiv mit und schaut nur auf bestimmte Environment-Variablen anderer Docker Container. Sobald es diese sieht, wird automatisch ein Reverse Proxy in Nginx so konfiguriert, dass er diesen Dienst erreichbar macht und gleichzeitig wird noch ein Let’s Encrypt Cert für die entsprechende Domain besorgt und auf dem neuesten Stand gehalten.

Nun hatte ich in einem Setup mit sehr vielen gleichzeitig laufenden Diensten das Problem, dass einer der Dienste immer nur auf den ersten Request erfolgreich geantwortet hat, aber bei jedem weiteren Request nur noch einen 404 geworfen hat. Der Dienst selbst lief, Nginx hat auch keinen Fehler im Log geworfen und ich war etwas ratlos.

Nach ein paar grauen Haaren mehr und dem ein oder anderen versteckten Hinweis auf Google kam ich dann auf des Rätsels Lösung: durch ein fehlerhaftes Deployment lief kurzzeitig ein weiterer Container, der mittels der Environment Variable die gleiche URL für sich beanspruchte. Der Nginx Automatismus machte daraus automatisch einen Load Balancer. Nachdem das fehlerhafte Deployment weg war, wurde der Loadbalancer aber nicht mehr aufgelöst und somit war nur noch einer von beiden Einträgen aktiv. Warum der Nginx dann trotzdem immer wieder auf den nicht vorhandenen Host gehen wollte erschließt sich mir nicht so richtig, aber das war des Problems Lösung.

Also bin ich einfach per docker exec in den Nginx Container und habe die Datei /etc/nginx/conf.d/default editiert:


# server.name.com
upstream server.name.com {
# CONTAINER_NAME_1
server 123.45.0.67:1234;
# CONTAINER_NAME_2
server 123.45.0.78:1234;
}

Nachdem ich den Part von CONTAINER_NAME_2 gelöscht hatte, konnte ich mittels

nginx -s reload

die Config von Nginx on the fly neu laden und ab dem Moment lief der Service wieder wie gewohnt.

AWS Lambda@Edge liefert 503 Error und es gibt keine Logs

Jobbedingt musste ich mich kürzlich mit AWS Lambda@Edge Funktionen herumschlagen. Da die wenigesten wahrscheinlich wissen, was das ist:

Lamdba Funktionen gehören zum Bereich “serverless” – letztendlich bedeutet es nur, dass man nicht eigene Server oder Dienste (z.B. wordpress) hosted, sondern einzelne Funktionen. Beispiel: eine Bildskalierung. Sprich, man gibt dem Service eine URL mit und parameter, wie groß das Zielbild sein soll. Der Service holt sich das Bild von der URL, verkleinert/vergrößert es auf die Maße und gibt es dann zurück.

Lambda@Edge ist dann die Hipster Variante davon, diese Funktionen kann man nämlich vor sein AWS Cloudfront CDN hängen. Sprich, bei jedem Request, der beim CDN ankommt, wird vorher die entsprechende Lambda Methode ausgeführt. Mit dieser kann man den Request verändern, Authentifizierung abhandeln, oder auch z.B. A/B Tests fahren. (weitere Beispiele: docs.aws.amazon.com)

Im Gegensatz zum “normalen” Lambda gibt es jedoch ein paar Einschränkungen, die hier ganz gut erklärt werden: Lambda at the Edge

Zusätzlich zu den unzähligen Unterseiten, hier mal meine aktuellen Erkenntnisse zum Thema Lambda@Edge:

  • AWS Lambda@Edge funkionen MÜSSEN in “North Virginia (us-east-1)” abgelegt werden!
  • Der komplette Code für die Lambda Funktion darf nicht größer als 1MB sein, inkl. Libraries
  • du MUSST nodejs8.10 oder nodejs10.x verwenden
  • die Funktion darf nicht mehr als 128mb RAM verwenden
  • die Funktion darf nicht länger als 5s laufen
  • Die LOGS der Aufrufe über CLOUDFRONT werden nicht in Cloudwatch “North Virginia (us-east-1)” abgelegt, sondern in der Area, WO SIE HERKOMMEN. In meinem Fall also “EU (Frankfurt)”. Wenn man die Funktion selbst per Testcall in der Lambda Oberfläche aufruft, DANN landen die Logs in “North Virginia (us-east-1)”. Es hat mich mehrere Tage gekostet, darauf zu kommen…
  • Cookies, die man an die Funktion überträgt, werden im Cookie Array (event.Records[0].cf.request.headers.cookie) nicht als “key: value” übergeben, sondern als “cookie: key=value”

Etwas fies ist, dass die Fehlercodes sich überlappen. In meinem Fall bekam ich immer wieder einen 503 Fehler angezeigt, sobald ich meine Funktion über Cloudfront aufrief. Da ich zu diesem Zeitpunkt den “anderen Ort” der Logs nicht kannte, musste ich raten. Die 503 Fehlerseite gab aber ungünstigerweise noch den Hinweis, dass die Funktion wahrscheinlich nicht genügend Permissions oder Ressourcen hat – was mich die ganze Zeit auf die falsche Fährte lockte. Denn eigentlich warf meine Funktion die ganze Zeit selbst einen 500er Fehler, weil das Cookie Parsing nicht richtig klappte. Diese Unterscheidung sieht man aber nicht wirklich von aussen – sprich, eine fehlerhafte Konfiguration von Lambda@Edge Funktionen und Fehler im Script selbst sehen von aussen exakt gleich aus.

Nachdem ich die Logs dann endlich gefunden hatte, war das Problem schnell behoben (siehe Punkt “cookies”) in der oberen Liste, funktionierte meine Funktion nun wie gewünscht.

Chrome scheint Videosoftware unter MacOS auszubremsen

Creative Director Felipe Baez von der Agentur Cre8ive Beast hat bemerkt, dass sich Final Cut Pro deutlich langsamer wird, und teilweise sogar abstürzen kann. Grund dafür ist das “Video-Toolbox” Framework, welches von MacOS bereitgestellt wird. Chrome nutzt dieses Framework und klaut somit die Ressourcen anderen Programmen, wie eben Final Cut Pro. Das gleiche Problem tritt auch z.B. bei Handbrake auf, und somit wahrscheinlich auch bei weiteren Video-Editoren.

Aktuell ist der Ratschlag: sobald man irgendeine Art von Videoschnitt macht, sollte Chrome nicht laufen.

Bei dieser Gelegenheit rate ich wirklich JEDEM dazu, sich den aktuellen Firefox nochmal anzusehen. War er in den letzten Jahren eher langsam und behäbig geworden, ist er nun seit ca. 0,5-1 Jahr wieder in seiner alten Form zurück. Er ist super schnell (teilweise sogar schneller als Chrome), hat die gleichen Funktionen, und ganz wichtig: nimmt Privatsphäre und Datenschutz höchstwahrscheinlich deutlich ernster als andere Browserhersteller. Ich bin schon vor einer ganzen Weile umgestiegen (auf meinem Mac und auch auf iPhone/iPad) und bereue es in keinster Weise!

via Golem

Firefox deaktiviert addons

Am Wochenende ist Mozilla leider ein sehr blöder Fehler unterlaufen: das Zertifikat, welches die Echtheit von Extensions sicherstellt, ist abgelaufen 🙁

Die Folge: sämtliche Extensions/Erweiterungen sind komplett deaktiviert und lassen sich weder aktivieren noch neu installieren.

Die Lösung ist, zumindest aktuell, relativ einfach:

Einstellungen öffnen, dann den Punkt Datenschutz & Sicherheit wählen und dort den Punkt aktivieren, dass ihr an so genannten “Studien” teilnehmen wollt. Darüber wird nämlich gerade der Hotfix verteilt:

Danach habe ich den Browser einmal neu gestartet, und nach ein paar Minuten erschienen meine Addons wieder.

Da ich noch nicht so recht weiß, was ich von diesem Setting halten soll, mit dem Mozilla eigentlich beliebig meinen Browser steuern darf, werde ich es wohl in den nächsten Tagen, sobald der “offizielle” Fix da ist, wieder deaktivieren.

WordPress zeigt nur die Überschriften, aber nicht den Artikel Inhalt / Content an

Bei einem Umzug von WordPress hatte ich auf einmal das Phänomen, dass die Seite an sich wunderbar funktionierte, jedoch nur die Blog Post Überschriften und nicht den Content anzeigte.

Komischerweise war der Content beim Bearbeiten des Artikels vorhanden, also tippte ich erst auf das Template. Da ich jedoch ein WordPress Default Template in Verwendung hatte, konnte das schnell ausgeschlossen werden.

Die Lösung brachte dann der allgemeine WordPress Universal-Tip: Alle Plugins deaktivieren und dann einzeln wieder anschalten. Und siehe da, das (leider) komplett veraltete “wp-slimbox-reloaded” hatte den Fehler verursacht. Irgendwie hat es den Render-Prozess des Artikel Contents zerschossen. Sobald ich das Plugin deaktiviert hatte, lief die Seite wieder wie gewohnt 🙂

[Quicktip] Walkie Talkie App ist nicht auf der Apple Watch vorhanden

Irgendwie ist die großartige Walkie Talkie App auf der Apple Watch total an mir vorbei gegangen. Als ich sie nun doch entdeckte, wollte ich sie natürlich gleich ausprobieren. Mit einem Freund klappte es auf Anhieb, der andere sagte mir, dass die App nicht auf seiner Uhr zu finden ist bzw. die Walkie Talkie App auf der Apple Watch fehlt.

Nachdem wir diverse Lösungvorschläge durchprobiert hatten, war die Lösung dann doch relativ leicht. Folgende Vorraussetzungen müssen erfüllt sein, damit die App auf der Apple Watch erscheint und nutzbar ist:

  • Facetime muss auf dem iPhone eingrichtet und nutzbar sein
  • die Apple Watch muss das neueste WatchOS installiert haben
  • ihr braucht mindestens eine Apple Watch 2 oder aber die zweite Revision der ersten Apple Watch, also die mit der neuen CPU
  • die Facetime App muss auf dem iPhone installiert sein

Der letzte Punkt war in unserem Fall entscheidend. Da man Facetime neben der offiziellen App auch einfach über die Telefon-App bzw. das Telefonbuch verwenden kann, hatte sich die Facetime App wegen Nicht-Nutzung automatisch de-installiert. Nachdem der Kollege die App durch einfaches drauf tippen wieder neu installiert hatte, erschien die Walkie Talkie App auch auf der Uhr.