nicht angemeldet
Hi,
vielen Dank für deine Antwort. Es erfreut mich ja immer, wenn ich als Laie eine Idee/ ein Konzept habe, welches die Zustimmung eines Experten findet. :-)
Von daher, nachdem dieser Teil soweit klar ist vom Grundsatz her, hätte ich noch ein paar (speziellere) Fragen dazu.
Auch in Punkto "Sonderzeichen" kann man da die Einstellung in baldiger Zukunft mal dem aktuellen Stand anpassen - wenn auch der IE mal nachzieht. Meine Gedanken dazu legte ich letztlich schon mal dar. Dass "Umlautdomains" möglich sind, bei denen auch ein ä im Domainpart in der Adresszeile korrekt dargestellt wird, ich statt eines solchen im Path- oder Query-String-Bestandteil des URL aber immer noch ein ae dafür schreiben soll, ist nicht mehr state-of-the-art.
Den verlinkten Beitrag, sowie dedlfixs Artikel "Kontextwechsel" habe ich mir jetzt schon zigfach durchgelesen, bin aber immer noch nicht schlau, bzw. mir der Sache sicher (Frage folgt weiter unten).
Intern würde ich es so handhaben, dass es egal ist, wie es geschrieben ist, d.h. solange der Text unabhängig von Klein- oder Großschreibung matched, wird die Seite gefunden und ggf. (wegen der Kanonizität) auf die entsprechende Schreibweise redirected.
So werde ich das künftig auch halten.
Wenn die Daten nicht über allzu aufwegige Queries ermittelt werden, dann prüfe ich nicht vorher extra die Schreibweise explizit hinsichtlich korrekter Gross-/Kleinschreibung - sondern lasse mir beim Auslesen von der Datenbank einen Boole'schen Wert mit ermitteln, der angibt, ob die Schreibweise diesbezüglich korrekt war. Wenn ja, dann habe ich direkt meine Daten zum anzeigen; wenn nein, dann leite ich noch mal um.
Ja, so ähnlich zumindest will ich es auch machen. Ich prüfe zuerst auf "Kriterien", die ich automatisch korrigieren will (trailing slash etc.) um ggf. direkt per 301 zu redirecten. Danach prüfe ich, ob die angegebene URL existiert. Falls nicht, binde ich eine weitere Prüfung ein, die ggf. "errät" welche URL gemeint war und diese (ggf. auch mehrere) dann vorschlägt. Diese Seite liefere ich dann mit einem 404er aus.
Da ich nicht unbedingt in der Lage bin, alle Eventualitäten im Vorfeld schon hinreichend zu berücksichtigen, gibt es da noch einige Punkte, wo ich nicht genau weiß, wie ich damit verfahren soll.
Meine bisherige Planung bezüglich des URL-Designs sieht eigentlich recht simpel aus. Normale Seiten (also überwiegend die reinen Artikel-Seiten) sind direkt über eine "sprechende" URL auf dem Root-Level erreichbar.
Also bspw.: http://example.com/Mein-neuester-Artikel
Ferner wollte ich das Media Wiki Namespace System übernehmen. Also bspw. soll eine Übersichtsseite mit allen Artikeln zu einem "Tag" dann so erreichbar sein:
http://example.com/Tag:CSS
Etwas unsicherer bin ich mir schon bei der Suche. Ich dachte bisher an etwas wie:
Suchseite: http://example.com/Search:
Ergebnisseite: http://example.com/Search(result?):CSS+HTML+Usability
Wie man bereits jetzt schon feststellen kann, schwanke ich auch noch zwischen englischen und deutschen Bezeichnungen. Einerseits werde ich die Seite, erstmal zumindest, nur auf Deutsch erstellen, andererseits sind viele der gängigen Begriffe & Formulierungen im Webpublishing nunmal Englisch. Zumal sie meist auch noch deutlich kürzer sind und keine Umlaute enthalten (gut - bei den folgenden Beispielen trifft das eh alles nicht zu, aber man weiß ja nicht, was noch alles kommen kann):
Tag <-> Thema(?) oder Schlagwort (?)
Search <-> Suche
Searchresult <-> Suchergebnis
Mal abgesehen von den FOrmulierungen, sollte ich evt. am besten doch direkt ein Konzept wählen, dass eine spätere Mehrsprachigkeit möglichst einfach ermöglicht? Ich habe die fragliche Domain aber eh bereits unter den folgenden TLDs registriert: de, eu und info (com war leider schon besetzt). So könnte ich ja später einfach eine Englisch sprachige Version unter eu oder info anbieten. Bisher leiten diese Domains auf die de weiter.
Ein weiterer Punkt, der mir Kopfzerbrechen bereitet, ist die Sache mit dem Query String. Was mir sehr plausibel erscheint ist, dass es keine schlechte Idee ist, einen vorhandenen QS auf die enthaltenen Variablen zu prüfen und nur die durchzulassen, die als "erlaubt" hinterlegt sind. Auch könnte man darauf achten, dass bspw. nur die benötigten Variablen, d.h. die mit einem Wert, und stets in gleicher Reihenfolge sortiert im QS vorkommen.
Frage: Lohnt sich der Aufwand? Einfachere Möglichkeit?
Bisher weiß ich noch gar nicht, ob ich überhaupt eine Seite haben werde, die per GET Daten versendet.
Andererseits könnte man so bspw. aber auch häufig vorkommende Suchanfragen cachen (vorausgesetzt natürlich, die Suchbegriffe und -kriterien sind exakt gleich).
Und dann ist da noch das leidige Thema mit der "Besucher-Identifizierung/ -wiedererkennung". Denn ich würde dem User bspw. verschiedene Layouts (zumindest 2) anbieten wollen. Blöd nur, wenn der dann keine Kekse akzeptiert. Dann hätte ich in jedem Request die schei.. Session-ID. Oder gibt es für dieses Problem noch eine andere Lösung? Oder soll ich diesen Usern dann mitteilen, dass Cookies zwingend erforderlich sind für diese "Komfort-Funktion"?
Jetzt nochmal kurz zurück zu dem Thema "Kontextwechsel erkennen und behandeln".
Wenn ich den Request in meinem PHP-Script verarbeite, muss ich dann auch irgendetwas de-/codieren, oder kann ich einen evt. vorhandenen QS einfach so "abschneiden" und wieder "anhängen"? Und wie sieht es im Bezug auf evt, Prüfungen seitens z.B. str(i)pos oder preg_xxx aus?
Ich arbeite UTF-8 codiert und gebe auch meine Seiten so aus (also serverseitig so konfiguriert).
Dieses Thema treibt mich noch in den Wahnsinn! ;-)
Einerseits soll ja alles richtig funktionieren und korrekt ausgegeben werden, andererseits will ich aber ja auch keine (unnötigen) Kodier-Orgien veranstalten.
Es wäre wirklich sehr nett, wenn du/ ihr mir hier nochmal weiterhelfen könntet - danke!
Gruß Gunther
suit
Der Martin