@Marc

Frage Dich jetzt ganz direkt:
Hat es einen Grund weshalb Du Fragen, wie zB. wegen E-Mails hier bewußt ausweichst ???

Gruß Dirk

Hallo jaspa, ich glaub Marc antwortet darauf nicht weil er im Moment andere Sorgen hat. Außerdem hieß es doch schon das Mails im Postausgang bleiben beim Versender. Sprich Unzustellbar.

Marc ich wünsch dir das alles wieder gut geht und zwar schnell.

Jaspa und alle anderen es tut mir leid für euch.

LG Brian

@japsa
Keine Ahnung, welche Frage ich dir beantworten soll (??)

Du liest hier mit und weist nicht, welche Fragen ?
Unverständlich!

Gruß Dirk

HMeine Seiten sind mittlerweile schon wieder verfügbar, jedoch gibt es folgende Fehler, die aus der Übertragung erfolgen, da vorher nicht da waren:

Umlaute und Sonderzeichen werden bei z.B. http://www.konexa.de nur noch kryptisch dargestellt.

Desweiteren gibt es ein php.ini-Problem:
Warning: Call-time pass-by-reference has been deprecated; If you would like to pass it by reference, modify the declaration of text_widget(). If you would like to enable call-time pass-by-reference, you can set allow_call_time_pass_reference to true in your INI file. in /var/www/vhosts/wipplertec.de/httpdocs/modules/i18n/experimental/ttext.module on line 148

Warning: Call-time pass-by-reference has been deprecated; If you would like to pass it by reference, modify the declaration of text_widget(). If you would like to enable call-time pass-by-reference, you can set allow_call_time_pass_reference to true in your INI file. in /var/www/vhosts/wipplertec.de/httpdocs/modules/i18n/experimental/ttext.module on line 148

Hat jmd. ähnliche Probleme und kann man das noch beheben?
Wäre toll, wenn alles so läuft wie vor dem Umzug

Ich kann zwar verstehen, das ein Umzug mit solch großen Datenmengen sehr lange dauert, am Ende sollte aber alles entsprechend funktionieren und keine Übertragungsfehler geben.

Ansonsten DURCHHALTEN

ich kenne das genannte problem von wippletec nur aus unkorrekten mysql-datenimports und wenn das der fall ist, dann ist das alles andere als "erfolgreich übetragen" ... das is nich 1:1 sondern vielleicht 1: 3/4

Da ahne ich schlimmes, wenn dann mal meine Seiten irgendwann mal wieder gehen sollten !

Jetzt fehlt dann nur noch die Aussage von Support, dass etwaiige Fehler, wenn dann mal die Seite wiede rgeht, man selbst beheben soll bzw. muß - auf sowas hab ich dann gerade ncoh gewartet

Jeder der mit der professionellen und schnellen Abwicklung von Host2Day zufrieden ist, kann ja auf Webhostlist.de eine entsprechende Bewertung abgegeben.

Etwas OT, aber hier notwendig:

@nitrit, das ist so nicht korrekt. Die Daten sind korrekt UTF-8, der Http-Header ist UTF-8, das UTF-8 - BOM ist mitgeschickt.

Ursache für die zerschossenen Umlaute unten scheint die Warnung oben zu sein, weil die den Browser aus dem Tritt bringt, so daß der Content vor dem <meta ... utf-8> hat.

Sprich: Verschwindet die Warnung (was wahrscheinlich über eine entsprechende PHP-Option möglich sein sollte - gabs vor kurzem einmal einen Thread), dürften auch die UTF-8 - Codierungen korrekt erkannt werden.

Ich bekommen diese Warnungen nicht und habe das gleiche Problem.

http://blog.autor-texter-content.com/

Das "UTF8" Problem, habe ich weitergegeben, der Bug ist anscheinend bekannt beim Migrationsmanager.

@simpsons
Kundennummer oder Domain, dann kann ich dir gerne weiterhelfen oder nützen dir deine 3 Posts in diesem Beitrag etwas um das Problem zu beheben? Das nennt man übrigens üble Nachrede, was du hier machst, also behalte das für dich.

Dann sieht es eher schlecht aus.

Da ist alles als UTF-8 definiert - im Http-Header, im Html-Header.

Grade nochmals nachgeguckt: Jetzt sieht es wirklich schlecht aus.

Wenn man sich den obigen Link mit dem Download.exe aus meinen Freeware-Tools holt, speichert und diese Datei mit dem Uralt-Editor edit öffnet, dann kommt folgendes raus:

Man sieht, daß das ü (eigentlich zwei Byte UTF-8 - Code) roh mit 4 Byte geschickt worden ist.

FireFox zeigt in der Dateiansicht an:

Das, was Firefox anzeigt, ist das, was geschickt werden müßte (und bei fehlerhaften Headern manchmal angezeigt wird). Geschickt wird aber, wie man per Edit sehen kann, die UTF-8 - Codierung der UTF-8 - Codierung.

das ist kein php.ini problem - da wird ein script, das für php4 entwickelt wurde, mit php5 ausgeführt.

function test(&$data) {
}

test(&$test);

ist in php5 veraltet. hier wird das so gemacht:

=> function test($data) {
}

test(&$data);

Es kann aber doch nicht sein, dass was vorher bei Host2day gehostet wurde funktioniert hat, hinterher nach dem Umzug dann plötzlich nicht mehr funktionieren soll, oder sehe ich es jetzt falsch ?

Werden denn bei einem Umzug zusätzlich noch Änderungen voorgenommen, wo dann die User dann zusätzlich noch eigene Änderungen am eigenen Projekt vornehmen müssen, damit es wieder so läuft wie vorher ??

Gruß Dirk

@jAuer

Ich werde nicht richtig schlau aus Deiner Antwort.

Muß ich das jetzt selber beheben oder sind bei Host2day noch irgendwelche Sachen nicht am Laufen?

Sylvia

@sylvia - ich habs mir jetzt nicht genau durchgelesen, aber ich würd behaupten, jAuer meint, dass host2day die datenbanken falsch portiert hat (charsets nicht beachtet)

ergo, abwarten bis host2day es behoben hat.

Danke!

Mach ich!

Ich werde ja auch nicht schlau aus dem Problem.

Bei dem ersten Beispiel sah alles noch (relativ) konsistent aus.

Beim zweiten (deinem) Beispiel verstand ich das zunächst nicht, sah nochmals genauer hin.

Und das, was ich oben geschrieben habe, da verstehe ich, daß das nicht mehr funktionieren kann (sprich: Meine erste Einschätzung war zu optimistisch).

Mir ist derzeit aber noch gänzlich unbekannt, auf welcher Ebene einem Tool ein Fehler unterlaufen müßte, um so einen Effekt zu generieren.

Ich kann auch aus der Entfernung nicht sagen, ob das Problem in der Datenbank oder bei den Scripts zu suchen wäre.

PS: Das

ist nicht meine Aussage. Ich weiß derzeit einfach nicht, wo der Fehler liegen könnte, ob diese Doppelcodierung bereits in der Datenbank existiert oder erst on the fly generiert wird.

Scheint wohl doch nur ein fehlender Eintrag in der php.ini zu sein, da die Datenbankinhalte korrekt mit Umlauten sind, so wie ich das auf die schnelle gesehen habe.

@SvenK

Ist korrekt, habe entsprechende & vor den Variablen entfernt und das Problem war behoben. Hoffe aber, dass es auch ohne diesen Workaround bald klappt:)

Leider ist das Problem mit den Umlauten damit nicht behoben. Auch nachdem der Fehler entfernt wurde, werden diese falsch dargestellt

@Marc:

Host2Day bezeichne ich als "besten Hosting-Anbieter" und deshalb bin ich auch schon eine ganz lange Weile mit dabei. Ich hatte alle Umstellungen auch die Adresse Balgach und mit dem Finanzentrum etc mitbekommen. War kein Problem.

Nichts gegen Host2Day ich werde immer ein treuer Kunde von Euch bleiben, denn wo bekommt man sonst als Reseller einen fast vollen Root zugriff und kann sogar für die eigenen Kunden selbst Domains anlegen? Nirgendwo, und wenn dann viel zu teuer.

Lediglich frage ich mich folgendes: Wie kann ich das allesmein Chef (er ist unser Kunde aber zugleich bin ich bei ihm angestellt - hat sich so ergeben) erklären ??? Geschäft ist Geschäft und obwohl er mein Chef ist und ich mit ihm ein gutes Verhältnis hab ist er, was unser Geschäft betrifft, ziemlich sauer. Da wir erst frisch gestartet sind haben wir auch im moment noch keine Versicherung für solche Situationen. Jedenfalls können wir ihm alles schreiben, alles erklären doch ihn interessierts nicht. Ihn iteressiert nur wann der E-Mail Account wieder geht. Cablecom und sontige grosse Firmen (Alstom, ABB, etc) geben Taxibestellungen bei ihm auf (das sind Jahrelange Stammkunden). Durch die überlebt er, das Geschäft und auch ich als Angestellter. Ohne diese Kunden würde er Konkurs gehen...

Nun seine Kunden hatten schon gedroht abzuspringen. Somit wäre sein geschäft ruiniert und auch unseres. Er musste allein heute persönlich bei diesen Kunden vorbeigehen und alles Erklären und entschuldigen. Ich musste mir einiges Anhören wie zum Beispiel (ich Zitiere:) "Alle meine Kunden sind bald plötzlich weg wenn das so weitergeht! Ich erlitt schon einen Verlust von über zweitausend Franken. Wer zahlt mir diesen Verlust? Niemand! Ich weiss Sie können nichts dafür aber mich interessierts nicht! E-mails sollen wieder funktionieren oder soll ich gleich vor Gericht und Sie wegen schweren Verschuldens und zerstören eines Geschäfts anklagen?? Muss ich mir noch überlegen... Eher weniger aber ich könnte, sollte noch mal so was sein".

Nun frage ich mich: Was soll man dazu noch sagen?
Alle anderen Kunden von uns verstehen den Ausfall voll und ganz, so wie wir auch.

@All
Weiss jemand von euch ob das möglich ist? Falls es jetzt zu einer Gerichtsverhandlung kommen würde... Wer würde da wohl gewinnen? Denn als frisch gestartete Einzelfirma ohne Kapital, die schon einen Auftrag hat (in der Anlaufs und Projektphase) laufen noch keine Versicherungen. Der Kunde war informiert, dass dies nicht unsere eigenen Server sind und wir hier keinen Einfluss darauf haben. Sowie Host2Day auch keinen Einifluss darauf hat, wenn PLESK nicht richtig funktioniert. Heisst, eigentlich sind wir sowie host2day unschuldig!

Hm.. Im Moment heissts nur "Abwarten und Tee trinken". - Nichts gegen Host2Day ist sonst eine Super Firma! Kompliment! Sofern solch ein Ausfall nie mehr vorkommt, wäre sehr sehr nett. Zum Glück haben wir noch keinen grösseren Kundenkreis, da dies sich sonst herumgesprochen hätte...