Hallo, ich habe vermutlich Tomaten auf den Augen.
Unter der Seite “Sie sind hier:Kontakt” wird bei mir nur weiter unten das Formular angezeigt. Es sollte doch oben die Standortkarte von Google-Maps angezeit werden. Nur wo stelle ich die Latitude und Longitude ein?
Aktuell ist auf der Seite nur eine große weiße Fläche zu sehen.
Danke.
Ich weiß nicht, ob es mit lat. und long. klappt, aber eine richtige Adresse kann man in den Theme Einstellungen unter “Kontakt” eintragen.
Ok. Das Problem liegt bei mir woanders …
Der IE (hatte zum testen immer den FF verwendet) gibt folgendes aus:
Dieser Inhalt kann nicht in einem Frame angezeigt werden.
Um die Informationen zu schützen, die Sie auf dieser Website eingeben, hat der Herausgeber dieser Inhalte das Anzeigen der Inhalte in einem Frame untersagt.
Ich denke das liegt wohl am Webserver. Der HTTP-Header sagt folgendes aus “X-Frame-Options: SAMEORIGIN”.
Nur bekomme ich es einfach nicht hin, externe URLs wieder zu erlauben. Mit dem Problem stehe ich bestimmt nicht alleine.
Ich teste auf einem Ubuntu 14.04.5 mit apache2.
Was muss ich genau tun, um die Beschränkung wieder aufzuheben?
Danke.
das ist dann wohl kein OXID Problem, sondern ein IE Problem.
Na ja, nicht wirklich IE. Der gibt den oben genannten Hinweis aus. Der FF gibt den iFrame auch nicht wieder, gibt aber nicht die Meldung des IEs aus.
Somit funktioniert es mit keinem Browser.
Es ist wie gesagt eine Einstellung des Webserver.
Ich habe aber keine Ahnung, wie ich die Beschränkung wieder aufheben kann.
Davon mal abgesehen, habe ich gerade ein wenig quer gelesen. Diese Eintsellung ist ein Sicherheits-Feature, die eigentlich alle Webserver fahren. Somit sind iFrames, die auf externe Quellen verweisen, nicht mehr wirklich geeignet. Moderne Browser werten die X-Frame-Options aus und unterbinden die Darstellung des iFrames. Es wurde einfach zu viel Schindluder in der Vergangenheit damit betrieben.
Wäre es nicht viel sinnvoller, eine solche Funktion per PHP zu inkludieren?
Mein Problem ist leider noch nicht gelöst.
Würde mich über weitere Ideen oder mögliche Maßnahmen freuen.
Danke.
Vermutlich ist es in dieser Form ein wenig verträglicher:
https://developers.google.com/maps/documentation/javascript/
Dabei fällt mir auf, das mit der hier vorgestellten iFrame-Methode auch nirgends ein Wort von dem notwendigen API-Key gesprochen wird (verm. weil iFrames das umgehen), um rechtssicher auf Google-Maps zugreifen zu können.
Ist diese API-Methode nicht viel sinnvoller und wie könnte man das einbauen, bzw. grundsätzlich in den Quellcode für alle etablieren (vielleicht nächstes Update)?
Nur so Ideen, die mich gerade beschäftigen und mir vor die Füße fallen 
Moin Stroet
Das ist deine Lösung: https://developer.mozilla.org/de/docs/Web/HTTP/Headers/X-Frame-Options
Einfach in der htaccess setzen und gut isses
[QUOTE=wolkenkrieger;184783]Moin Stroet
Das ist deine Lösung: https://developer.mozilla.org/de/docs/Web/HTTP/Headers/X-Frame-Options
Einfach in der htaccess setzen und gut isses :)[/QUOTE]
So einfach ist das nicht. ALLOW-FROM wird lediglich in FF und Safari supportet. Alle anderen User sehen weiter das leere Feld. Nicht so toll.
Hmm, ich bin gerade ein wenig mit der Google-API am testen. Das geht schon mal zu 50%. Hoffentlich bekomme ich das noch ganz hin - die Lösung ist dann browserunabhängig. Leider muss ich dafür die Templates ein wenig verbiegen. Nicht so schön, wenn die Updatefähigkeit erhalten bleiben soll.
[QUOTE=Stroet;184784]So einfach ist das nicht.[/QUOTE]
Doch: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy 
Man kann mehrere Varianten derselben Direktive in der htaccess haben - der IE und der Safari (imo) holen sich das allow-from, alle anderen die CSP.
Hallo, das mit dem iFrame gefällt mir nicht und kann mich damit auch nicht anfreunden. iFrames werden auch von Google nicht gerade mit offenen Armen empfangen.
Darum habe ich jetzt das Ganze jetzt per API umgesetzt.
Anbei gebe ich hier meine Wissen einfach mal weiter. Ich pers. denke, das die Implementierung per API viele Vorteile hat. So können zum Beispiel auch Markierungsmarken, Beschriftungen etc. einfach auf der Map hinzugefügt werden. Mit einem iFrame nicht denkbar. Und auch die X-Frame-Options-Problematik gibt es nicht.
Bearbeiten:
\application\views\flow pl\layout\header.tpl
Neu hinzufügen unter Zeile 70
[{/block}]
<script src="https://maps.google.com/maps?file=api&v=2&key=[B]DEIN-API-KEY[/B]" type="text/javascript">
</script>
<script type="text/javascript">
//<![CDATA[
function load() {
if (GBrowserIsCompatible()) {
var map = new GMap2(document.getElementById("map"));
var punkt = new GLatLng(48.340181, 10.903297);
map.setCenter(punkt, 14);
var marke = new GMarker(punkt);
map.addOverlay(marke);
}
}
//]]>
</script>
Bearbeiten:
\application\views\flow pl\page\info\contact.tpl
Zeile 16 - 18 ersetzen mit:
<div id=“map” style=“width: 100%; height: 400px”></div>
Das war es schon. Dann stehen jetzt alle Freiheiten per API bereit.
Wichtig ist natürlich, das Ihr Euch noch einen kostenlosen API-Key bei Google besorgt. Geht ganz schnell. Hier der Link dorthin:
https://console.developers.google.com/flows/enableapi?apiid=maps_backend,geocoding_backend,directions_backend,distance_matrix_backend,elevation_backend,places_backend&keyType=CLIENT_SIDE&reusekey=true
Viel Spaß damit!
Das hat mir doch keine Ruhe gelassen und ich habe nun den eigentlichen Grund gefunden, warum unsere Adresse nicht in dem iFrame unter Kontakte dargestellt wurde.
Meine oben genannte API-Lösung funktioniert auch.
Aber …
Ich habe habe eine Bug im Flow-Themes gefunden:
[B]Ergo: fieser kleiner netter bug, der mich fast irre gemacht hat …[/B]
Sollte sich mal ein Entwickler ansehen.
Stroet, wenn du der Datenbank erklärst,sie soll kein UTF-8 speichern, dann ist das “Dein” Fehler und nicht das des Themes
Deiner Datenbank isses schlicht schnurz, welche Codepage dein Browser anzeigen will
Kollation: latin1_general_ci
Sollte doch passen?
Ja, passt auch aber dann brauchst du dich nicht wundern, dass im Backend Sonderzeichen falsch dargestellt werden. Die sind in der db anders codiert abgelegt als sie der Browser darstellen will.
?? Hä ??
Die Sonderzeichen werden doch nur falsch angezeigt, wenn ich die Textcodierung absichtlich umstelle, damit die Sonderzeichen sauber in die DB übertragen werden.
Im Standard sehe ich keine falsche Darstellung.
Danach wird die Map erst angezeigt.
Komm schon - das ist ein bug im Template …
Kann ich mir nicht mehr anders erklären.
Im theme_options.php ist folgendes hinterlegt:
‘charset’ => ‘UTF-8’,
charset im theme options hat nichts damit zu tun, der ist lediglich für die Übersetzungen.
Damit es ein Bug ist, müsste jemand anders das nachvollziehen können, aber es scheint bei allen anderen zu funktionieren.
Ikke noch mal …
Ich habe jetzt wild herumgespielt und komme zu einem Ergebnis: Es ist ein bug.
Bei der Shopinstallation kommt man zu einem Punkt “UTF-8 Zeichenkodierung benutzen?”.
Wenn dort der Harken gesetzt ist, funktioniert alles normal. Die Tabellen werden in UTF-8 erzeugt.
Ist er aber nicht gesetzt, kann der Fehler nachvollzogen werden. Die Tabellen werden hier in latin1_general_ci erzeugt.
Das erklärt natürlich einiges.
Und stellt sich nun die Frage, was da genau buggy ist.
In jedem Fall fängt das Template flow diese Gegebenheiten nicht ab (Sonderzeichen in der Adresse) und mein oben genanntes Problem entsteht.
Ich habe das jetzt auf drei verschiedenen unabhängigen Webservers getestet.
[QUOTE=Stroet;184812]
Und stellt sich nun die Frage, was da genau buggy ist.[/QUOTE]
[B][U]Gar nichts![/U][/B]
Es passiert genau das, was ich dir die ganze Zeit versuche zu erklären: deine ganze Datenbank wird als latin angelegt (die Standardeinstellung deines Datenbankservers! meiner würde in jedem Fall UTF-8 machen!) und kann kein UTF-8 abspeichern (bzw. kodiert die Sonderzeichen anders).
Sowas fängt man nicht in einem Theme ab! Das ist schlicht ein Anwenderproblem!
Setz dich doch einfach mal mit den Kodierungen in MySQL auseinander und die damit verbundenen Besonderheiten bei der Zeichendarstellung. Die Zeit würde sich sicher mehr lohnen als die Jagd nach Bugs, die schlicht nicht existieren
Es hat doch nichts damit zu tun, ob ich nun die DB mit der Kollation utf8_general_ci oder latin1_general_ci erzeuge.
Ausschlaggebend ist der folgende Punkt in der Installationsroutine:
- Installation Punkt 4. Datenbank --> UTF-8 Zeichenkodierung benutzen: nein (Haken raus)
- Begründung steht im Begleittext (benutze nur deutsch und ist etwas schneller): Die UTF-8 Zeichenkodierung kann besser mit Sonderzeichen umgehen als andere Zeichenkodierungen. Dies ist insbesondere für vielsprachige eShops wichtig. Allerdings ist der eShop mit UTF-8 geringfügig langsamer als mit der Standard-Zeichenkodierung (ISO 8859-15). Wenn Sie vorhaben, viele verschiedene Sprachen im eShop zu benutzen, sollten sie UTF-8 verwenden. Wenn Sie nur Sprachen mit ähnlichen Zeichensätzen (z. B. Deutsch, Englisch, Französisch) im eShop benutzen möchten, benötigen Sie UTF-8 nicht.
Also UTF-8 abgewählt. Und schon werden alle Tabellen in latin1_general_ci angelegt (obwohl die DB in utf8_general_ci angelegt wurde). Ein jetziger Blick unter phpmyadmin sagt, das nun die DB unter latin1_general_ci läuft. Somit hat die Installationsroutine die Kollation der DB geändert.
Ich bin also gezwungen den Haken bei UTF-8 zu setzen, wenn ich danach mit Sonderzeichen in meiner Adresse arbeiten möchte und die Map angezeigt werden soll. Obwohl der Begleittext etwas ganz anderes sagt und suggeriert.
Wenn dem so ist, warum dann diese Auswahlmöglichkeit? Nehme ich den Haken raus, funktioniert die Map-Funktion nicht richtig.
Alles andere funktioniert. Es geht wirklich nur um dieses ein Feld in der Konfiguartion des Templates flow.
Also wenn das kein bug ist …