Beiträge von Melewo

Zitat von bgeissler

Nur wo durch wird die Zeile im fehlerhaften RSS erzeugt?

Ist zwar nicht so ganz neu, jedoch noch lesenswert. In einem Fall soll es zum Beispiel daran gelegen haben, dass der öffnende PHP-Tag in der functions.php in Zeile 2 verrutscht war:

http://blog.nina-boecher.de/2010/xml-verar…d-in-wordpress/

Noch etwas ältere Beiträge fand ich hier im Forum, wobei auch ein Beispiel-Code aufgeführt wird, wie Plugins nicht beginnen sollten:

http://forum.wpde.org/installation/3…-leerzeile.html

Zitat von Art of Avalon

mozilla komplett löschen und neu installieren, nach neustart......

Ich bin mir nicht sicher, ob das genügt, je nachdem wie sich die Malware (oder was auch immer das ist) eingegraben hat. Möglich das die dann in Profilen, in Systemdateien oder Dateien für die Wiederherstellung gespeichert bleibt. Vor einigen Jahren las ich mal etwas von Viren, die angeblich bis in den Bios vorgedrungen waren, da half dann wohl nichts mehr. Ganz so schlimm wird es nicht sein, wenn nur der FF befallen wurde, dennoch wäre es sicherer den Rechner neu aufzusetzen.

Ohne ein wenig Entwicklungsarbeit wird das wohl nichts werden. Hatte gestern noch eine einfache aufklappbare Liste erstellt, wobei bisher die Anfangshöhe mit onload und die Höhe der aufgeklappten Liste bei onclick ermittelt wird. Der iFrame passt sich zwar an, doch die Liste und der zweite Eventhandler gefallen mir noch nicht, so dass ich da so noch nicht veröffentliche.

Wenn das mit den bisherigen Codes noch nicht zufriedenstellend funktioniert, dann arbeite Dich doch einfach in postMessage ein, ist jedoch nicht sehr weit abwärtskompatibel. Mit

var  hoehe = document.getElementById("ID-Element").offsetHeight;
window.parent.postMessage(hoehe, 'origin');

kannst Du doch die Höhe bei jeder kleinen Änderung an die Frameseite senden, nur würde ich die übermittelten Daten gut filtern.

Geht nicht, geht nicht, geht nicht, wenn es wirklich nicht gehen will, dann bestellt man sich ein bis zwei Bücher und nach vier bis sechs Wochen des Lernens und Testens geht es gewiss schon sehr viel besser.

Na ja, grob übern Daumen würde ich sagen, zwei Drittel von den Funktionen setzen beim Editieren clientseitig mehr oder weniger auf JavaScript, jQuery und Ajax auf, so dass ich da schon zuerst die Browser verdächtigen würde.

Und ob bei edit# der formatfüllende DIV-Bereich öffnet oder nicht, da wird praktisch nur noch einmal eine Anfrage an den Server gesendet, um die wp-admin/admin-ajax.php zu laden und noch ein paar JPGs und mehr nicht. Was aber in diesem Zusammenhang eine gewisse Bedeutung haben könnte, steht im HTTP-Header: X-Frame-Options: SAMEORIGIN

Verlinke mal wegen einer besseren Erklärung und den Beispielen:
http://de.wikipedia.org/wiki/Same-Origin-Policy

Möglich dass da etwas schief laufen könnte bei mehreren Domains und Installationen innerhalb eines Paketes. Doch das ist halt nur etwas, was man mal für einen winzigen Augenblick in Betracht ziehen könnte und mehr halt nicht.

Zitat von fermate

außer, dass sich in der Browser-Adresszeile action=edit in action=edit# ändert.

Was ja erst einmal richtig ist, da sich ja keine neue Seite öffnet, sondern nur ein formatfüllender DIV-Bereich. Nur das die Raute / Hash nur im Link bzw. beim Überfahren des Links in der unteren Browserleiste aber nicht in der Browsereingabezeile mit angezeigt wird. Hast Du das schon mit unterschiedlichen Browsern getestet? Eventuell mit und ohne Pop-up-Blocker oder anderen Browsereinstellungen?

Zitat von bgeissler

Eine Installation bringt den selben Fehler, auch schon in älteren Versionen.

Hier mal der Unterschied zwischen Deinen und meinen Feed. Eindeutig eine Zeile zu viel zwischen HTTP-Header und Message-Body.

TCP/IP Socket (Endpunkt) wurde erzeugt: OK.
Eine Verbindung zu 46.252.31.219 über Port 80 wurde aufgebaut: OK.
Ein HTTP GET Request wurde gesendet: OK.


HTTP/1.1 200 OK
Date: Thu, 22 Aug 2013 08:33:59 GMT
Server: Apache/2.2.22
X-Powered-By: PHP/5.3.19
X-Pingback: http://gsew.de/xmlrpc.php
ETag: "xxx"
Set-Cookie: xxx
Last-Modified: Wed, 24 Jul 2013 16:40:32 GMT
Connection: close
Content-Type: text/xml; charset=UTF-8
Content-Length: 11698




<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
    xmlns:content="http://purl.org/rss/1.0/modules/content/"
    xmlns:wfw="http://wellformedweb.org/CommentAPI/"
    xmlns:dc="http://purl.org/dc/elements/1.1/"
    xmlns:atom="http://www.w3.org/2005/Atom"
    xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
    xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
    >


<channel>

TCP/IP Socket (Endpunkt) wurde erzeugt: OK.
Eine Verbindung zu 81.169.145.157 über Port 80 wurde aufgebaut: OK.
Ein HTTP GET Request wurde gesendet: OK.


HTTP/1.1 200 OK
Date: Thu, 22 Aug 2013 08:36:52 GMT
Server: Apache/2.2.25 (Unix)
X-Powered-By: PHP/5.3.27
X-Pingback: http://www.coder-welten.com/xmlrpc.php
ETag: "xxx"
Last-Modified: Wed, 07 Aug 2013 18:56:36 GMT
Connection: close
Content-Type: text/xml; charset=UTF-8
Content-Length: 11459


<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
    xmlns:content="http://purl.org/rss/1.0/modules/content/"
    xmlns:wfw="http://wellformedweb.org/CommentAPI/"
    xmlns:dc="http://purl.org/dc/elements/1.1/"
    xmlns:atom="http://www.w3.org/2005/Atom"
    xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
    xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
    >


<channel>

Scheint doch wieder alles bestens zu laufen, wäre nur schön wenn Solo noch mitteilen könnte, wie er den Fehler lokalisierte: http://www.tischlerei-lohse.de/feed/

Und jetzt auf einmal flutscht der Feed wieder wie neu geschmiert?

Ich halte es für unwahrscheinlich, dass dies mit der wp-includes/feed-rrs2.php zusammenhängt und jede unüberlegte Änderung führt nur zu weiteren Fehlern. Ein kurzer Test hätte da gereicht und ein HTTP-Header muss ja ausgegeben werden.

Eine Deaktivierung von Plugins hat nichts gebracht, wie Du schreibst, da hätte ich mir mehr einen Fehler vorstellen können. Eventuell, dass da ein Plugin versucht etwas in den HTTP-Header zu schreiben oder diesen zu ergänzen und dabei dann der Fehler auftritt.

Jetzt ist da gar nichts mehr richtig erreichbar. Versuche mal den Ausgangszustand wiederherzustellen, dann werde ich morgen mal versuchen den Feed mit einem Bot einzulesen, der eventuell mehr anzeigen könnte. Ich hatte nur heute nicht mehr daran gedacht, dass ich ja einen Bot zu liegen habe, der HTTP-Header und Seite zusammen ausgibt. Da müsste dann eigentlich zu sehen sein, ob eine Leerzeile zuviel ausgegeben wird.

Und wenn Du nichts mehr verstehst, dann probiere halt:

<h3 style="clear:none">Unterschiedliche Mattenvarianten</h3>

Und wenn das nichts bringt, dann probiere halt:

<div style="float: right; margin: 0px;"
<a href="http://web260.login-32.hoststar.ch/Wordpress/wp-content/uploads/2013/08/Anwendungen-gross.jpg"><img alt="Anwendungen" src="http://web260.login-32.hoststar.ch/Wordpress/wp-content/uploads/2013/08/Anwendungen-gross-150x1024.jpg" width="122" height="889" /></a>
</div>
<h3>Kapillarrohr-Heizsysteme sind flexibel einsetzbar</h3>
<p>Die einzelnen, nur 4,5 Millimeter schlanken PP-Kapillarröhrchen sind parallel in einem Abstand von 10 bis 30 Millimeter in der Matte angeordnet ...

Und wenn das auch noch nichts bringt, ja dann ...

Ja, aber da liegt doch style="float: right; innerhalb eines p-Tags und ich bin mir nicht sicher, wo bei Dir die nächste Flussbegradigung ihre Wirkung entfaltet. Ohne clear würde alles so lange fließen, bis das Bild zu Ende wäre. Kann sein, dass dieser Fluss bereits am nächsten Absatz oder aber erst mit dem nächsten Titel wieder aufgehoben wird.

Das ist nicht Dein Quelltext. Da wird eventuell ein clear: both; dazwischen funken. Ist das schon bei p-Tags der Fall oder erst nach H-Tags? In der CSS würde ich dann nichts schrauben, falls Du nicht auf allen Seiten eine Veränderung wünscht. Dann lieber statt <h3> eine CSS Klasse und Tags wie <span class="wie_h3">Text</span> verwenden.

Besser und einfacher ist wohl <h3 style="clear:none"> Text </h3> zu verwenden, nehme ich mal an. Da hilft nur probieren.

Von "Eigene Bilder" oder woher auch immer => nach "Neue Dateien hochladen" => "Dateien hierher ziehen", da brauchst Du nicht einmal etwas hochladen, da brauchst Du die nur von einem Fenster ins andere ziehen. Ganz normal über Dateien hochladen geht es aber auch.

Ich kenne mich nur mit Feeds aus und mit denen eigentlich zur Genüge, wo was bei WP gerendert wird, da schaue ich hingegen aber auch ab und an nur wie so ein vierbeiniges Tier ins Uhrwerk. Würde jetzt mal auf die wp-includes/feed-rrs2.php tippen, dann aber immer noch nicht verstehen, wie sich da über dem ersten echo eine Leerzeile einschmuggeln kann, da die Ausgabe ja eigentlich erst mit echo beginnt.

Zwischen Header und Content sollte auch eigentlich eine Leerzeile sein, nur sollte die nicht im Feed mit ausgegeben werden. Du könntest die auf eigenes Risiko mal entfernen, also die Zeile zwischen $more und echo, doch eigentlich müsste der Fehler wohl noch woanders verbaut sein. Vielleicht einfach mal schauen, ob da etwas verrutscht ist. Bei mir sieht es so aus:

header('Content-Type: ' . feed_content_type('rss-http') . '; charset=' . get_option('blog_charset'), true);
$more = 1;


echo '<?xml version="1.0" encoding="'.get_option('blog_charset').'"?'.'>'; ?>

Wird hier nicht korrekt wie erwartet angezeigt, die erste Zeile ist durchgängig.
Ansonsten alle Plugins deaktivieren und schauen ob der Fehler dann verschwindet.

Zu der von Dir verwendeten Funktion hatte ich gestern noch eine abgewandelte Funktion gefunden. Ob die mehr bringen würde, weiß ich jedoch nicht, doch die Tipps bei Stack Overflow sind oft nicht schlecht.

http://stackoverflow.com/questions/1500…ion-not-working

Ansonsten wäre noch überlegenswert, ob Du nicht doch die Events von den Klicks im Menü abfangen solltest, ob mit postMessage oder mit einem anderen Eventhandler bleibt erst einmal dahingestellt. Jedenfalls so, dass die Funktion nicht nur bei onload sondern auch bei einem Klick im Frame aufgerufen wird.

Für User und nicht für Bots, die zuerst nach einer Startseite und nach allen möglichen Seiten für die Registrierung suchen, dann den Duden in Variationen als Liste abarbeiten.

Bei mir ist die 104 auch im Chrome nicht erreichbar und somit allgemein nicht erreichbar.

Ich halte mich heraus was sinnvoll ist und was nicht, doch jede zusätzliche Übertragung von irgendwelchen Login-Daten würde ich als zusätzliches Risiko ansehen, ohne SSL auf jedem Fall. Die günstigste Variante wäre, wenn nur eine Hand voll eingeweihter Leute weiß, wie eine Login-Seite erreichbar und ein Login möglich ist.

Kann nur ein kleiner Fehler sein, ist alles richtig, beginnt aber erst in Zeile 2 und sollte in Zeile 1 beginnen. Einen BOM oder Umbruch kann ich aber auch nicht entdecken, falls sich beim Speichern einer eingeschlichen haben sollte.

<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"

Hast Du das durch irgendetwas vermurkst?

Edit: Also, in Hex enthält die erste Zeile 0D 0A und somit \r\n und somit doch irgendein Zeilenumbruch in PHP?

Zitat von fhmuc

Könnte ich nun auf meiner Index seite (rootfolder auf der domain) abfragen ob das Wordpress cookie vorhanden ist und mich dann automatisch weiterleiten zu lassen ?

Allgemein, hängt davon ab, ob ein Cookie für die ganze Domain oder nur für spezielle Verzeichnisse gültig ist. Dein Vorhaben hört sich für mich nach einer Frage an, in etwa: "Wie kann ich Sicherheitslücken einladend gestalten."