Nach mehrfach Caches löschen und Reparieren bekomme ich es manchmal für http hin, dass die Vorschaubilder (und Bilder im Player) angezeigt werden. Nutze ich aber https klappt es wieder nicht. Oft klappt es aber auch mit http nicht.
Vor meinem heutigen Update auf 2.4.5 hatte ich das Problem nicht. Ich weiß allerdings nicht, auf welcher Version ich zuvor war. Ich habe seit einigen Wochen nicht geupdated.
Erzeugt werden die Bilder in einem Template wie folgt:
{% set imgUrl = e.image({fallback: true}).url({width: 600}) %}
Wobei e eine Episode ist.
Unter Support habe ich Warnungen bezgl. curl und Zertifikaten bei meinen Bildern. Vielleicht hängt es auch damit zusammen.
Der Haken ist gar nicht drin. Aber interessant ist, dass die Warnung tatsächlich immer für genau die 4 betroffenen Bilder kommt. Also hat es vielleicht tatsächlich etwas damit zu tun. Andererseits sagt die Warnung wohl nur aus, dass Curl das Zertifikat nicht hat, um https zu verifizieren. Und wenn man die Meldung im Netz sucht, heißt es allgemein, man könne es ignorieren oder mit -k bzw. --insecure abschalten.
Also das Problem hat vermutlich nichts mit den anderen Problemen in diesem Thread zu tun. Vielleicht könnt ihr es verschieben. Es sieht nach einem TLS Problem mit Curl aus.
Ich habe curl 7.47.0 und meine Seite nutzt letsencrypt Zertifikate.
Die Fehlermeldung cURL error 60 erhalte ich auch auf der Konsole. Und es handelt sich nicht um eine Warnung, denn wenn sie auftritt wird kein Inhalt geladen.
Curl findet die certificate chain nicht auf dem Server. Lade ich mir das Let’s Encrypt Authority X3 (IdenTrust cross-signed) Zertifikat im pem Format und hänge es an /etc/ssl/certs/ca-certificates.crt an, dann klappt es mit curl in der Konsole.
Leider hat das aber keine Auswirkung auf PHP, Wordpress und das Podlove Plugin.
Ich habe folgenden Stellen ausprobiert - ohne Erfolg:
Zeile mit: ‘sslcertificates’ => ABSPATH . WPINC . ‘/certificates/ca-bundle.crt’ // i guess this is just a missing default in the current wp curl lib
Die Zeile sieht ein wenig seltsam aus wegen dem Kommentar. Ich habe sowohl die Zeile geändert nach /etc/ssl/certs/ca-certificates.crt (kein Erfolg), als auch das geladene Zertifikat eingefügt in die Datei, auf die die Zeile ursprünglich verweist, also wp-includes/certificates/ca-bundle.crt (kein Erfolg).
Ich weiß aber auch nicht, ob ich beim Suchen im PHP-Code die richtige Stelle angeschaut habe. Wird diese Funktion denn benutzt beim Laden von Bildern über Templates oder beim Vorschaubild im Webplayer (v2)?
2. php.ini
Ich habe in die php.ini folgende Sektion eingefügt:
Aber auch damit hatte ich nach einem php-fpm Neustart leider keinen Erfolg.
Ich frage mich wirklich, woher da jetzt plötzlich das Problem kommt. Seit Ende Dezember habe ich Letsencrypt im Einsatz und die Bilder waren bisher unter https ladbar. Das Betriebssystem war auch schon im Dezember Ubuntu 16.04 LTE so dass ich höchstens von geringen Änderungen bei cURL ausgehe.
@ericteubert Ich würde gerne das Problem weiter untersuchen bin mir aber nicht sicher, ob ich an der richtigen Stelle bin. In welcher Datei benutzt Podlove denn curl, um die Bilder für Templates und den Player zu laden? Ist das wie oben beschrieben schon die richtige Stelle?
Es funktioniert nun, wie in Schritt 1 oben beschrieben: Also wenn ich das Let’s Encrypt Authority X4 (IdenTrust cross-signed) pem in der Datei wp-includes/certificates/ca-bundle.crt einfüge. Evtl. hatte ich beim ersten Versuch nicht alle Caches geleert.
Vielleicht hat es etwas mit PHP 7 und php-curl zu tun. Jedenfalls sieht es so aus, als hätte die Option “Podlove > Expert Settings” Sektion “Files & Downloads” keinerlei Wirkung mehr bei mir. Es hat auch nichts gebracht das Setting CURLOPT_SSL_VERIFYPEER manuell auf ‘false’ zu setzen.
Hier nochmal meine Konfiguration.
Website ZYLONENSENDER – Der deutschsprachige Podcast über die Fernsehserie Battlestar Galactica
PHP Version 7.0.15-0ubuntu0.16.04.4
WordPress Version 4.7.2
WordPress Theme Advanced Twenty Seventeen Child v1.0
Publisher Version 2.4.5
Web Player Version no web player found
Twig Version 1.30.0
open_basedir ok
curl Version 7.47.0
iconv available
simplexml ok
max_execution_time 30
upload_max_filesize 2M
memory_limit 256M
disable_classes
disable_functions pcntl_alarm,pcntl_fork,pcntl_waitpid,pcntl_wait,pcntl_wifexited,pcntl_wifstopped,pcntl_wifsignaled,pcntl_wifcontinued,pcntl_wexitstatus,pcntl_wtermsig,pcntl_wstopsig,pcntl_signal,pcntl_signal_dispatch,pcntl_get_last_error,pcntl_strerror,pcntl_sigprocmask,pcntl_sigwaitinfo,pcntl_sigtimedwait,pcntl_exec,pcntl_getpriority,pcntl_setpriority,
permalinks ok (/%postname%/)
podlove_permalinks ok
podcast_settings ok
web_player ok
podlove_cache on
assets
Ggf. muss ich zumindest auch CURLOPT_SSL_VERIFYSTATUS setzen?
Aber die bessere Lösung ist auf jeden Fall, jeweils das Serversetup zu fixen anstatt SSL-Sicherheitsfeatures zu deaktivieren.
Noch zu deiner Lösung: Du hast wp-includes/certificates/ca-bundle.crt editiert, was aber beim nächsten WordPress Update überschrieben wird. Du solltest das pem besser in der Systemdatei einfügen, die in der php.ini unter curl.cainfo hinterlegt ist.
Ich habe nachträglich gelernt, dass mein Ansatz obwohl er funktioniert, der falsche ist. Er löst nicht die Ursache des Problems, sondern bekämpft nur ein Symptom.
Die Ursache ist, dass SSL am Server falsch eingerichtet war. Für Let’s Encrypt genügt es nicht, am Webserver Zertifikat und Passwort zu setzen. Das schon erwähnte Let’s Encrypt Authority X4 (IdenTrust cross-signed) pem muss als Certificate chain hinterlegt werden.
Im Apache httpd gibts dafür ein extra Setting. Im ngingx jedoch nicht. Die Konfiguration erfolgt dort so, dass das Zertifikat zusammen mit dem Let’s Encrypt Authority X4 (IdenTrust cross-signed) pem von oben in eine Datei gespeichert wird. Diese Datei wird dem nginx dann als Zertifikatsdatei angegeben.
Ob man es richtig gemacht hat, kann man z.B. mit dem SSL Test von ssllabs.com testen. Ist alles korrekt, so erhält man Grade A+. Ansonsten nur Grade B.
Anschließend konnte ich das Intermediate Certificate das ich wie in meinem vorherigen Post beschrieben in wp-includes/certificates/ca-bundle.crt eingefügt hatte, wieder entfernen.
oh man, bin am Verzweifeln. auch nach dem Update von 2.4.1 auf 2.5 sind die Bilder weg. Die neuen Links hinter den Bildern zeigen auf nicht existente Verzeichnisse “http://moto-funk.de/podlove/image/…”. Es gibt kein Unterverzeichnis “podlove” … Hat wer eine Idee?
jap. leider hat es nichts gebracht. “Clear Caches” und “Attempt Repair”.
Wenn ich aber von Hand dieses “…/podlove/image/…” auf dem FTP Server nachbaue, wird auch das Bild, welches ich da hinterlege, angezeigt.
So habe nun wirklich alles erdenkliche probiert ohne jeglichen Erfolg!
Habe das Bild umbenannt rauf und runter gespielt…den Podlove Publisher gelöscht und neu installiert…den Webplayer 2 und 3 (Beta) durchgetauscht…das Theme geändert…und so weiter und so fort…alles hat nichts gebracht! Über dem Subscribe Button erscheint das Bild übrigens auch nicht automatisch, habe es manuell über die Text Funktion eingefügt…ich weiß nicht mehr weiter und setze mal auf euch
Die Symptome sind die gleichen wie ich weiter oben im gleichen Thread beschrieben habe:
Bilder im Player oder in Podlove Templates werden nicht angezeigt.
Der Link wie auch bei dir beschrieben zu den Bildern ist broken.
Problem lag bei mir daran, dass ich https verwendet habe und das Systemprogramm curl das von Podlove verwendet wird mein Zertifikat nicht akzeptiert hatte. Daher meldete curl einen Fehler und erzeugte das Bild nicht.
Wenn ich mir deinen HTML-Code ansehe hast du einen Mix aus http und https in deiner Seite. Und dein Link oben ist auch https. Daher könnte es sein, dass du das gleiche Problem wie ich hast, dass es also etwas mit https und curl zu tun hat.
Hast du denn unter Podlove → Support unten irgendwelche Warnungen oder Errors? Wenn da keine sind, sind wohl nur die Symptome gleich.