Wie fehlerhaften Podcasting-Feed reparieren

[garvinhicking]

Hi!

Das Logfile enthält leider arg viele Einträge. Es wäre wichtig dass Du diese auf das wesentliche reduzierst, also das Logfile löschst bevor Du den Artikel erstellst, dann sofort die Aktionen durchführen, und dann sofort das Logfile rüberkopieren. Sonst kann ich es nicht wirklich analysieren und die nächsten Schritte einleiten.

Bitte sage mir dann auch mal den konkreten Blogeintrag und die konkrete Datei bei der der MIME-Typ nicht erscheint damit ich einen Anhaltspunkt bei der Suche habe.

UPDATE: Was mir merkwürdig erscheint; die DAtei z.b. "/home/datenkanal/website/uploads/podcast/DK009-100-Tage-TLfD.mp3" wird wohl lokal nicht gefunden. Stimmt an diesem Pfad etwas nicht? Wie lautet der korrekte Pfad? Hat Dein PHP evtl ein open_basedir oder so gesetzt und der Pfad ist darin nicht enthalten, evtl weil Du symlinks irgendwo nutzt?

Viele Grüße,
Garvin

[deka]

Schau mal bitte in das Uploadverzeichnis. Ich habe nochmals als Admin und als Redakteur Beiträge angelegt. Dabei bin ich so vorgegangen:

• Einloggen und neuen Beitrag wählen.

• debug aktivieren.

• Beitrag mit einem Link anlegen und Kommentare etc. deaktivieren.

• Speichern

• Debugging aus.

• Jeweils RSS, ATOM und Logdateien runterladen.

In der index.rss1 sieht man deutlich den Unterschied beim enclosure. Auch ist die als Redakteur erstellte fast zehnmal so groß. Ich habe beide Beiträge wieder gelöscht. Dennoch sollte aus den RSS-Dateien alles hervorgehen.

Die Dateien liegen lokal in /home/datenkanal/static/uploads/podcast und die S9Y-Installation liegt in /home/datenkanal/website/. Der Webserver läuft als Nutzer $foo und die Verzeichnisse sind rwx für $foo.

Die Aufteilung hat etwas damit zu tun, dass hier zwei Apachen involviert sind. Der Frontend-Apache serviert die Dateien für die Außenwelt und je ein Backend-Apache kümmert sich um einzelne Webseiten. Dabei war die Idee, dass wir statische und dynamische Inhalte trennen. Die Dateien in static/ werden direkt vom Frontend-Apachen ausgeliefert. Das soll vermeiden, dass die erst durch PHP und Co. geschleift werden. S9Y uund anderes wird erst vom Backend-Apachen bearbeitet.

open_basedir ist nirgends gesetzt. Ich vermute aber, dass es Probleme mit der obigen Konstruktion geben könnte. Die Frage ist jedoch, warum geht es als Admin und als Redakteur nicht? Müsste ich dem Redakteur selektiv mehr Rechte geben?

[garvinhicking]

Hi!

Ich fürchte an dieser Stelle wird es zu kompliziert um das hier "fernzudebuggen", sorry. Rein praktisch dürfte es eigentlich keinen Unterschied zwischen der Erstellung als Admin und Redakteur geben, es sei denn Du hast in der Rechte-Konfiguration gewisse Plugins bei der Redakteurs-Gruppe ausgeschlossen; sonst operiert jedes event-plugin nämlich eigentlich unabhängig, es gibt im s9y kern funktional kaum unterschiede ob jemand admin oder redakteur ist, es werden nur einige Buttons und Aktionen ausgeblendet, aber der workflow bleibt eigentlich.

Falls Du auf einem anderen Server einer parallelinstallation aufsetzen kannst wo das ganze reproduzierbar ist, und zu dem ich SSH oder FTP Zugriff kriegne kann, würde ich gerne darin debuggen.

Viele Grüße,
Garvin

[deka]

OK, ich werde in den nächsten Tagen (kann auch erst nächste Woche werden) eine Parallelinstallation aufsetzen. Alles weitere dann vorerst per E-Mail.

[deka]

Die Seite ist kürzlich zu einem neuen Server umgezogen. Dort machte ich einige Änderungen und seitdem validiert der RSS2-Feed. RSS1 und ATOM enthalten noch Fehler. Die liegen meiner Meinung nach nicht an dem hier diskutieren. Bei der Umstellung der Seite fiel mir dann auch auf, wo der Fehler gelegen haben könnte. Garvin, mich würde deine Meinung interessieren.

Die alte Installation hatte das DocumentRoot in $FOO/s9y, wobei $FOO ein beliebiger absoluter Pfad ist. Die Audiodateien lagen im Ordner $FOO/static/uploads. Der Ordner wurde im Apachen auf die URL http://example.com/uploads gemappt. Das letztere Verzeichnis wird auch über S9Y (Mediendatenbank) vewaltet. Das Unterverzeichnis uploads/podcast war in der Mediendatenbank nicht registriert. Jetzt vermute ich, dass ein Redakteur nicht darauf zugreifen kann, auch wenn es, wie oben beschrieben, existiert. Der S9Y-Admin wiederum kann eventuell darauf zugreifen. Denn wenn das so wäre, würde das den beschriebenen Fehler erklären. Bei einem neuen Beitrag wertet S9Y wahrscheinlich die URL aus, sieht dass es in der Medien-DB liegt und versucht, an die Inhalte zu kommen. Der Admin kann das, der Redakteur nicht. Dementsprechend wird der Feed mit fehlenden Werten erzeugt.

Könnte die Erklärung in etwa hinhauen?

[garvinhicking]

Hi!

Ja, so etwas hatte ich als Fehler uach fast vermutet. Das Plugin versucht vom relativen HTTP-Pfad aus auf den absoluten zu schließen, ich vermute dass es dann hier Probleme in der Dateiauflösung kam und er so an die echte Datei nicht rankam, und daher auch keinen Mime-Typ erkennen konnte.

Das mit den Mediendatenbank-Zugriffsrechten sollte aber eigentlich über eine Funktion ausgewertet werden, die die Mediedatenbank-Zugriffsrechte garnicht ausliest - das würde mich also dann schon eher wundern. Aber evtl erinnere ich mich hier nur falsch, man müsste die involvierten Funktionen nochmal prüfen... Irgendetwas der Art muss es ja sein, sonst hättest du das Phänomen nicht gehabt.

Grüße,
Garvin