[QUOTE=Stroet;184816]Also wenn das kein bug ist …[/QUOTE]
Ist es auch nicht. Du versuchst ein widget (Karte) eines amerikanischen Anbieters (Google) mit Daten zu fütterrn, die nicht UTF-8 kodiert sind (was Google bei allen seinen widgets voraussetzt).
In einem Punkt hat stroet aber Recht: die Begründung, ob UTF-8 ja oder nein, ist Quark mit Sosse
Ich glaube, die Diskussion hatten wir hier schon einmal … der Performanceunterschied ist nicht einmal mehr messbar inzwischen bei aktueller Serverhardware. UTF-8 als Standard und solche Probleme, wie von Stroet, können gar nicht erst auftreten.
[QUOTE=wolkenkrieger;184817]Ist es auch nicht. Du versuchst ein widget (Karte) eines amerikanischen Anbieters (Google) mit Daten zu fütterrn, die nicht UTF-8 kodiert sind (was Google bei allen seinen widgets voraussetzt).[/QUOTE]
Ich versuche mich einfach an den Anleitungen der Installationsroutine zu halten.
Da steht nirgends, das ich UTF-8 verwenden muss, wenn die Map funktionieren soll.
Da aber das eine mit dem anderen verkettet ist, ist das dann eine Auslegungssache, ob das nun ein bug ist oder nicht.
Wenn ich einen Laden gehe, der am Eingang damit wirbt, das ich mit der Kreditkarte zahlen kann, mir dann aber an der Kasse erzählt wird “nur bares ist wahres”, ist das auch ein Fehler im Gesamtsystem. Merkste was?
Aber du hast es ja schon wahrgenommen. Der Haken muss da weg. Sonst ist das nicht kompatibel mit dem einem Punkt unter flow.
Oder … und jetzt komme ich wieder auf meine API-Lösung zurück (siehe einige Post zurück). Vielleicht sollte man das als Standard etablieren. Funktioniert prima und hat viel mehr Möglichkeiten.
PS: Zitat WIKI
Ein Programmfehler oder Softwarefehler oder Software-Anomalie, häufig auch Bug (englisch) genannt, bezeichnet im Allgemeinen ein Fehlverhalten von Computerprogrammen. Dies tritt auf, wenn der Programmierer eine bestimmte Festlegung der Spezifikation nicht oder falsch umgesetzt hat, oder wenn die Laufzeitumgebung fehlerhaft bzw. anders als erwartet arbeitet. Weiterhin können auch Unvollständigkeit, Ungenauigkeit oder Mehrdeutigkeiten in der Spezifikation des Programms zu „Fehlern“ führen.
[QUOTE=Stroet;184818]Wenn ich einen Laden gehe, der am Eingang damit wirbt …[/QUOTE]
In unserem Fall stünde unter dem Text aber noch “Achtung! Unsere Kartenzahlungsterminal befindet sich im Testbetrieb und ist für den eigentlichen Betrieb des Ladens noch nicht frei gegeben.”
Sprich: Flow ist beta (wusstest du, oder?) … und die Installanleitung aus einer Zeit, in der es das tolle Kartenwidget noch gar nicht gab.
Haarspalterei, ich weis
Die iframe-Lösung halte ich aber in der Tat für lame. Die API-Variante sollte in der Tat beim Release als Lösung präferiert werden, finde ich.
ja, es ist ein Bug.
Wir hätten uns aber schon vor Jahren darauf geeinigt und das Problem besser nachvollziehen können, wenn du uns nicht die Hälfte der Fehlermeldungen verschwiegen hättest.
Nämlich, dass das iFrame zunächst eine 400er Fehlermeldung von Google zurückliefer, um genau zu sein sagt Google da "Your client has issued a malformed or illegal request. That’s all we know."
Und erst die Fehlerseite wirft die Same Origin Fehlermeldung, die du uns genannt hast.
So wären wir direkt drauf gekommen, dass eine latin1 kodierte Adresse von Google nicht angenommen wird.
Und nun zu der Ursache: die Adresse wird mit urlencode() für die Verwendung als URL Parameter kodiert. urlencode() setzt aber eine utf8 Kodierung voraus.
Lösung:
Problem gelöst. Ohne unnötiger API Keys und Registrierung bei Google. Funktioniert aber nur für Shops, die nicht im UTF-8 Modus laufen.
Im utf8 Shop führt das zu den selben Problemen, die es im nicht-utf8 Shop gab.
Ich wollte eigentlich nur auf diesen Umstand hinweisen.
Schließlich möchte ich nur dazu beitragen, das alles rund läuft und anderen meine Erfahrungen mitteilen.
Schön wäre natürlich, wenn das tatsächlich irgendwie gerade gezogen wird. Hat mich jetzt schon ein wenig Zeit gekostet - aber macht ja auch Spaß.
In diesem Sinn - macht was raus, sonst knallen noch andere vor die Wand :o
Da kennst du mich aber schlecht - ich probiere [B]JEDEN[/B] Schalter aus, der mir in die Quere kommt
Und Hartnäckigkeit zahlt sich in der EDV doch immer wieder aus @wolkenkrieger
Noch eine Anschließende Frage: Kommt soetwas mit in das nächste Update? Oder wie wird hier bei OXID vorgegangen?
Ich bin ja immer noch am testen und möchte mich bald festlegen, welches System ich für ein neues großes Shop-Projekt verwenden soll.
Weil wir die Lösung ja haben und es ab hier ohnehin OT würde:
Spalten wir mal weiter Haare ->
Das ganze ist kein Bug, weil:
das System absolut korrekt arbeitet!
Die Daten werden dem Anwenderwunsch gemäß latin-kodiert in der DB gespeichert und so auch an das Theme ausgeliefert. Diese wiederum liefert diese Daten an ein widget aus, welches aber utf8-kodierte Daten erwartet … UND … eine entsprechende Fehlerbehandlung vornimmt in Form einer Fehlermeldung.
Das ist ein zu erwartendes Verhalten der gesamten Ereigniskette. Mein TI-Professort würde mit dir jetzt bis auf’s Blut diskutieren, dass das System NICHT fehlerbehaftet ist Und ja, TI (theoretische Informatik) - ich hatte noch Compilerbau, Turingmaschinen und dergleichen Unnützes im Studium
… ich wußte, da kommt noch etwas :rolleyes:
So, Pipi machen - Hände waschen - ab ins Bett (das hat mir meine Mutter immer heruntergebetet). Auf einen neuen Tag!
PS: Ich installiere unseren Test-Shop doch besser noch mal im UTF-8 Modus
In einem Punkt hat stroet aber Recht: die Begründung, ob UTF-8 ja oder nein, ist Quark mit Sosse
Ich glaube, die Diskussion hatten wir hier schon einmal … der Performanceunterschied ist nicht einmal mehr messbar inzwischen bei aktueller Serverhardware. UTF-8 als Standard und solche Probleme, wie von Stroet, können gar nicht erst auftreten.[/QUOTE]
Ich hab jetzt nicht den ganzen Thread gelesen aber ich glaube, zu dem Thema habe ich mich schon sehr lange nicht geäussert. Fakt ist, dass die 6er komplett auf UTF-8 rauskommt - und darauf freue ich mich
Habt ihr wenigstens nebulös (ja, ich weis - ich hab lange genug als Entwickler gearbeitet: lass dich nie auf einen Termin festnageln^^) einen terminlichen Fahrplan?
Ich wollte jetzt im 1. Quartal 17 mit dem 4.10.x live gehen, würde aber tatsächlich alles mit dem 6er soweit vorbereiten und dann erst den Sprung machen, wenn es zeitlich vertretbar ist (ich brauch eigentlich nur das responsive Theme - ich hab laut Paypal 75% mobile Kunden) … und solange eben mal mit der beta rumspielen. Dann lass ich die 4.10 gleich links liegen und fang jetzt gar nicht erst damit an (war für die Tage tatsächlich geplant).
Nebulös steht tatsächlich Ende Q2 (Juni) für die V6 im Raum. Es wird Migrationspfade geben, so dass Du im Grunde in Ruhe auf der 4.10 aufbauen kannst, um dann auf die V6 zu heben. Es wird trotzdem mit Arbeit verbunden sein.
musst du leider direkt in contact.tpl eintragen: “&key=YOUR_API_KEY” an die iframe URL dranhängen.
Hast du eine Email von Google bekommen, dass es nicht mehr ohne API Key geht? Oder wo steht das?
Ich bin eigentlich im Google Maps Newsletter, aber davon wusste ich nichts.
Die letzten Tage haben dann die Maps bei einigen neueren Typo3 Projekten nicht mehr funktioniert und es musste ein Key verwendet werden.
Bei älteren Projekten gibt es wohl noch eine Galgenfrist.
Diese eine MyISAM, die es noch braucht, erzeugt jedesmal eine Turmorzelle mehr im Hirn