Beiträge von viehrig
-
-
Es könnte sich auch um eine falsch konfigurierte .htaccess-Datei handeln. Das ist aber alles Spekulatius. Die Idee, für Testzwecke einen Benutzers mit geringen Rechten einzurichten, klingt vernünftig.
-
frank Bueltge
Es ging immer nur um den HTML-Editor bzw. Texteditor. Und der filtert ein iframe-Tag nunmal nicht - normalerweise. Einzige Ausnahme bisher: Geplante Artikel in WP-Version 3.5
-
Seit gestern steht nun die WP-Version 3.5.1 zum Download zur Verfügung:
Deutsch:
http://de.wordpress.org/wordpress-3.5.1-de_DE.zip
Englisch/International:
http://wordpress.org/wordpress-3.5.1.zip
Nach dem Upgrade direkt von Version 3.4.2 habe ich erfolgreich einen Artikel mit iframe-Tags planen und veröffentlichen können. Der Fehler scheint also behoben zu sein.
Ob dies auch für den Adsense-Code von Google gilt, müßte noch getestet werden.
-
andreas11, @all
Dieses Ticket läßt hoffen, daß das Problem mit dem nächsten Update zur Version 3.5.1 gefixt wird:
http://core.trac.wordpress.org/ticket/22944
Damit ist, nebenbei bemerkt, die Aussage von malo.conny, daß iframe-Tags schon immer und egal mit welcher Einstellung in keinem Post verwendet werden konnten, ohne zuvor manuell irgendwo irgendwelchen Code zu implementieren, widerlegt.
-
Nachtrag: Herr Bültge hat die Kommentare unter dem Artikel zwar geschlossen, aber ein Kontaktformular:
Er hatte unlängst auf eine Frage von mir binnen weniger Stunden geantwortet.
-
Ich kann andreas11 bestätigen und habe insoweit meinen Kommentar in #25 zu korrigieren: Nach einem erneutem Downgrade auf Version 3.4.2 habe ich nun nochmals folgende Szenarien durchprobiert:
1) Theme Twenty Ten, aktivierter visueller Editor, komplett aktivierte Plugins
Ergebnis: Geplanter Artikel bleibt unverändert, in iframe-Tags eingebettetes Video erscheint.
2) Theme Twenty Ten, aktivierter visueller Editor, komplett deaktivierte Plugins
Ergebnis: Geplanter Artikel bleibt unverändert, in iframe-Tags eingebettetes Video erscheint.
3) Theme Twenty Ten, deaktivierter visueller Editor, aktivierte Plugins
Ergebnis: Geplanter Artikel bleibt unverändert, in iframe-Tags eingebettetes Video erscheint.
4) Theme Twenty Ten, deaktivierter visueller Editor, komplett deaktivierte Plugins
Ergebnis: Geplanter Artikel bleibt unverändert, in iframe-Tags eingebettetes Video erscheint.
Zwischen allen jeweiligen Versuchen wurde der Browser geschlossen, der dann automatisch den Cache leert, Cookies entfernt etc. Außerdem wurden zusätzlich mittels CCleaner nochmals der Browsercache geleert und temporäre Dateien gelöscht.
Bei allen Versuchen sah der Code für den Testartikel folgendermaßen aus:
HTML <center><iframe width="640" height="391" src="http://www.youtube-nocookie.com/embed/p175_3O8E3Q?hd=1&autohide=0&rel=0&showinfo=0" frameborder="0" allowfullscreen></iframe></center> <br />Es handelt sich also (das ist inzwischen wirklich eindeutig, finde ich) um einen Bug des Editors in Version 3.5.
Bezüglich der Unterbringung des Codes würde ich die Frage direkt an den Autor, Herrn Bültge, richten. Und zwar bei ihm selbst:
-
Will man iframes im Editor von WordPress erlauben, so muss man den Editor ergänzen, siehe:
http://bueltge.de/wordpress-wysi…weitern-2/1100/
http://wpengineer.com/1963/customize…wysiwyg-editor/Danke für die Links!
Inzwischen scheint klar zu sein, daß sich bei meiner WP-Installation vor 3 Jahren etwas derart verhakt hatte, daß mir dies die uneingeschränkte Nutzung von HTML ermöglichte. Offensichtlich ist das durch das Upgrade nun beendet und vorbei. Nachdem ich den visuellen Editor nach der Anleitung von codestyling deaktiviert hatte, geht HTML nun auch unter WP 3.4.2 nur noch eingeschränkt. Zum k....n, ehrlich.
Für meine Begriffe ist der Lösungsansatz von Herrn Bültge auch ein falscher. Ich will dem HTML-Editor ja nicht einzelne Tags beibringen (müssen), vielmehr bin ich der Ansicht, daß ich ihm die Eingriffe in meinen HTML-Code komplett und dauerhaft austreiben können muß. Deshalb ist das schließlich der HTML-Editor, nicht Text, nicht visuell, nicht sonstwas anderes. Ich hatte das 3 Jahre lang (augenscheinlich nur durch die glückliche Verkettung unglücklicher Umstände). Und ich will das wieder zurück.
Wo also holt sich der Editor die Anweisung für die Eingriffe in den Code her? Entweder muß die Anweisung gelöscht, verändert oder was auch immer werden. Oder man muß den Pfad zu ihrer Ausführung blockieren.
Nur: Wie macht man das?
-
Vielen Dank für den Hinweis auf den Pfad! Der visuelle Editor war tatsächlich wieder aktiviert.
Ich habe nun folgende Szenarien durchprobiert:
1. Theme Twenty Ten, deaktivierter visueller Editor, aktivierte Plugins
Ergebnis: Geplanter Artikel wird verändert.
2. Theme Twenty Ten, deaktivierter visueller Editor, komplett deaktivierte Plugins
Ergebnis: Geplanter Artikel wird verändert.
3. Theme Twenty Ten, deaktivierter visueller Editor, aktiviertes Plugin "Deactivate oEmbed" von Frank Bültge (gist.github.com/4437683)
Ergebnis: Geplanter Artikel wird verändert.
Muß jetzt noch ein weiteres Plugin installiert werden, damit HTML wieder geht?
-
Ich habe nun nochmals ein Upgrade zur Version 3.5 durchgeführt und kann die Fragen wie folgt beantworten:
1.) Können wir davon ausgehen, das beide Versionen, die du vergleichst auf "Werkszustand" sind (ohne Plugins und mit Twenty Ten beide) ?
Ja. Zu Testzwecken hatte ich nun auch mal auf Twenty Ten umgestellt.
2.) Hast du vorher sämtliche Browsercaches geleert und jeweils den Browser neu gestartet (damit gecachte Javascripts der TinyMCE mit iframe Support auch wirklich nicht mehr benutzt werden)?
Ja.
3.) Hast du in beiden Versionen den visuellen Editor komplett im Backend abgeschaltet (um nur noch HTML zu machen) ?
Ich habe weder eine Ein- noch eine Abschaltmöglichkeit des visuellen Editors im Backend gefunden. Mir ist inzwischen eingefallen, daß ich damals (unmittelbar nach der Installation von WP vor 3 Jahren) irgendwo nach Anleitung etwas verändert habe, um vollwertiges HTML verwenden zu können. Wo und wie, das erinnere ich leider aber nicht mehr.
-
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.
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/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!
-
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.
-
Ich hoffe, alle sind gut angekommen.
Ich habe den Code nun auch in der functions.php meines Themes getestet, das sah dann so aus:
PHP
Alles anzeigen<?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.
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.
-
Kurzer Zwischenbericht
Als eigenes Plugin in einen eigenen Plugin-Ordner ausgelagert habe ich den Code folgendermaßen getestet:
PHP
Alles anzeigen<?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!
-
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!
-
PS:
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?
-
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.zipEnglisch/International
http://wordpress.org/wordpress-3.4.2.zip2. 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!
-
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.
-
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 Artikel1. 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:
HTML <center><iframe width="640" height="395" src="http://www.youtube-nocookie.com/embed/tvRjyLxcHSo?hd=1&autohide=0&rel=0&showinfo=0" frameborder="0" allowfullscreen></iframe></center> <br />
Daraus wird im Moment der geplanten Veröffentlichung des Artikels:HTML <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?
