Umlautdomain in base href und canonical url

[Theoretiker]

Hallo,

ich habe hier ein kleines kosmetisches Problem.

Ich nutze eine domain mit Umlauten. Der Shop funktioniert.

Damit der Shop funktioniert, muss ich in der /includes/configure.php den http_server auf die ohne umlaute aufgelöste Domain setzen.

Nun habe ich das "Problem" das beispielsweise Facebook eben anscheinend aus dem ebenfalls ohne Umlaute aufgelösten Basepfad oder eben der Canonical Url die eben selbst angelegte aufgelöste
URL anzeigt. Das ist unschön.

Nun würde man sagen, ja mensch, dann ändere hat den http_server auf die Domain inkl. Umlaut.
Der Umlaut wird dann aber nicht richtig interpretiert und mit kryptischen Zeichen ersetzt.

Ja sagt man dann, Du musst der Umlaut eben maskieren... aber weder ein kühnes "%C3%BC" noch ü wollen fnktionieren. Die werden im gegensatz zum umlaut direkt durchgeschickt.

Meine Idee wäre nun einfach den base pfad und den server der canonical url direkt überschreiben/ersetzen zu wollen.

Ich wäre an dieser Stelle über Ideen erfreut. Ich weiß, es gibt wichtigeres aber es ist einfach unschön und wirkt unprofessionell wenn der dargestellte Pfad beispielsweise bei einem FB Post nur sehr entfernt an die tatsächliche Zielurl erinnert. Die Leute sind inzwischen auch recht sensibel was "falsche" URLs angeht.

PS: Vielleicht bin ich an irgendeiner Stelle auch auf dem Holzweg, aber der Shop selbst arbeitet 100% inkl. Unlauten korrekt. Einzig canonical und base href scheinen sich am http_server zu orientieren, und an dieser Stelle habe ich das Problem des aufgelösten Zielpfades anstatt der Umlautdomain.

Lieber Gruß
Chris



Linkback: https://www.modified-shop.org/forum/index.php?topic=30985.0

[timopaul]

Moin,

wie lautet denn deine Domain mit Umlaut(en)? Wäre an dieser Stelle eine vielleicht nicht unwichtige Information.

Hast du es auch mit dem ACE-String der Domain in der /includes/configure.php versucht?

Besten Gruß,
Timo

[Theoretiker]

Ja, ok, der Fachbegriff.

Also mit aufgelöster Domain meinte ich den ACE String.

Ja, also ich habe den ACE String im Normalfall als http_server eingetragen,
und eben dieser wird dann als base href und canonical url (anfang) genutzt.

und leider eben auch bei Facebook angezeigt. Eben auch wenn man eigentlich die Orgininal-Domain
verlinken will.

Wie eine Domain mit umlaut aussieht müste eigentlich klar sein.
Tun wir mal so als würde sie demö-shop.de heißen

(Ich möchte nicht daß jetzt tausend Skriptkiddies versuchen den WIP zu hacken und auch nicht daß später diese Konversation in Google auftaucht wenn man eigentlich den Shop sucht... es ist ja ein Produktivsystem. Daher sei mir das Verschweigen der Originaldomain an dieser Stelle verziehen, tut auch nicht wirklich was zur Sache... denke ich...  )

Lieber Gruß
Chris

[Matt]

includes/header.php:

Code: PHP  [Auswählen]

<base href="<?php echo (($request_type == 'SSL') ? HTTPS_SERVER : HTTP_SERVER) . DIR_WS_CATALOG; ?>" />

ersetzen durch

Code: PHP  [Auswählen]

<base href="<?php echo (($request_type == 'SSL') ? idn_to_utf8(HTTPS_SERVER) : idn_to_utf8(HTTP_SERVER)) . DIR_WS_CATALOG; ?>" />

Könnte evtl. erforderlich sein, den gesamten Shop vorher auf UTF-8 umzustellen.

Man kann die Domain auch über einen URL-Shortener hier posten. Wenn ein einziger Beitrag hier aber dein Google-Ranking ins wanken bringt ist es um dieses wohl nicht zu gut bestellt.

[Theoretiker]

Danke!

Kannst Du mir den Sinn erklären, warum man für die Antwort auf meine Frage die Original Domain benötigt?

Mir gehts nicht ums Google-Ranking sondern ich eiere hier schon graume Zeit herum um simpleste Dinge zu implementieren von denen man denken könnte daß ein Shop sie von Haus aus mitbringt.

Auf einen späteren Kunden wirkt es schlichtweg unproffessionell 100 Treffer mit "oh, dies geht nicht, das geht nicht und jenes ist auch ein Problem" zu treffen. Es ist eigentlich himmelschreiend daß der Shop anscheinend Umlaute nicht vollständig unterstützt. Warum ich das jetzt auf Google in zusammenhang mit meinem Geschäft breittreten sollte erschließt sich mir nicht wirklich. Und mir erschließt sich ebenso wenig warum man so dringend die Domain benötigt um auf die Frage zu antworten. Wenn ich meinen Shop vorstellen möchte, mache ich das in einem entsprechendem Thread.

Ich kann es nicht verstehen warum ich in Deutschland mit vollständigem Aplhabet und Umlaut Domains seit 1999? hier überhaupt ein Problem habe. Mal ehrlich, da sind ein paar hundert tausend Codezeilen und sowas macht ein Problem?

Ich denke wir sollten langsam zum normalen Umgang zurückkehren auch wenn ich die Domain nicht nenne, dafür gibts hier ja wohl keinen Zwang oder?

Lieber Gruß
und danke für die Hilfe.
Chris

[Matt]

Kannst Du mir den Sinn erklären, warum man für die Antwort auf meine Frage die Original Domain benötigt?

Sagen wir es mal so: Ich hab es dreimal lesen müssen um den Kern deines Problems herauszufiltern. Da hilft ein Blick auf den betroffenen Shop manchmal schon, um schneller hinter das Problem zu kommen.

Mir gehts nicht ums Google-Ranking sondern ich eiere hier schon graume Zeit herum um simpleste Dinge zu implementieren von denen man denken könnte daß ein Shop sie von Haus aus mitbringt.

Die Diskussion, was ein Shop von Haus aus an Features zu haben hat und was nicht, ist in etwa so alt wie Shopsysteme selbst und wird nie für alle zufriedenstellend beantwortet werden können.

Auf einen späteren Kunden wirkt es schlichtweg unproffessionell 100 Treffer mit "oh, dies geht nicht, das geht nicht und jenes ist auch ein Problem" zu treffen.

Könnte es sein, dass du zu Übertreibungen neigst?

Ich kann es nicht verstehen warum ich in Deutschland mit vollständigem Aplhabet und Umlaut Domains seit 1999? hier überhaupt ein Problem habe. Mal ehrlich, da sind ein paar hundert tausend Codezeilen und sowas macht ein Problem?

IDN-Domains wurden 2004 eingeführt. Trotzdem ist eine flächendeckende Unterstützung nach wie vor nicht gegeben. Beispielsweise liest sich die Liste der Mailprogramme, die IDN-Domains unterstützen, ziemlich armselig. Und es ist ja nicht so, dass der Shop mit einer Umlautdomain nicht funktionieren würde. Du musst halt den ACE-String nehmen. Wie bei jedem Mailprogramm, dass Umlaute nicht unterstützt, auch. Das Facebook damit jetzt ein Problem hat dem Shop anzukreiden kann man natürlich machen...

[Theoretiker]

Ok, das leuchtet alles ein und ich danke Dir für die Erklärung.

Ich bin ein wenig hochgegangen und neige zu übertreibungen, weil ich den Teil Deiner Antwort:

Wenn ein einziger Beitrag hier aber dein Google-Ranking ins wanken bringt ist es um dieses wohl nicht zu gut bestellt.

...etwas überheblich und unangemessen empfunden habe zumal du weder mich, meine Arbeit, den Shop noch sonstetwas über mich weißt. Ich finde das nicht besonders nett. (Bin aber sicher auch etwas überspannt.)

Ok, was die Domains bzw. Umlaute angeht hast Du vollkommen recht.
Ich bin aber schon fast 20 Jahre in Mailboxen und Foren unterwegs und ich denke wir sind hier etwas aus dem Ruder gelaufen. Das kommt vor. Was mich betrifft, entschuldige bitte!

Ich möchte jetzt gern, wenn es ok wäre zum Thema zurückkehren, auf Vorhaltungen, Sarkasmus und Anmerkungen zu Zitaten verzichten und mich wie Erwachsene austauschen.

Warum ich die Domain nicht nennen wollte habe ich geschrieben und die Erklärung die Du mir gegeben hast ist einleuchtend.

Es geht um den Shop:
http://goo.gl/BXc9of

es scheint so als würde die itn_to_utf8 Funktion einen 500er Servererror triggern,
ich habe nun PHP5-intl nachinstalliert ... vorhanden ist Version 5.3.10 ...

EDIT: Nach einem Neustart gibt es keinen 500er mehr, aber ich habe nun am ACE String hinten ein
"xn--blabla-7sb45t.de" im Header anstatt ein "xn--blabla-s6b.de".

Nicht sauer sein, ich möchte bloß einigermaßen sauber posten können.

Lieber Gruß
Chris

PS: Wenn ich modified nicht klasse finden würde, dann würde ich es nicht schon kleine Ewigkeiten nutzen, es ist ein super Shopsystem, super anzupassen und sehr progressiv.... ABER hätte ich gewußt was hier wegen einem dämlichen ü auf ich zukommt hätte ich ue geschrieben ... es ist zum Haare raufen...

[Matt]

Das, was da in deinem Quelltext steht, ist jetzt die als ISO-8859-1 fehlinterpretierte Version eines ü. Laut deinem Meta ist der Shop zwar UTF-8, dein Server sendet aber ISO-8859-1. Das solltest du zunächst mal angleichen.

Dadurch kommt auch der falsche ACE-String.

Welche Kodierung benutzt denn dein Shop? Alle andere Umlaute, die ich gefunden habe, sind mit HTML-Entities geschrieben. Das geht aber beim base href nicht, weil es ja eine gültige URL sein muss.

Man könnte jetzt noch einen Trick versuchen:

Code: PHP  [Auswählen]

<base href="<?php echo (($request_type == 'SSL') ? utf8_decode(idn_to_utf8(HTTPS_SERVER)) : utf8_decode(idn_to_utf8(HTTP_SERVER))) . DIR_WS_CATALOG; ?>" />

Bin mir aber nicht sicher ob das funktioniert.

[Marcus Kreusch]

Wenn ich mich kurz einmischen darf:

Um das von Matt angesprochene Problem zu beheben könntest du an das Ende deiner /includes/application_top.php diese Zeile setzen:

Code: PHP  [Auswählen]

header('Content-Type: text/html; charset=utf-8);

Bei mir im Browser sieht es nach Umschalten auf utf8 auch mit dem <base>-Tag gut aus.
Deine Facebook-Tags und einiges anderes in deinem QUelltext allerdings sind nicht in utf-8 sondern iso-8859-1x hinterlegt.

Viele Grüße
Marcus

[Matt]

Alternativ, hab mir mal eben nen Testshop installiert:

Code: PHP  [Auswählen]

<?php
$url = parse_url($request_type == 'SSL' ? HTTPS_SERVER : HTTP_SERVER);
$url['host'] = idn_to_utf8($url['host']);
$server = $url['scheme']."://".utf8_decode($url['host']).$url['path'];
?>
<meta name="generator" content="(c) by <?php echo PROJECT_VERSION; ?> ------| http://www.modified-shop.org" />
<base href="<?php echo $server . DIR_WS_CATALOG; ?>" />

nach dem Kommentar in includes/header.php. In den configures steht der ACE-String.

[Theoretiker]

Boah, bin gerade zuhause angekommen... Ihr seid ja klasse!

habe mal beides gemacht....
mmh, jetzt habe ich wieder einen 500er... komisch...

Danke für Eure Hilfe.

[Theoretiker]

So,

heute alles ein wenig holperig, aber es geht vorran.

Der 500er hing mit einem zweiten geöffneten <?php zusammen , das der Shop nicht utf8 gesendet hat lag an einer Modul Arbeitsanweisung, bei der ich blind und blöd vor einiger Zeit in der htaccess auf
AddDefaultCharset ISO-8859-15 geschaltet habe.

Nun habe ich den von mir gewünschten basepath mit Umlaut,
und ich gebe zu, der Fehler war der User vor dem Bildschirm.

Dennoch möchte ich nun den Rest auch noch hinbekommen.

Mein Problem, nach der Umstellung auf UTF8 des Shops werden anstatt Umlaute nun überall Rauten mit
Fragezeichen dargestellt.

Und um es vorweg zu nehmen, ich denke das es an der Datenbank liegt, die Ihrerseits nämlich latin1_german_ci tabellen beherbergt. (weitestgehend)

Das ganze befindet sich in einer InnoDB latin1_swedish_ci Datenbank.
Frag mich bitte keiner wann ich das so eingestellt haben soll...

Kurzum, ich glaube ich muss die Datenbank inkl. aller inhalte auf UTF8 konvertieren richtig?
Wenn die Kodierung der Webseite UTF8 ist kann es eigentlich nur so sein.

Gibts dann eine für Angsthasen umsetzbare Variante?

Ich habe dort phpmyadmin.
Ich habe gesehen daß der amngepasste Export in UTF8 erfolgen kann.

Kann ich dann mit einem Texteditor einfach alle COLLATE latin1_german1_ci vorkommnisse gegen COLLATE utf8 austauschen, alle DEFAULT CHARSET=latin1 in DEFAULT CHARSET=utf8 und die gesammte Datenbank neu importieren oder stelle ich mir das zu einfach vor?

Oder ist das garnicht der Grund?

Lieber Gruß
Chris

[Matt]

Und um es vorweg zu nehmen, ich denke das es an der Datenbank liegt, die Ihrerseits nämlich latin1_german_ci tabellen beherbergt. (weitestgehend)

Eher durchgängig. Sonst würde es bei JOIN-Abfragen zu "Illegal mix of collations"-Fehlern kommen.

Das ganze befindet sich in einer InnoDB latin1_swedish_ci Datenbank.
Frag mich bitte keiner wann ich das so eingestellt haben soll...

Hast du nicht. MySQL kommt aus Schweden. latin1_swedish_ci war über viele Jahre der Default.

Kurzum, ich glaube ich muss die Datenbank inkl. aller inhalte auf UTF8 konvertieren richtig?

Nein. Ich hab ja seit gestern wieder nen Testshop und hab daher grad mal was probiert. Es gibt aber auch hier einen Wiki-Eintrag, allerdings bezieht der sich auf eine komplette Neuinstallation.

Ich habe gerade folgendes gemacht im Testshop (installiert mit latin1_german1_ci):
In der Tabelle languages language_charset auf UTF-8 geändert (dürfte bei dir schon erfolgt sein)
In includes/configure.php und admin/include/configure.php DB_SERVER_CHARSET (letzte Zeile) auf 'utf8' geändert

Ergebnis: http://möblr.de/

Diverse Änderungen aus dem Wiki-Eintrag sollte man aber trotzdem noch machen, u.a. die Language-Files auf UTF-8 umspeichern.

Was dann auch geht: Einfach die Domain mit Umlaut in die configure eintragen. Keine Klimmzüge mit idn_to_utf8() mehr. Nur eines ist wichtig: configure als UTF-8 speichern.

[Theoretiker]

Erstmal vielen Dank für den Support, ich freue mich sehr darüber.

Eher durchgängig. Sonst würde es bei JOIN-Abfragen zu "Illegal mix of collations"-Fehlern kommen.

9 von 88 Tabellen sind UTF8 im Gegensatz zu den 79 anderen Latin 1 Tabellen.
personal_offers_by_customers_status_0,1,2,3 (4); banktransfer, banktransfer_blz, (2), sessions, imagesliders, imagesliders_info (2).

Zusätzlich habe ich gerade gesehen daß ich auchnoch innerhlab der utf8 Tabellen einen MyIsam und INNODB Mix habe.

Nagut, also das ähndern in den Configure Dateien hat geholfen... mensch, ich habe sooft reingeschaut, aber nicht bis zum ende gescrollt bzw. im Hinterkopf gespeichert daß er bei der Datenbankkonfiguration ja auch die Charsetkonfiguration angibt.

Klasse!

Ich kann momentan nur ein einziges Problem erkennen. (Der große Test steht natürlich noch aus, ist noch WIP Status)
Der shopping_cart.php und configuration.php rufen nun die domain nich korrekt auf:

"Der Server unter www.dem%c3%bc-shop.de konnte nicht gefunden werden."

http://goo.gl/BXc9of
Einfach etwas in den Warenkorb legen.

Das Frontend als solches scheint aber zu funktionieren.

Hast Du noch eine Idee wo man den letzten Schalter umlegen könnte?

Vielen Dank für die Hilfe!

Schrägerweise steht die richtige und auch funktionierende URL in der Browserzeile.
Findet er also die domain nicht und ich bestätige die URL die oben im browser steht (mit ü)... dann lädt er die richtige Zielseite.

Lieber Gruß
Chris

[Matt]

Bei mir im Testshop funktionierts, bei dir kann ich es nicht testen, da ich bei jedem Klick eine neue Session-ID bekomme und daher nichts in den Warenkorb legen kann.