Beiträge von ntm_de

    Hallo Holger,

    in den php Datei auf die du im anderen Forum hingewiesen wurdest, wirst du zumindest keinen podPress Code finden.
    Die podPress Elemente werden über sogenannte Action Hooks in die Beiträge dynamisch eingefügt. Ich vermute, dass diese Social Media Buttons auch auf diese Weise eingefügt werden, wenn sie von einem Plugin erzeugt werden.

    Ist AnyButton das Plugin mit dem die Buttons eingefügt werden?
    Wenn die Buttons von AnyButton erzeugt werden und auch dann doppelt angezeigt werden, wenn nur AnyButton aktiviert ist, solltest du versuchen herauszufinden mit welchem Action Hook oder Filter Hook die Button eingefügt werden.
    In den PHP Dateien des Plugins sollte die Zeile add_action(... bzw. add_filter(... zu finden sein. Beispielsweise könnte es add_filter('the_content', '...') in diesem Fall wäre der Hook the_content - ein Hook der benutzt wird. um Elemente zum dargestellten Artikelinhalt hinzuzufügen. In der Gegenpart in den Themedateien (index.php, single.php oder auch loop.php, post.php und page.php) heißt do_action('....') oder apply_filters('the_content').

    do_action und apply_filters können durchaus mehrfach in einer Datei auftauchen, auch mit dem selben Hooknamen. In letzterem Fall nur, wenn sie z.B. in verschiedenen Zweigen einer Bedingung stehen also z.B. if ( ... ) { ... apply_filters('the_content') ... } else { ... apply_filters('the_content') ... }.

    Viele Grüße
    Tim

    Hallo,

    bitte entschuldige die späte Reaktion. Ich schaue in diesem Forum nur selten vorbei. Allerdings verfolge ich alle Beiträge mit dem tag "podpress" in diesem Forum http://de.forums.wordpress.org/tags/podpress und antworte dort sehr gern auch auf Deutsch.

    Aber zum Problem:
    In welchem Blog hast du die Option iTunes:New-Feed-Url aktiviert?
    (Diese Option ist dazu gedacht, im alten Blog aktiviert zu werden, bevor es geschlossen und deinstalliert wird. Das neue Blog sollte zu diesem Zeitpunkt bereits aktiv sein und dem zu Folge auch der neue Feed.)

    In welchen Feed hast die Option aktiviert? Im Feed ?feed=podcast, also im Abschnitt podPress Feeds oder im normalen RSS Feed (am Anfang der Feed Einstellungen Seite)?

    Du schreibst, dass nach dem aktivieren der Option, der Feed nicht mehr valide war. Kannst du dich an die Fehlermeldung(en) erinnern? Oder kannst du sie reproduzieren und hier mal posten?

    Welche podPress Version nutzt du und mit welcher Version trat/tritt das Problem auf?

    Gruß,
    Tim

    Ich habe mir gerade den http://www.eintracht-podcast.de/category/podcast/feed Feed angeschaut. Die .m4a Dateien, wie z.B. Eintracht_Podcast_046.m4a oder Eintracht_Podcast_045.m4a lassen sich in der Tat gut auf dem Desktop Computer abspielen. Warum es auf dem iPhone nicht geht, weiß ich nicht.
    Momentan sind deine/eure Feeds leider etwas "kaputt". Das liegt an der podPress Variante die du/ihr gerade benutzt. ich habe leider in den Versionen 8.8.10.3-8.8.10.5 mind. 1 großen Fehler drin.
    Ich nehme an, dass du eine dieser Versionen verwendet. Oder ist es bereits podPress 8.8.10.6? Mit 8.8.10.6 sollten alle Feeds wieder valide sein.
    Aber ich denke, dass das aktuelle Problem mit den Feeds nichts mit dem eigentlich Problem zu tun hat. Andere habe scheinbar auch so ein Problem https://discussions.apple.com/thread/247922
    In einem der Beiträge steht "So product feedback Bug Report has been submitted.", was für mich so viel heißt, wie: jemand hat einen Fehlerbericht diesbezüglich bei Apple eingereicht. Es gibt auch noch andere Diskussionsstränge genau zu diesem Thema https://discussions.apple.com/message/11857233
    (allerdings auch ohne Lösung)

    ... wie auch immer, bitte upgrade zu podPress 8.8.10.6.

    Viele Grüße
    Tim

    Hallo Astrid,

    ich habe heute mal einen Blick in den Quellcode des Themes (Version 2.4.1) werfen können. Es scheint tatsächlich so zu sein, dass die Eingabefelder für die Kommentare nicht angezeigt werden, wenn man die Javascript und AJAX Effekt abstellt und es scheint wirklich nur damit zusammenzuhängen.

    In der Datei comments.php des Themes gibt es die Zeile:

    Code
    <div id="comment_form" class="index-comment" style="display: none">

    .
    Der Code

    Code
    style="display: none"

    versteckt die Eingabefelder beim Laden der Seite und die JS/AJAX Effekte machen sie wahrscheinlich bei Bedarf sichtbar. Allerdings scheint zu mindestens in der Version des Themes, dass ich gesehen habe, der Fall, dass diese Effekte deaktiviert sind, nicht berücksichtigt worden zu sein.

    Der vermutlich einfachste Weg die Eingabefelder sichtbar zu machen, ist genau diesen Style-Abschnitt (style="display: none") aus der Zeile zu löschen.
    Dann sind die Eingabefelder jedoch immer sichtbar.

    Eine etwas elegantere Methode wäre die JS/AJAX Effekte Option zu berücksichtigen und dabei auch die Zeilen über dieser Zeile einzubeziehen:
    alt:

    PHP
    <?php if($post->comment_status == 'open' && get_option('slf_ajax') == 1 && ($comment_count + $ping_count) != 0) { ?>
            <div class="index-comment"><textarea class="respondtext single">Write a comment..</textarea></div><?php 
        } ?>
        <div id="comment_form" class="index-comment" style="display: none">

    neu:

    PHP
    <?php 
        $slf_ajax = get_option('slf_ajax');
        if($post->comment_status == 'open' && $slf_ajax == 1 && ($comment_count + $ping_count) != 0) { ?>
            <div class="index-comment"><textarea class="respondtext single">Write a comment..</textarea></div><?php 
        }
        if ( 1 != $slf_ajax ) { ?>
        <div id="comment_form" class="index-comment">
        <?php } else { ?>
        <div id="comment_form" class="index-comment" style="display: none">
        <?php } ?>

    Es ist vielleicht eine gute Idee, vor dem Beginn der Änderungen in der comments.php Datei, von dieser eine Kopie zu machen.

    Viele Grüße
    Tim

    Hallo Astrid,

    manche Themes zeigen auf den Katergorieseiten nur einen Auszug des Beitrags an. Wenn kein Auszug eingegeben wurde, wird automatisch einer erstellt. In Auszügen werden standardmäßig keine Bilder angezeigt.
    Allerdings werden die podPress Elemente unter den Auszügen angezeigt. (Ich kann sie sehen, wenn ich z.B. die Kategorie Podcast auf der angegebenen Seite ansehe.)

    Es kann sein, dass die aktuelle Version des Themes http://smells-like-facebook.nazieb.com/513/smells-like-facebook-2-6/ die Kategorieseiten per AJAX.
    Aber ich denke nicht, dass das unbedingt mit den nicht erscheinenden Bildern zu tun hat. Wie gesagt es liegt wahrscheinlich daran, dass das Theme in den Kategorieansichten nur Auszüge anzeigt.

    Das Template für diese Seiten, dessen Datei z.B. archive.php oder vielleicht category.php heißen kann, enthält anstatt the_content() den Funktionsaufruf the_excerpt(). Im prinzip brauchst du nur die Zeile finden und the_excerpt() mit the_content() ersetzen.

    Viele Grüße
    Tim

    Ob Full+ funktioniert hängt davon ab, wie lange PHP Skripte auf dem Server deines Blog laufen dürfen. Eine Grenze kann hier z.B. die PHP Einstellung max_execution_time sein, die man als Nutzer oft nicht verändern kann und die oft nur eine Minute oder weniger ist.
    Full und Full+ unterscheiden sich nur in einem Punkt: Full+ versucht festzustellen, ob ein Download abgeschlossen wurde oder nicht. Dazu läuft während des Downloads ein Skript. Wenn der Download nun aber länger dauert, als das Skript laufen darf, bricht er ab (bzw. endet scheinbar normal) und die Datei ist unvollstängig (, was mit deinen Beobachtungen übereinstimmt.)
    Da dieses Verhalten im Grunde nicht neu ist, gibt es seit 8.8.6 einen Hinweis auf das Problem mit dem Zeitlimit in der Beschreibung der Methode Full+ und Full wird als Statistikmethode empfohlen.

    Viele Grüße
    Tim

    Pascal,

    vielen Dank für deine Angaben. Die helfen natürlich. Aber das Problem scheint wirklich kein allgemeines Problem zu sein, dass alle podPress Nutzer betrifft. Ich kann es in keinem meiner Blogs nachbilden.
    Daher wäre es richtig hilfreich, wenn du selbst 2 Test durchführen könntest.
    1. Bitte schalte die Statistikfunktion nochmal vorübergehend an und öffne dann einen der Downloadlinks in einem neuen Fenster/Tab (dazu z.B. den Mauspfeil über den Link "Download" bewegen, dann mit der rechten Maustaste klicken und im sich öffnenden Menü die entsprechende Option wählen).
    Erhältst du eine Fehlermeldung? Welche?
    2. Was ist, wenn du den Beitrag erneut speicherst? Funktioniert der Downloadlink dann?

    Gruß,
    Tim

    ps: Probiere danach auch mal Full anstelle von Full+. Aber versuche erstmal eine Fehlermeldung zu erhalten mit den Einstellungen, die du bis vor kurzem verwendet hattest.

    Das Problem, welchem ich begegnet bin, scheint ein Problem des WordPress Importer Plugins zu sein. Es gibt dazu im WP.org Forum einen Thread (http://wordpress.org/support/topic/…custom-fields-1). Version 0.2 dieses Plugin scheint manche serialisierte Daten beim Import doppelt zu serialisieren. Das Problem scheint aber in der aktuellen Development Version (0.3 beta 4) behoben zu sein.

    Pascal, ich bin wirklich gespannt, ob das von dir beobachtete Verhalten eine andere Ursache hat.
    Wie gesagt, bitte untersuche, ob das erneute Speichern eines Beitrags Abhilfe bringt, - und vielleicht sogar noch interessanter - ob du beim öffnen eines Downloadlinks in einem neuen Fenster oder Tab eine (ähnliche) Fehlermeldung erhältst (bei eingeschalteter Statistikfunktion).

    Viele Grüße
    Tim

    Hallo Pascal,

    die Ursache des Problem ist doch nich so leicht zu finden, wie es mir vorhin schien und hat evtl. nicht unbedingt etwas mit WP 3.1 zu tun. Ich habe mir ein neues Blog angelegt und die Beiträge, Metadaten etc. per WP Export/Import in das neue Blog geholt und sämtliche Downloadlinks und MP3 Player funktionierten während die Statistikfunktion (stat method: Use WP Permalinks - stat logging: Full) an war. Ich habe die Downloadlinks in einem neuen Fenster geöffnet und sogar eine Fehlermeldung (Fatal error: Cannot use string offset as an array in ... podpress_functions.php on line 20..) erhalten. Allerdings habe ich dann während ich der Ursache des Fehlers nach ging, einen neuen Beitrag angelegt und eine Mediendatei angehängt. Diese Datei ließ sich dann prima herunterladen und abspielen. Außerdem ist es beim mir so, dass wenn einen der Importierten Beiträge mit dem Beitragseditor öffne und dann einfach abspeichere, gehen die Downloadlinks auch wieder.

    Das ganze scheint etwas damit zu tun zu haben, wie serialisierte Metadaten in der Datenbank gespeichert werden. Ich werde das weiter untersuchen.

    Aber unsicher zu gehen, dass wir nicht von unterschiedlichen Problemen berichten, wäre es gut, wenn du Statistikfunktion nochmal kurz anschalten könntest und dann einen der Downloadlinks in einem neuen Fenster/Tab öffnen könntest.
    Erhältst du eine ähnlich Fehlermeldung? Was ist, wenn du den Beitrag erneut speicherst? Funktioniert der Downloadlink dann wieder?

    Viele Grüße
    Tim

    podPress ist im Moment noch nicht kompatibel mit WP 3.1. Aber ich arbeite daran und bis WP 3.1 dann wirklich veröffentlicht wird, wird es bestimmt auch eine kompatible podPress Version geben (vielleicht auch schon früher).
    Es ist auf jeden Fall gut, dass du von dem Problem berichtet hast.

    Gruß
    Tim

    Hallo Pascal,

    es handelt sich nicht um ein generelles Problem. Ich kenne mehrere Blogs die eine der letzten podPress Versionen verwenden und es diese Probleme nicht gibt. Allerdings verwenden diese Blogs auch nicht WP 3.1.

    Daher wäre es für die Fehlersuche hilfreich, wenn du mehr über deine Statistikeinstellungen schreiben würdest (stat method, stat logging de_DE: Statistikmethode, Umfang der Datenerhebung).

    Vielleicht liegt es auch an einem anderen Plugin. Hast mal du ausprobiert, ob es funktioniert, wenn du deine anderen Plugin mal für einen Moment deaktivierst? Wenn du eins nach dem anderen wieder aktivierst und zwischen immer wieder den Download testest, kannst du heraus finden, ob es an einem anderen Plugin liegt - und auch an welchem.

    Da das auch mit den Permalink-Einstellungen zusammenhängen kann: Hast du diese in letzter Zeit mal verändert? Oder hast du vielleicht an der .htaccess Datei etwas verändert?

    Viele Grüße
    Tim

    Es freut mich, dass es funktioniert. Allerdings muss ich die obige Erklärung etwas einschränken und verbessern. Das Scenario "ein Feed mit dem Artikel und der .m4a-Datei als Anhang und ein Feed mit dem selben Artikel aber der .mp3-Datei als Anhang" sollte auch ohne die Option "Bypass the "Included in" selection for this Feed", nur über die Dateitypfilter, funktionieren.

    Zitat

    Wo finde ich denn diese Included in Einstellung?


    auf der Feed/iTunes Einstellungen Seite von podPress im Abschnitt podPress Feeds unter dem Dateitypfilter und dem Kategoriefilter des jeweiligen Feeds.

    Zitat

    Podpress war die ganze Zeit aktiv, aber wenn ich die Feed benenne und dann auf die URL gehe findet er die Seite dazu nicht.


    Hast du die Permalink Einstellungen nochmal abgespeichert?
    (Wie lautet denn die URL?)

    Um einen .mp3 Feed und einen .m4a Feed zu erhalten, kann man z.B. den normalen RSS Feed und einen podPress Feed nutzen oder z.B. 2 dieser podPress Feeds verwenden.
    Wenn man mehrere Dateien zu einem Artikel hinzufügt, kann man nur eine der Mediendateien so markieren, dass der Artikel mit dieser Datei als Anhang in RSS Feeds auftaucht. Daher war diese Konstellation (ein Feed mit dem Artikel und der .m4a-Datei als Anhang und ein Feed mit dem selben Artikel aber der .mp3-Datei als Anhang) bisher (bis 8.8.8.5) nur möglich, wenn einer der Feeds ein ATOM Feed war - welche prinzipiell auch als Podcastfeed geeignet sind.
    Seit podPress 8.8.9 gibt es aber eine neue Option für jeden dieser podPress Feeds, mit der sich die "Enthalten in:" (bzw. "Included in:") Einstellung für den jeweiligen Feed umgehen lässt und so in einer solchen Konstellation 2 RSS Feeds möglich sind.

    Wenn man 2 podPress Feeds nutzt kann man den Dateitypfilter des einen Feeds auf .mp3 stellen und den des anderen Feeds beispielsweise auf .m4a. Dann sollten beide Feeds nur Artikel enthalten, die auch eine Datei des gewählten Typs als Anhang haben. Wenn allen Podcastartikel mit podPress jeweils eine .mp3 Datei und eine .m4a Datei angefügt wurde, sollten beide Feeds die selben Artikel, jedoch nur mit Anhängen des gewählten Typs, enthalten.

    Falls podPress Feeds umbenannt oder (de-)aktiviert wurden und nicht das Standard-Permalinkschema verwendet wird, müssen die Permalinkeinstellungen (er-)neut gespeichert werden, damit die Feeds erreichbar werden.

    Viele Grüße
    Tim

    rizzo: wenn Sie auf der "Allgemeine Einstellungen"-Seite von podPress einen festen Speicherort (Absolute path of the media files directory bzw. vollständiger Verzeichnisname des Speicherorts der Mediendateien) angeben sollte dies der komplette Verzeichnisname und kein URL (mit http:// am Anfang) sein. Wenn diese Angabe falsch ist kann es zu dem von Ihnen beschriebenen Problem kommen.

    Werden in der Auswahlliste in der podPress Box unterhalb des Editors die Mediendatei auf gelistet, die sich in diesem Verzeichnis befinden?

    Um herauszufinden, ob es sich um ein Problem mit den Mediandateien oder ein anderweitiges Problem handelt, geben Sie bitten einen URL zu einer der Mediendateien an. Dies geht auch über die Auswahlbox.

    Und wie ixxoo bereits angesprochen hat, könnte es hilfreich sein, wenn Sie hier einen Link zu diesem/Ihrem Blog posten.

    Viele Grüße
    Tim

    podPress 8.8.6.x sollte mit WP 3.0.x funktionieren und tut es auch (siehe z.B. kuechenradio.org).

    Was funktioniert denn in Ihrem Fall nicht? Wenn Sie das Problem beschreiben, kann ich versuchen Ihnen zu helfen.

    Viele Grüße
    Tim