Hallo Stefan K.

Ich habe das gleiche Problem wie ihr Kunde. Und so wie es aussieht sind wir nicht die einzigen.

Ich hoffe sehr, dass es dafür bald eine Lösung gibt. So wie meine Internetseite momentan veröffentlicht ist, geht es garnicht..

Ich wollte sie hiermit anfragen ob sie mich kontaktieren könnten (vieleicht ein sms schreiben) damit ich sie anrufen kann.

Hier meine Nummer: 0041(79)751 34 00

Ich tu mich oft schwer im Umgang mit all diesen Suport-Texten, ein Gespräch mit einer kompetenten Person, die das wbsitex5 kenn, würde mir sehr helfen.

..vielen Dank

Ich habe eben ein paar Tests gemacht.

WinSCP oder FileZilla funktionieren bestens, haben aber den Nachteil, dass sie für jemanden, der sich überhaupt nicht mit Servern, FTP und dem Kram auskennt, viel zu komplex sind. Der "einfache" Website X5 Anwender hat davon keine Ahnung und muss sie auch nicht haben, er ist gewohnt, "Export der Website ins Internet" auszuwählen, ein paar mal "weiter" zu klicken und gut is. Wer es sich selbst oder seinen Kunden -fast- genauso einfach machen will, sollte den Weg über ein Command Line Interface gehen.

Dazu zuerst NcFTP installieren: ftp://ftp.ncftp.com/ncftp/binaries/Setup NcFTP 3.2.5.msi

Dann eine Batch Datei mit folgendem Inhalt erstellen:

ncftpput -R -u USER -p PWD SERVER "DEST" "SOURCE"

Hierin ersetzen

USER: FTP User Name
PWD: Password
SERVER: Remote Server, z.B. ftp.myserver.de
DEST: Zielverzeichnis auf dem Remote Server
SOURCE: Lokales Verzeichnis auf dem Rechner

Bleibt natürlich zu hoffen, das WebsiteX5 das Problem selber mal fixt. Aber der Workaround tut es solange.

Ich vergaß ...

SOURCE sollte natürlich das Verzeichnis sein, in das man bei WebsiteX5 über "Export der Website auf ein Laufwerk" seine ganzen Daten kopiert hat.

Ich habe eine Gemeinsamkeit zwischen mir und meinem Kunden festgestellt: wir haben beide seit kurzem eine wesentlich schnellere (nicht langsamere!) DSL Verbindung, nämlich 50000 Up / 10000 Down. Vorher waren es 1700 Up / 220 Down. Dass Daten verloren gehen, wenn die Übertragung schneller wird, habe ich allerdings noch nie gehört. Das wäre ein Armutszeugnis für Incomedia.

Es wäre schön, wenn die anderen Leser hier bestätigen oder nicht bestätigen könnten, ob bei ihnen auch eine schnellere Datenrate kürzlich installiert wurde und seitdem das fehlerhafte Verhalten auftritt.

Mittlerweile bin ich nahezu sicher, dass es an der Datenrate liegt, es erklärt jedenfalls alle Symptome.

Ich vermute, dass die FTP Upload-Routinen in WebsiteX5 kein ordentliches Handshake mit der Gegenstelle machen. Sie schicken wahrscheinlich die Datenpakete auf den Server raus, ohne auf die Bestätigung zu warten, dass sie auch ordentlich angekommen und akzeptiert wurden. Bei hoher Serverlast auf der Gegenstelle und entsprechend hoher Datenrate kann es deshalb dazu kommen, dass Dateien auf dem Server nicht komplett oder gar nicht abgespeichert werden. Und da der Server immer anders ausgelastet ist, passieren beim Upload die Fehler bei jedesmal bei anderen Dateien, wenn man Glück hat, gar nicht. Beim nächsten Mal aber wieder.

Das deckt sich genau mit meinen Beobachtungen. Ich habe mir "verdächtige" HTML Dateien auf dem Server angesehen, die hören mitten drin, z.B. nach einen <div> Tag auf. Oder JPG Dateien sind korrupt, genau gesagt zu kurz. Passt alles zum Fehlverhalten.

Es wäre natürlich ein riesengroßer Bock, den Incomedia da geschossen hat. Ein Upload, der überprüft, ob die Daten auch richtig ankommen, ist eine Selbstverständlichkeit. Als verantwortlicher Programmierer würde ich mich in die hinterste Ecke verkriechen und schämen.

Alles vorbehaltlich, dass meine Vermutungen stimmen. Bin mal gespannt, ob von denen eine Reaktion kommt. 

Es *kann* sein, dass die Lösung VIEL einfacher ist: neim Upload einfach das Häkchen bei "passives FTP verwenden" setzen. Das hatte ich zwar schon ausprobiert, aber die Caching Mechanismen meines Browser haben mich vera... und deshalb hatte ich fälschlicherweise angenommen, dass es nicht funktioniert hat. 

Mein Rat an alle, die das geschilderte Problem haben: "passives FTP" einschalten, alle Browser-Caches löschen (wenn ihr nicht wisst wie, dabei hilft google), dann die Website aus WebsiteX5 komplett neu hochladen und im Browser anzeigen lassen. Wenn es dann immer noch nicht funktioniert, helfen die o.g. Tipps.

Wenn das die Lösung sein sollte, nehme ich meine Anschuldigungen gegenüber dem Incomedia Programmierer mit Bedauern zurück. 

Bei Markus hat das "passive FTP" schon mal nicht zum Erfolg geführt.

Hallo Markus,

ich könnte per Remote Zugriff auf deinen PC die notwendigen Einstellungen / Installationen vornehmen, damit der FTP Upload Workaround bei dir funktioniert. Dazu müsstet du aber vorher die Software "Teamviewer" installieren:

http://download.teamviewer.com/download/TeamViewer_Setup_de.exe

Beim ersten Fenster der Installation "Installieren" und "privat/nicht-kommerziell" auswählen. Keine Sorge, die Software ist für Privatanwender kostenlos und das, was wir hier machen, ist privat. Sobald Teamviewer läuft, mich anrufen.

Gruß, Stefan

Nach einiger Suche durch die Answers-Threads hier habe ich etliche gefunden, die mit dem gleichen Problem kämpfen. Es wurde aber noch keine Anleitung seitens Incomedia gegeben, wie man das Problem fixt oder umgeht und erst recht nicht, woran es liegt. Es scheint ein sehr junges Phänomen zu sein, vielleicht 2-3 Wochen alt, bin mir dabei aber nicht sicher.

Kurzbeschreibung des Fehlers:

Bei Uploads aus WebSite X5 (Version 8.0.16) heraus, egal ob alles oder nur die geänderten Dateien, egal ob passiver oder aktiver FTP, landen die Dateien beschädigt auf dem Server oder fehlen ganz. Das führt zu fehlerhaften Darstellungen der Webseiten, fehlenden Bildern oder Texten, verrutschten Designs usw. Im Testmodus lokal auf dem PC ist alles prima. Es hat jahrelang funktioniert und plötzlich nicht mehr, ohne dass etwas geändert wurde. 
Der Upload mit externem Programm hingegen funktioniert fehlerfrei!

Fazit der letzten drei Tage:

• Es scheint nichts mit den Einstellungen in WebSiteX5 zu tun zu haben.
• Es scheint nichts mit dem Internet (DSL Provider, Speed, Router, Firewall) zu tun zu haben.
• Es tritt bei verschiedenen Usern / PCs auf
• Es tritt bei verschiedenen Hostern auf
• Es könnte an einem Windows Update in der letzten Zeit liegen, irgendwie "riecht" es danach
• Es könnte an einem Update auf den Servern der Hoster in letzter Zeit liegen

Es wäre super, wenn sich weitere Betroffene hier in diesem Thread äußern könnten. Zum Beispiel wäre es interessant zu wissen, ob das Problem auch mit anderen WebSiteX5 Versionen auftritt.

wie in meinem anderen Post beschrieben.

Datum der letzten Aktualisierung von Website X5: 15.11.2013

Datum der letzten Windows Update Aktualisierung: 27.9.2013

es kann also an keinem Windows Update liegen

Des Rätsels Lösung ist der IE11. Macht ein Rollback auf 10 und alle Fehler sind verschwunden. Keine Ahnung ob man im IE11 was Einstellen muß damit es geht. Auf jeden Fall ist so wie es aussieht inkompatibel zu Website X5 V7 & V8

Ist ja interessant, ich denke, wir kommen der Sache näher, im IE werden die ganzen Internet-Sicherheitseinstellungen für den PC definiert.

Benutzt du auschließlich IE? Ich verwende Chrome und da tritt der Fehler auch auf, aber natürlich befindet sich ein IE auf meinem Rechner, und wie erwartet IE11. Zurück auf IE10 kann ich nicht mehr, die Updatedateien habe ich alle gelöscht.

geht in die vermutete Richtung:

http://stackoverflow.com/questions/19683291/wininet-from-ie-11-randomly-returns-error-12003-for-most-ftp-functions

ja ich habe auch noch Chrome und Maxthon am Laufen habe eben ein Rollback auf IE 10 gemacht kein Problem mehr mir Website X5 und bin sogar noch weiter zurück auf IE 9 und Website X5 hat keine Probleme da ich mit IE10 Freezer am Rechner habe: Kannst du nicht einfach IE9 oder 10 downloaden und installieren. Deinstallieren kannst du ihn doch unter Programme Windows Funktionen Updates.

Gruß

Nee, schon probiert, geht leider nicht. Habe Win 8.1, das spielt da nicht mit.

Hello,

I have exactly the same problems as you with X5 V8, but what is really an enigma for me, is that when I import my site on an other domain it works almost well. While the same import on http://www.pariezmieux.com do something really bad.

It is true that I just changed from IE10 to IE11, last week. But if it comes from IE, why it doesn't work on Chrome and Mozilla?

This problem is really a headick for me. Already 3 days that my website is unreadable!

With the installation af IE11 you get some System DLLs replaced which are used also by other programs. That's the reason why all browers fail after installation of IE11 regardless if you use IE11 or not.

As far I understood, the bug in the wininet.dll has to do with the handshake procedures between your PC and the Server of your Website Host. So, it might work if the Server is fast and your PC and your internet connection is slow, but there is no guarantee.

If you want 100% error free uploads, you either have to roll back to IE10 or you have to use the latest version of FileZilla for external uploads.

Thanks Stefan

I rolled back to IE 10 and it works fine now.

Many thanks because I never could have thought that it comes from windows.

I hope that Microsoft will solve this problem, anyway I will stay with my old IE10, and don't want to upgrade it.