Kritik erwünscht: Rewrite-Konzept

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Kritik erwünscht: Rewrite-Konzept

    Hallo zusammen,

    ist ja ganz schön leer hier da muss man doch mal was ändern
    ich bin seit einiger Zeit daran mir ein CMS und darauf ein Portal zu bauen und stehe jetzt vor der Entscheidung wie ich meine Links gestalte. Ich hab auch schon ein fertiges und so weit funktionierendes Konzept:

    http://[COLOR="Blue"]section[/COLOR].example.com/[COLOR="blue"]my/page/ident[/COLOR].[COLOR="blue"]language[/COLOR].htm
    bzw.
    http://[COLOR="Blue"]section[/COLOR].example.com/[COLOR="blue"]my/page/ident[/COLOR].[COLOR="blue"]language[/COLOR].htm-[COLOR="blue"]parameter=bla[/COLOR]
    Wobei ich das mit den Parametern nur Sicherheitshalber ermögliche, benutzt wird das derzeit nicht.

    Weiter habe ich ein Plugin-System im Aufbau das auch eine eigene (idr. sehr kleine) Navigation mit sich bringt. Und hier hab ich die größten bedenken bezüglich SEO. Unterseiten eines Plugins wären dann so verlinkt:

    http://[COLOR="Blue"]section[/COLOR].example.com/[COLOR="blue"]my/page/ident[/COLOR].[COLOR="blue"]language[/COLOR].htm/[COLOR="blue"]page/of/plugin[/COLOR]
    Und auch hier sind Sicherheitshalber Parameter gestattet (auch wenn sie vermutlich nie genutzt werden):
    http://[COLOR="Blue"]section[/COLOR].example.com/[COLOR="blue"]my/page/ident[/COLOR].[COLOR="blue"]language[/COLOR].htm-[COLOR="blue"]parameter=bla[/COLOR]/[COLOR="blue"]page/of/plugin[/COLOR]

    Um noch mal halbwegs realistische Beispiele zu nennen:
    Code:
    #1: http://development.example.com/news.htm (Seite mit zugeordnetem Plugin)
    
    #2: http://development.example.com/scripts.eng.htm-id=42/download (Seite mit zugeordnetem Plugin, Parameter und Unterseite)
    
    #3: http://gaming.example.com/tetris.htm/history (Seite mit zugeordnetem Plugin und Unterseite)
    
    #4: http://gaming.example.com/admin/user/edit.htm-id=42 ("Normale" Seite mit Parameter)
    Ich strebe natürlich links im Stil von #1 an, würde aber zugunsten der Plugins auch gerne Links im Stil von #3 akzeptieren. Links nach Beispiel #2 werde ich komplett vermeiden (wenn auch nicht ausschließen) und #4 eben ausschließlich im Admin-Bereich wo SEO ohnehin unrelevant ist.

    Für diejenigen die es Interessiert hier meine derzeitigen Rewrite-Rules:
    Code:
    # -----------------------------------------
    # Admin page redirects
    RewriteRule (^|^/)admin/?$ index.php?mode=admin&page=index
    
    # Admin page redirects (with parameters)
    RewriteRule (^|^/)(admin/[^\..]+)\.(.{3})\.html?(-(.*))?(/(.+)/?)?$ index.php?mode=admin&page=$2&lang=$3&plugin_page=$7&$5
    RewriteRule (^|^/)(admin/[^\..]+)\.html?(-(.*))?(/(.+)/?)?$ index.php?mode=admin&page=$2&plugin_page=$6&$4
    
    
    # -----------------------------------------
    # Ajax page redirects
    RewriteRule (^|^/)ajax/([^\..]+)\.(.{3})\.html?(-(.*))?(/(.+)/?)?$ index.php?mode=ajax&page=$2&lang=$3&plugin_page=$7&$5
    RewriteRule (^|^/)ajax/([^\..]+)\.html?(-(.*))?(/(.+)/?)?$ index.php?mode=ajax&page=$2&plugin_page=$6&$4
    
    
    # -----------------------------------------
    # Public page redirects
    RewriteRule ^/?$ index.php
    
    # Public page redirects (with parameters)
    RewriteRule (^|^/)([^\..]+)\.(.{3})\.html?(-(.*))?(/(.+)/?)?$ index.php?page=$2&lang=$3&plugin_page=$7&$5
    RewriteRule (^|^/)([^\..]+)\.html?(-(.*))?(/(.+)/?)?$ index.php?page=$2&plugin_page=$6&$4
    Für Verbesserungsvorschläge bin ich natürlich immer offen

    MfG
    Jens aka Forsaken
    Zuletzt geändert von Forsaken; 09.07.2010, 20:10.
    IM: Pidgin | Browser: Chromium Firefox | HTML: SelfHTML | PHP: PHP.net SelfPHP | Linux: GnomeDo



    And remember, respect is everything!

  • #2
    Ich würde mir an deiner Stelle mal anschauen, wie der Zend Router das macht.

    Kommentar


    • #3
      Ich strebe immer den Stil ohne Dateinamen an:

      http://example.com/lang/section/page/[COLOR="#aaa"]?param=value (nur wenn's nicht anders geht)[/COLOR]
      [COLOR="DarkSlateGray"]Hast du die [COLOR="DarkSlateGray"]Grundlagen zur Fehlersuche[/color] gelesen? Hast du Code-Tags benutzt?
      Hast du als URL oder Domain-Beispiele example.com, example.net oder example.org benutzt?
      Super, danke!
      [/COLOR]

      Kommentar


      • #4
        Zitat von AmicaNoctis Beitrag anzeigen
        Ich strebe immer den Stil ohne Dateinamen an:

        http://example.com/lang/section/page/[COLOR="#aaa"]?param=value (nur wenn's nicht anders geht)[/COLOR]
        Demnach hast du die Sprache (sofern mehrere vorhanden) immer in der URL? Ich denk wieder viel zu kompliziert ^^
        Die Sprache da irgendwie sauber rein zu bekommen ist nämlich im Moment mein größtest Problem. Als Subdomain will ich es nicht umsetzten (Cookies, Verwendung des CMS auf Subdomains).
        Das Plugin-Problem konnte ich inzwischen lösen.
        Zuletzt geändert von Forsaken; 09.07.2010, 21:20.
        IM: Pidgin | Browser: Chromium Firefox | HTML: SelfHTML | PHP: PHP.net SelfPHP | Linux: GnomeDo



        And remember, respect is everything!

        Kommentar


        • #5
          Zitat von Forsaken Beitrag anzeigen
          Demnach hast du die Sprache (sofern mehrere vorhanden) immer in der URL?
          Ja, gleich als erstes. Diese Variante wird von den meisten mehrsprachigen Websites benutzt. Der leere Pfad (http://example.com/) geht auf ein PHP-Script welches den Accept-Language-Header parst und auf die passendste verfügbare Sprachversion umleitet. Darüber hinaus gibt es dann trotzdem noch die Flaggen zum manuellen Umschalten.
          Zuletzt geändert von AmicaNoctis; 09.07.2010, 21:38.
          [COLOR="DarkSlateGray"]Hast du die [COLOR="DarkSlateGray"]Grundlagen zur Fehlersuche[/color] gelesen? Hast du Code-Tags benutzt?
          Hast du als URL oder Domain-Beispiele example.com, example.net oder example.org benutzt?
          Super, danke!
          [/COLOR]

          Kommentar


          • #6
            Wo ist denn das Problem dabei, wenn die Sprache in der URL steht?

            Kommentar


            • #7
              Zitat von h3ll Beitrag anzeigen
              Wo ist denn das Problem dabei, wenn die Sprache in der URL steht?
              Prinzipell hab ich da kein Problem mit, ich kann nur scheinbar bei den Temperaturen nicht mehr klar denken
              Wie gesagt ich hab mal wieder viel zu kompliziert gedacht.

              Und danke für den Tipp Amica
              IM: Pidgin | Browser: Chromium Firefox | HTML: SelfHTML | PHP: PHP.net SelfPHP | Linux: GnomeDo



              And remember, respect is everything!

              Kommentar


              • #8
                Persönliche Meinung, nicht wirklich SEO belegt oder nachgewisen;

                Ich finde immer, dass Dateinamen in der URL wie "http://example.com/de/index.php/test/blub/3" absolut hässlich sind.

                Erstens suggeriert eine Endung immer und bei jedem Benutzer, egal wie versiert er ist, dass es diese Datei in irgendeiner Form physikalisch gibt und sie auf dem Server existiert und zweitens ist es nicht benutzerfreundlich. Wenn schon SEO, dann richtig! Es gibt keinen nachvollziehbaren Fall, in dem eine URL mit einer Endung ".html" einer mit ".php" vorgezogen wurde, geschweigedenn einer ohne Endung überhaupt.

                Daher vermeide ich soetwas wo es nur geht und habe nur Endungen in den URLs, wenn es die Dateien tatsächlich gibt...
                This is what happens when an unstoppable force meets an immovable object.

                Kommentar


                • #9
                  Zitat von ApoY2k Beitrag anzeigen
                  Es gibt keinen nachvollziehbaren Fall, in dem eine URL mit einer Endung ".html" einer mit ".php" vorgezogen wurde, geschweigedenn einer ohne Endung überhaupt.
                  Das ist richtig, aber warum sollte man URLs andererseits mit Detailinformationen zumüllen, die weder für den Besucher noch für Suchmaschinen (sondern nur für potentielle Angreifer halbwegs) interessant sind?
                  [COLOR="DarkSlateGray"]Hast du die [COLOR="DarkSlateGray"]Grundlagen zur Fehlersuche[/color] gelesen? Hast du Code-Tags benutzt?
                  Hast du als URL oder Domain-Beispiele example.com, example.net oder example.org benutzt?
                  Super, danke!
                  [/COLOR]

                  Kommentar


                  • #10
                    Zitat von ApoY2k Beitrag anzeigen
                    Ich finde immer, dass Dateinamen in der URL wie "http://example.com/de/index.php/test/blub/3" absolut hässlich sind.
                    Das index.php lässt sich ja auf einfache Weise wegmachen. Außerdem kann man statt des nichtssagenden "index" auch eine sinnvollere Bezeichnung wählen.

                    Erstens suggeriert eine Endung immer und bei jedem Benutzer, egal wie versiert er ist, dass es diese Datei in irgendeiner Form physikalisch gibt und sie auf dem Server existiert ...
                    Dann häng halt noch ein ".html" an:
                    "http://example.com/de/kaeseblatt.php/Seite-3.html"
                    Ist für Menschen les- und merkbar.

                    ... und zweitens ist es nicht benutzerfreundlich. Wenn schon SEO, dann richtig! Es gibt keinen nachvollziehbaren Fall, in dem eine URL mit einer Endung ".html" einer mit ".php" vorgezogen wurde, geschweigedenn einer ohne Endung überhaupt.
                    Bei der Gestaltung einer vernünftigen URL-Struktur interessiert mich der Spanische Vogelschutzbund herzlich wenig. Und Suchmaschinen juckt das ebensowenig.

                    Zitat von AmicaNoctis Beitrag anzeigen
                    Das ist richtig, aber warum sollte man URLs andererseits mit Detailinformationen zumüllen, die weder für den Besucher noch für Suchmaschinen (sondern nur für potentielle Angreifer halbwegs) interessant sind?
                    Genau! Und deswegen mag ich keine Sprachenkürzel in Pfadangaben, es sei denn, sie sind Teil der Navigation (wie bspw. in einem Wörterbuch). Aber in welcher Sprache ich eine Web-Seite am liebsten serviert haben möchte, soll bitte der Webserver bei meinem Browser erfragen. Der käme sich sonst veräppelt vor, weil er bei jeder HTTP-Anfrage extra entsprechende Header mitschickt.
                    Zuletzt geändert von fireweasel; 18.07.2010, 22:28.
                    Klingon function calls do not have “parameters”‒they have “arguments”‒and they always win them!

                    Kommentar


                    • #11
                      Ich würde versuchen die Slashes zu minieren.. benutz einfach andere Trennzeichen (Unterstrich z.B.)

                      Kenne dein Projekt nicht, aber vllt solltest du generell mal die Struktur überdenken, das scheinen mir nämlich schon arg viele Paramter zu sein
                      PHP Forum
                      Sessions in PHP
                      Loginsystem mit PHP erstellen

                      Kommentar


                      • #12
                        Und deswegen mag ich keine Sprachenkürzel in Pfadangaben,
                        Was allerdings dazu führt, dass SUMAs evtl. nur eine Sprache finden, da sie selten Cookies unterstützen. Oder gar wechselnde Inhalte unter der Selben URL.

                        Ich sach nur: Problematisch!
                        Wir werden alle sterben

                        Kommentar


                        • #13
                          Ja - auch die Möglichkeit, gezielt Links auf andere Sprachversionen zu verschicken/bei Social Bookmarking-Diensten einzutragen etc. verschenkst du, wenn die Sprache nicht Bestandteil des URLs ist.
                          I don't believe in rebirth. Actually, I never did in my whole lives.

                          Kommentar


                          • #14
                            Zitat von combie Beitrag anzeigen
                            Was allerdings dazu führt, dass SUMAs evtl. nur eine Sprache finden, da sie selten Cookies unterstützen.
                            Wer sprach von Cookies? "Accept-Language" heißt der Header der Wahl ...

                            Oder gar wechselnde Inhalte unter der Selben URL.
                            Das verstehe ich jetzt nicht ...
                            Ich denke mal, dass ein Suchmaschinenrobot selten einen Accept-Language-Header mitschickt. Wenn doch, dann sollte die Suchmaschinendatenbank auch mit den dahintersteckenden Konzepten vertraut sein. Im Normalfall wird aber die Default-Seite ausgeliefert. Das dürfte wohl meist die in englischer Sprache sein. Das kann natürlich ein Problem für den Web-Seitenbetreiber darstellen. Deswegen schrob ich ja auch: ... deswegen MAG ICH keine Sprachenkürzel in Pfadangaben, es sei denn ...
                            Es wird sich nicht jeder nach mir richten, aber ich finde es in den meisten Fällen eine bessere Lösung, als auf irgendwelchen (oft unpassenden) Landesflaggen rumzuklicken ...

                            Ein Problem ist auch, dass die meisten Browser das Einstellen der Sprache kompliziert machen und die entsprechenden Konfigurationsdialoge gerne verstecken.

                            Zitat von wahsaga Beitrag anzeigen
                            Ja - auch die Möglichkeit, gezielt Links auf andere Sprachversionen zu verschicken ...
                            Das ist auch nicht nötig, wenn Browser und Server die Sprache aushandeln. Schicke ich den Link einer Person, die eine andere Sprache als ich spricht, wird diese die Web-Seite in ihrer gewünschten Sprache ansehen können.

                            ... /bei Social Bookmarking-Diensten einzutragen etc. ...
                            Wer braucht'n so'n Kram? Nee, im Ernst: Da gilt doch das Gleiche: Eine URL, und die Sprache wird bei deren Aufruf ausgehandelt.
                            Klingon function calls do not have “parameters”‒they have “arguments”‒and they always win them!

                            Kommentar


                            • #15
                              Zitat von fireweasel Beitrag anzeigen
                              Das ist auch nicht nötig, wenn Browser und Server die Sprache aushandeln. Schicke ich den Link einer Person, die eine andere Sprache als ich spricht, wird diese die Web-Seite in ihrer gewünschten Sprache ansehen können.
                              Du weißt selber, dass nicht immer alle Sprachversionen gleiche Qualität haben müssen - Paradebeispiel: PHP-Manual.


                              Sprachversion gehört für mich definitiv mit in die Adresse.
                              Besucher, die über die Indexseite einsteigen, kannst du ja trotzdem per Content Negotiation auf die am besten zur gemeldeten Vorliebe passenden Version weiterleiten.

                              Und für den Fall, dass explizit per Adresse angeforderte Sprachversion und Accept-Language nicht übereinstimmen, kann man auch gerne den Hinweis auf die anderen Sprachen noch mal gesondert hervorheben.
                              I don't believe in rebirth. Actually, I never did in my whole lives.

                              Kommentar

                              Lädt...
                              X