Artikel planen - Eingebette Videos verschwinden bei Veröffentlichung

Vor einigen Wochen habe ich ein Upgrade meines Blogs von WP 3.2 auf 3.4 und nun auf 3.5 durchgeführt.
Wie im Titel bereits erwähnt tritt seitdem ein Fehler im Zusammenhang mit der Planung eines Artikels auf. Der komplette Code zur Einbettung eines Videos ist im Moment der Veröffentlichung des geplanten Artikels verschwunden. Im Gegensatz dazu funktioniert er, wenn der Artikel

1. sofort veröffentlicht wird
2. im Dashbord in der Vorschau angezeigt wird
3. nach geplanter Veröffentlichung der Video-Code nachträglich wieder eingefügt wird.

Zur Fehlersuche bzw. Eingrenzung hatte ich bereits testweise sämtliche Plugins deaktiviert, ohne Veränderung, das heißt, der Fehler tritt trotzdem auf.

Da ich Artikel ausschließlich in der HTML-Ansicht erstelle, nachfolgend ein Beispiel:

 
<center><iframe width="640" height="395" src="http://www.youtube-nocookie.com/embed/tvRjyLxcHSo?hd=1&amp;autohide=0&amp;rel=0&amp;showinfo=0" frameborder="0" allowfullscreen></iframe></center>
<br />

Daraus wird im Moment der geplanten Veröffentlichung des Artikels:

 


<br />

Es sei angemerkt, daß der Fehler auch mit dem alten Embed-Code auftritt. Er tritt auch unabhängig vom Videohoster auf.

Fragen:

1. Woran kann das liegen?
2. Wie kann ich das beheben?

Narcanti

Zunächst einmal danke für die Reaktion.

Um ehrlich zu sein, ich verstehe nicht genau, wie die Frage gemeint ist. Wenn ich lediglich den Link zum Video einfüge, dann erscheint in dem Artikel auch nur der Link zum Video, was ja auch der Sinn der HTML-Ansicht des Editors sein sollte.

Im übrigen, wie oben bereits am Beispiel ersichtlich, möchte ich die Standard-Einbettung (beispielsweise von YouTube) in der Regel nicht verwenden und ändere sie in der Regel deshalb auch entsprechend ab. Das hat aber mit dem Fehler nichts zu tun. Auch die Standard-Einbettung habe ich versucht, der Fehler tritt auch dann auf.

Narcanti

Ganz herzlichen Dank für den Link! Der Artikel ist ein echter Augenöffner.

Der Fehler ist in den Augen der Entwickler von WP also gar kein Fehler, sondern Feature. WP schränkt die Möglichkeiten, Videos in das eigene Blog einzubetten, erheblich ein, erleichtert dafür aber die Handhabung der einzig verbliebenen Einbettungsmöglichkeit. Der Apple-Weg halt. Damit ist auch klar, daß das absehbar nicht behoben wird. Im Gegenteil hat man nun auch noch seit Version 3.5 die Möglichkeit gestrichen, dies wenigstens abzuschalten.

Nun, das ist nicht mein Weg.

Vorgehensweise für diejenigen, die das auch nicht haben und ebenfalls weiterhin selbst entscheiden wollen, wie sie vom wem welche Medien einbinden:

Downgrade

Voraussetzung: FTP-Zugang zum eigenen Blog, die meisten Hoster bieten dafür auch ein entsprechendes Web-Interface.

Backup der Wordpress-Datenbank anlegen, herunterladen und sicher speichern.

1. Download der letzten 3.4-Version von Wordpress (3.4.2) von hier:

Deutsch
https://wpde.org/files/2012/09/wordpress_342-de.zip

Englisch/International
http://wordpress.org/wordpress-3.4.2.zip

2. Speichern auf eigenem Rechner und entpacken.

3. Alle Plugins deaktivieren

4. Löschen sämtlicher Worpress-Ordner auf dem eigenen Webspace, ausgenommen des Ordners "wp-content"

5. Löschen sämtlicher WP-Dateien auf dem eigenem Webspace, ausgenommen ".htaccess", "wp-config.php"

6. Die Ordner der Version 3.4.2 hochladen, ausgenommen "wp-content"

7. Die entsprechenden WP-Dateien des Hauptverzeichnisses an die entsprechende Stelle hochladen

8. Den Admin-Zugang bzw. Login-Bereich aufrufen

9. Einloggen

10. Den Anweisungen zur Aktualisierung der Datenbank folgen

11. Im Admin-Bereich (Dashboard) auf Einstellungen --> Mediathek gehen

12. Haken entfernen bei "Einbettungen" --> "Automatische Einbettungen" --> "Versuchen Sie wenn möglich, Medieninhalte einer eingegebenen Adresse direkt im Artikel einzubetten. Beispielsweise für flickr oder YouTube."

13. Speichern durch Klick auf "Änderungen übernehmen"

14. Vorläufig auf Upgrades von WP verzichten

Nun funktionieren die Einbettungen der Medien wieder wie gewohnt und können selbst umfassend individuell gestaltet werden.

Danke nochmals, Narcanti!

PS:

Narcanti

Unter Link hatte ich verstanden, ein normales HTML-Tag zu bilden, also

<a href="URL" target="_blank">verlinkter Text</a>

gemeint war wohl aber der reine URL, richtig?

Narcanti

Nochmals vielen Dank! Auch noch am Sylvestertag hier helfend präsent zu sein, ist ganz großartig!

Bleiben mir abschließend einige Fragen: Wo füge ich den Code ein? In welche Datei? Oder gehört der in eine eigene PHP-Datei ausgelagert, die ich als eigenes Plugin in den Plugins-Ordner verschiebe, so wie es Herr Bültge bezüglich Twitter vorschlägt?

Guten Rutsch!

Kurzer Zwischenbericht

Als eigenes Plugin in einen eigenen Plugin-Ordner ausgelagert habe ich den Code folgendermaßen getestet:

<?php
/*
Plugin Name: Disable auto-embeds
Description: Disable auto-embeds in WordPress >= 3.5
Version:     1.0.0
*/


remove_filter( 'the_content', array( $GLOBALS['wp_embed'], 'autoembed' ), 8 );


?>

In dieser Weise funktioniert er schon mal nicht. Höchstwahrscheinlich habe ich da ein paar Fehler drin, nur welche?

Nun aber: Bis nächstes Jahr!

Ich hoffe, alle sind gut angekommen.

Narcanti

Ich habe den Code nun auch in der functions.php meines Themes getestet, das sah dann so aus:

<?php
/**
 * @package WordPress
 * @subpackage Classic_Theme
 */


remove_filter( 'the_content', array( $GLOBALS['wp_embed'], 'autoembed' ), 8 );


automatic_feed_links();


if ( function_exists('register_sidebar') )
    register_sidebar(array(
        'before_widget' => '<li id="%1$s" class="widget %2$s">',
        'after_widget' => '</li>',
        'before_title' => '',
        'after_title' => '',
    ));


?>

Das Ergebnis ist dasselbe wie bisher.

andreas11

Danke für den Hinweis. Inzwischen ist mir auch klar, worauf das hinauslaufen soll. Und inzwischen kommt Zorn auf.
Es ist sicher kein Zufall, daß der entsprechende Reiter im Editor (jedenfalls in der deutschen Version, die ich verwende) plötzlich mit "Text" anstatt "HTML" bezeichnet wird. Die klauen uns gerade den HTML-Editor. Die einzige Lösung derzeit ist ein Downgrade, das ich inzwischen mehrfach durchgeführt habe, da ich die verschiedenen Lösungsvorschläge von Narcanti natürlich immer mit der Version 3.5 getestet habe, um anschließend umgehend wieder ein Downgrade durchzuführen.

Ich bin fest entschlossen, den HTML-Editor gegen alle Diebstahlsversuche zu behalten. Ich bin dem Apple-Weg gegenüber solange tolerant, wie man mir die Freiheit läßt, diesen gar nicht erst zu betreten. Diese Grenze wird gerade überschritten.

Nochmal Narcanti

Ich weiß nicht, wie hier der Draht zu den WP-Entwicklern ist. Mein Englisch ist jedenfalls lausig und erreicht gerade die Fähigkeit, es einigermaßen verständig lesen zu können. Deshalb wäre meine Botschaft an die Entwickler derzeit weit jenseits jeglichen guten Tons etwa

"PISS OFF! TAKE YOUR HANDS OFF THE HTML-EDITOR!"

Das müßte nun jemand so an diese herantragen, daß sie auch bereit sind, die Botschaft zu empfangen und zu begreifen. Und vor allem die einzig richtige Konsequenz daraus zu ziehen.

Inzwischen ist für mich jedenfalls klar. Das Upgrade auf 3.5 fällt flach. Der Hinweis auf die Sicherheitslücken ist natürlich richtig. Es gibt aber Dinge, die kann und vor allem die darf man sich nicht bieten lassen.
Ich habe WordPress dereinst installiert, um größtmögliche Freiheit verbunden mit relativ einfacher Handhabung zu erlangen. Wenn die Entwickler unbedingt eine "Apple-Version" wollen, sollen sie diese bitteschön separat halten.

That's it.

kleinstadtgedanken

Solange man damit leben kann, daß nun einzig Google entscheidet, wie ein Video von YouTube eingebettet wird, und solange man die Einbettung etwaigen Codes von Google AdSense ausschließlich einem Plugin überlassen will und darauf vertraut, daß das schon irgendwie klappt, mag das derzeit (noch) so funktionieren, ja. Ich finde diese "Lösung" auf Dauer inakzeptabel.

Zitat von malo.conny

Dieses Thema ist nicht durch das Update von WordPress 3.5 gekommen. Der iframe Tag wurde noch nie im TinyMCE erlaubt, auch nicht durch den Wechsel in den HTML Modus. WordPress filtert im Standard dirverse Tags und Zeichen, ersetzt und formatiert. Darum werden unter anderen auch iframes gefiltert. Der Benefit des oEmbed liegt genau darin, denn man muss nur die URL des Ziels angeben und das Markup wird automatisch gebaut, je nach Plattform und unabhängig vom Veröffentlichungszeitraum. Will man iframes im Editor von WordPress erlauben, so muss man den Editor ergänzen, siehe:

http://bueltge.de/wordpress-wysiwyg-...eitern-2/1100/
http://wpengineer.com/1963/customize...ysiwyg-editor/

Ich habe ein Zauber-WordPress! Seit Jahren offenbar!

Denn das iframe-Tag nutzte ich, bald nachdem es durch YouTube als bevorzugtes Tag zu Einbettung von Videos vorgeschlagen wurde (das alte embed-Tag funktioniert übrigens trotzdem noch immer genauso). Welche WP-Version war denn vor 3 Jahren aktuell? Seitdem also durch alle Versionen hindurch.

Ich habe nun nochmals den obigen Code in einem geplanten Artikel genutzt (WP-Version 3.4.2), zuvor hatte ich selbstverständlich sämtliche Plugins deaktiviert, nur um auszuschließen, daß ein Plugin zaubert.

Und siehe, der Artikel erschien 2 Minuten später wie geplant, sah aus wie geplant. Und der Code war samt iframe-Tag unverändert. Wie ebenso geplant.

Was in der Version 3.5 plötzlich nicht mehr funktioniert.

Muß ich jetzt Screenshots anfertigen und verlinken? Oder wird mir das auch ohne solche geglaubt?

Es sei jedem freigestellt, den "Benefit" von oEmbed zu nutzen. Solange es mir freigestellt bleibt, darauf zu pfeifen. Da ich zu Einbettung der Videos spezielle Parameter nutze, die YouTube dereinst selbst herausgab und an die sich YouTube auch noch immer hält (z.B. Titel ausblenden), möchte ich diese auch weiterhin verwenden, was unmöglich wird, wenn ich die Einbettung der Videos direkt YouTube überlasse.

Aber immerhin scheint nun die Ursache auf den Editor eingegrenzt zu sein, der sich auf einmal Dinge herausnimmt, zu denen ich ihm nie den Autrag erteilt und die ich ihm nie gestattet habe. Und ich hoffe, daß ich ihm diese Eigenmächtigkeiten wieder austreiben kann.

Zitat von Narcanti

viehrig, ich verstehe den Ärger und den Zusammenhang mit Apple nicht. Ich sehe es nicht so, dass die WP-Entwickler versuchen den HTML-Editor zu klauen. Änderungen am Code und HTML-Filterung gab es schon immer (auto_p), wie malo.conny ja schon schrieb.
Bisher konnte ich WP aber immer an meine Bedürfnisse anpassen und ich denke auch, dass die Entwickler sich eben entscheiden müssen und nicht direkt alle Bedürfnisse aller Nutzer berücksichtigen können.
Allerdings habe ich mehrfach den gleichen Lösungsweg zum Deaktivieren gefunden. Wie genau testest Du denn ob das Deaktivieren funktioniert?
Eventuell wird dein Inhalt ja nicht über the_content angezeigt, dann kann der Filter zum Deaktivieren nicht greifen.

Hier noch mal Infos dazu:
http://wpgrafie.de/1078/wordpress-einstellungen-entfernt/

Narcanti

Der Bezug auf Apple ist sinnbildlich gemeint ("Alles easy-going, solange Du in unserem Gefängnis bleibst").
Die Tests habe ich natürlich auf die Weise durchgeführt, wie ich es oben schon beschrieben habe. Ich teste, ob meine geplanten Artikel unverändert erscheinen. In der Version 3.5 ist das derzeit nicht der Fall. In allen anderen Versionen zuvor war das aber so.

Wie dem auch sei, da steht mir umfassende Arbeit bevor, damit der HTML-Editor das tut, was er tun soll: HTML unverändert lassen. Deshalb hieß der nämlich bisher so.

Ich werde berichten.

Vielen Dank an alle, die sich mit dem Kram befaßt haben!