Karl Heinz: Parameter geht bei Weiterleitung verloren

Hallo,

für den Online-Shop www.fotoadvent.de habe ich eine Google AdWords Werbekampagne erstellt. Klickt jemand auf die Werbeanzeigen, so wird er auf www.fotoadvent.de verlinkt. Damit ich weiß das ein Besucher ausgehend von einem Klick auf eine AdWords-Anzeige gekauft hat wird der URL der sogenannte gclid-Parameter angehangen.

Hier weitere Infos zum gclid-Parameter:

https://support.google.com/analytics/answer/2938246?hl=de

Dummerweise erfolgt von www.fotoadvent.de eine Weiterleitung zu fotoadvent.de. Das führt dazu das der glicd-Parameter verloren geht. Aus diesem Grund funktioniert das Tracking nicht korrekt.

Ich könnte nun hergehen und die Werbeanzeigen statt auf www.fotoadvent.de auf fotoadvent.de verlinken.

Technisch würde mich allerdings interessieren ob ich irgendwas tun kann, damit der gclid-Parameter bei der Weiterleitung von www.fotoadvent.de zu fotoadvent.de nicht verloren geht?

Folgende Beiträge verweisen auf diesen Beitrag:

  1. Lieber Karl,

    ich hasse User-Tracking. Und ich hasse Werbung. Aber Deine technische Problembeschreibung verstehe ich und bilde mir ein, eine Lösung zu kennen.

    Technisch würde mich allerdings interessieren ob ich irgendwas tun kann, damit der gclid-Parameter bei der Weiterleitung von www.fotoadvent.de zu fotoadvent.de nicht verloren geht?

    Wenn Du die Weiterleitung mittels Apache-Direktive (mod_rewrite bzw. URL-Rewriting genannt) vornimmst, dann bedarf es lediglich eines Schalters. In Deiner .htaccess-Datei wirst Du wahrscheinlich etwas in dieser Art stehen haben:

    RewriteEngine on
    RewriteCond %{SERVER_NAME}  ^www\.
    RewriteRule .* http://fotoadvent.de%{REQUEST_URI} [R]
    

    Diese Weiterleitung vergibt zweierlei: Den Pfad (%{REQUEST_URI}) und ein Flag, das dem Browser mitteilt, dass diese Weiterleitung nicht nur unsichtbar intern, sondern für den Browser transparent durchzuführen ist ([R]), dieser de facto eine neue Adresse aufrufen soll, ohne diesen Schritt in der History zu dokumentieren (ein Schritt zurück führt dann nicht mehr zur www-Variante der Adresse).

    Wenn URL-Parameter angehängt bleiben sollen, dann muss man das in der Direktive mitteilen. Dafür gibt es das [QSA]-Flag, das "query string attached" bedeutet. Mehrere solcher Flags trennt man durch Kommata, sodass Du in obigem Beispiel nun folgendes stehen haben müsstest:

    RewriteEngine on
    RewriteCond %{SERVER_NAME}  ^www\.
    RewriteRule .* http://fotoadvent.de%{REQUEST_URI} [R,QSA]
    

    Nähere Informationen zu URL-Manipulationen auf einem Apache-Webserver findest Du in der dortigen Dokumentation: [Redirecting and Remapping with mod_rewrite]

    Liebe Grüße,

    Felix Riesterer.

    1. Hallo,

      vielen Dank für Deine ausführliche Rückmeldung. Leider verstehe ich die nachfolgenden Zeilen nicht so richtig, obwohl ich mich ein bisschen mit Apache und auch regulären Ausdrücken beschäftigt habe.

      RewriteEngine on 
      RewriteCond %{SERVER_NAME} ^www\. 
      RewriteRule .* http://fotoadvent.de%{REQUEST_URI} [R]
      

      Ich versuche die Zeilen mal so weit wie möglich in eigenen Worten zu erklären. Vielleicht kannst du meine Erklärung berichtigen bzw. ergänzen.

      Zunächst wird mit "RewriteEingine on" der Apache so konfiguriert, dass eine Umleitung überhaupt erst möglich ist.

      Im nächsten Schritt wird mit Hilfe von RewriteCond eine Bedingung festgelegt die eintreffen muss, damit die nächste Zeile (RewriteRule) überhaupt ausgeführt wird. Mit "^www." ist wohl gemeint, dass immer dann, wenn eine Seite mit www. beginnt die Bedingung erfüllt ist. Hier verstehe ich nicht was das %{SERVER_NAME} zu bedeuten hat. Des Weiteren habe ich gelesen, das RewriteCond zwei Argumente hat, ich frage mich wo hier das erste Argument ist und wo das zweite Argument?

      In der letzten Zeile wird schließlich die eigentliche Umleitung in die Wege geleitet. RewriteRule hat hierbei zwei Argumente. Das erste Argument stellt die URL dar die der Nutzer eingibt, das zweite Argument stellt die URL dar auf welche umgeleitet wird. Ich frage mich was in der dritten Zeile das erste Argument ist und welches das zweite Argument ist? Des Weiteren verstehe ich nicht was dieses % zu bedeuten hat?

      1. Mahlzeit,

        vielen Dank für Deine ausführliche Rückmeldung. Leider verstehe ich die nachfolgenden Zeilen nicht so richtig, ...

        das ist nicht schlimm, dagegen können wir etwas tun. Aber bitte tu allen Lesern den Gefallen, Code-Blöcke auch als solche zu markieren (Button </> oberhalb des Textfeldes), sonst entsteht ein Fließtext-Matsch daraus.

        RewriteEngine on 
        RewriteCond %{SERVER_NAME} ^www\. 
        RewriteRule .* http://fotoadvent.de%{REQUEST_URI} [R]
        

        Zunächst wird mit RewriteEingine on der Apache so konfiguriert, dass eine Umleitung überhaupt erst möglich ist.

        Ja.

        Im nächsten Schritt wird mit Hilfe von RewriteCond eine Bedingung festgelegt die eintreffen muss, damit die nächste Zeile (RewriteRule) überhaupt ausgeführt wird. Mit ^www. ist wohl gemeint, dass immer dann, wenn eine Zeite mit www. beginnt die Bedingung erfüllt ist.

        Ja. "Zeile" ist in diesem Fall der Hostname des Servers, der vom Browser angesprochen wird.

        Hier verstehe ich nicht was das %{SERVER_NAME} zu bedeuten hat.

        Diese Systemvariable enthält den Host- oder Servernamen, wie er vom Client kam (also z.B. "www.example.com").

        Des Weitern habe ich gelesen, das RewriteCond zwei Argument hat, ich frage mich wo hier das erste Argument ist und so das zweite Argument?

        Das erste Argument ist %{SERVER_NAME}, der Ausdruck, der untersucht werden soll; das zweite ist hier ^www., also ein regulärer Ausdruck, der auf das erste Argument passen soll, damit die Bedingung erfüllt ist.

        In der letzten Zeile wird schließlich die eigentliche Umleitung in die Wege geleitet. RewriteRule hat hierbei zwei Argumente.

        Eigentlich sogar drei, wenn du die Flags mitzählst.

        Das erste Argument stellt die URL dar die der Nutzer eingibt, das zweite Argument stellt die URL dar auf welche umgeleitet wird. Ich frage mich was in der dritten Zeile das erste Argument ist und welches das zweite Argument ist?

        Erstes Argument: .* (Regex für "ein beliebiges Zeichen, und das beliebig oft)
        Zweites Argument: http://fotoadvent.de%{REQUEST_URI} (Zieladresse der Weiterleitung)
        Drittes Argument: [R] (Redirect-Flag: nicht intern umleiten, sondern sichtbar)

        Des Weiteren verstehe ich nicht was dieses % zu bedeuten hat?

        Das ist die Apache-Notation für eine interne %{Systemvariable}.

        So long,
         Martin

        1. Hallo,

          obwohl Ihr mir prima erklärt habt wie die .htaccess Datei vom Grundprinzip her aufgebaut ist (Direktiven, reguläre Ausdrücke usw.) und obwohl ich mich eigenständig eine ganze Weile mit dem Thema beschäftigt habe sehe ich mich zum aktuellen Zeitpunkt nicht dazu in der Lage die nachfolgende .htaccess Datei so anzupassen, dass URL-Parameter auch nach der Umleitung erhalten bleiben. Das liegt primär daran, dass die Conditions und Rules mehrfach aufgerufen werden und ich nicht weiß wo genau ich welche Anpassungen machen muss. Es wäre prima, wenn Ihr mir hier behilflich sein könntet. Nachfolgend die .htaccess Datei:

          Achso an der Stelle noch eine anderen Frage:

          Mein Hoster ist allinkl, führt der diese Anpassung vielleicht für mich durch oder muss ich das definitiv selbst umsetzen?

          ############################################
          ## uncomment these lines for CGI mode
          ## make sure to specify the correct cgi php binary file name
          ## it might be /cgi-bin/php-cgi
          
          #    Action php5-cgi /cgi-bin/php5-cgi
          #    AddHandler php5-cgi .php
          
          ############################################
          ## GoDaddy specific options
          
          #   Options -MultiViews
          
          ## you might also need to add this line to php.ini
          ##     cgi.fix_pathinfo = 1
          ## if it still doesn't work, rename php.ini to php5.ini
          
          ############################################
          ## this line is specific for 1and1 hosting
          
              #AddType x-mapp-php5 .php
              #AddHandler x-mapp-php5 .php
          
          ############################################
          ## default index file
          
              DirectoryIndex index.php
          
          <IfModule mod_php5.c>
          
          ############################################
          ## adjust memory limit
          
          #    php_value memory_limit 64M
              php_value memory_limit 256M
              php_value max_execution_time 18000
          
          ############################################
          ## disable magic quotes for php request vars
          
              php_flag magic_quotes_gpc off
          
          ############################################
          ## disable automatic session start
          ## before autoload was initialized
          
              php_flag session.auto_start off
          
          ############################################
          ## enable resulting html compression
          
              #php_flag zlib.output_compression on
          
          ###########################################
          # disable user agent verification to not break multiple image upload
          
              php_flag suhosin.session.cryptua off
          
          ###########################################
          # turn off compatibility with PHP4 when dealing with objects
          
              php_flag zend.ze1_compatibility_mode Off
          
          </IfModule>
          
          <IfModule mod_security.c>
          ###########################################
          # disable POST processing to not break multiple image upload
          
              SecFilterEngine Off
              SecFilterScanPOST Off
          </IfModule>
          
          <IfModule mod_deflate.c>
          
          ############################################
          ## enable apache served files compression
          ## http://developer.yahoo.com/performance/rules.html#gzip
          
              # Insert filter on all content
              ###SetOutputFilter DEFLATE
              # Insert filter on selected content types only
              #AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript
          
              # Netscape 4.x has some problems...
              #BrowserMatch ^Mozilla/4 gzip-only-text/html
          
              # Netscape 4.06-4.08 have some more problems
              #BrowserMatch ^Mozilla/4\.0[678] no-gzip
          
              # MSIE masquerades as Netscape, but it is fine
              #BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
          
              # Don't compress images
              #SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary
          
              # Make sure proxies don't deliver the wrong content
              #Header append Vary User-Agent env=!dont-vary
          
          </IfModule>
          
          <IfModule mod_ssl.c>
          
          ############################################
          ## make HTTPS env vars available for CGI mode
          
              SSLOptions StdEnvVars
          
          </IfModule>
          
          <IfModule mod_rewrite.c>
          
          ############################################
          ## enable rewrites
          
              Options +FollowSymLinks
              RewriteEngine on
          
          ############################################
          ## you can put here your magento root folder
          ## path relative to web root
          
              #RewriteBase /magento/
          
          ############################################
          ## uncomment next line to enable light API calls processing
          
          #    RewriteRule ^api/([a-z][0-9a-z_]+)/?$ api.php?type=$1 [QSA,L]
          
          ############################################
          ## rewrite API2 calls to api.php (by now it is REST only)
          
              RewriteRule ^api/rest api.php?type=rest [QSA,L]
          
          ############################################
          ## workaround for HTTP authorization
          ## in CGI environment
          
              RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
          
          ############################################
          ## TRACE and TRACK HTTP methods disabled to prevent XSS attacks
          
              RewriteCond %{REQUEST_METHOD} ^TRAC[EK]
              RewriteRule .* - [L,R=405]
          
          ############################################
          ## redirect for mobile user agents
          
              #RewriteCond %{REQUEST_URI} !^/mobiledirectoryhere/.*$
              #RewriteCond %{HTTP_USER_AGENT} "android|blackberry|ipad|iphone|ipod|iemobile|opera mobile|palmos|webos|googlebot-mobile" [NC]
              #RewriteRule ^(.*)$ /mobiledirectoryhere/ [L,R=302]
          
          ############################################
          ## always send 404 on missing files in these folders
          
              RewriteCond %{REQUEST_URI} !^/(media|skin|js)/
          
          ############################################
          ## never rewrite for existing files, directories and links
          
              RewriteCond %{REQUEST_FILENAME} !-f
              RewriteCond %{REQUEST_FILENAME} !-d
              RewriteCond %{REQUEST_FILENAME} !-l
          
          ############################################
          ## rewrite everything else to index.php
          
              RewriteRule .* index.php [L]
          
          </IfModule>
          
          
          ############################################
          ## Prevent character encoding issues from server overrides
          ## If you still have problems, use the second line instead
          
              AddDefaultCharset Off
              #AddDefaultCharset UTF-8
          
          <IfModule mod_expires.c>
          
          ############################################
          ## Add default Expires header
          ## http://developer.yahoo.com/performance/rules.html#expires
          
              ExpiresDefault "access plus 1 year"
          
          </IfModule>
          
          ############################################
          ## By default allow all access
          
              Order allow,deny
              Allow from all
          
          ###########################################
          ## Deny access to release notes to prevent disclosure of the installed Magento version
          
              <Files RELEASE_NOTES.txt>
                  order allow,deny
                  deny from all
              </Files>
          
          ############################################
          ## If running in cluster environment, uncomment this
          ## http://developer.yahoo.com/performance/rules.html#etags
          
              #FileETag none
          
          
          

          Folgende Beiträge verweisen auf diesen Beitrag:

          1. Aloha ;)

            Achso an der Stelle noch eine anderen Frage:

            Mein Hoster ist allinkl, führt der diese Anpassung vielleicht für mich durch oder muss ich das definitiv selbst umsetzen?

            Das musst du letzten Endes deinen Hoster fragen - wir kennen weder ihn noch seine Bedingungen, und ein Blick in die Kristallkugel ist selten hilfreich.

            Was ich sehe, ist eine in irgendeiner Form vorkonfigurierte htaccess-Datei, und naiv würde ich davon ausgehen, dass dir am ehesten die Stelle helfen kann, die für die Vorkonfiguration verantwortlich zeichnet (da ich nach dem Gesagten nicht davon ausgehe, dass die Datei von dir zusammengeschrieben wurde).

            Als Hilfestellung zur Problemlösung versuche ich mal, die Datei ein wenig auf alles potenziell relevante (bezüglich rewrites und/oder GET-Parameter) zu filtern. Das erleichtert mir (und vielleicht auch anderen, die noch ein wenig mehr Ahnung haben), die Fehlersuche (und ist dank der ausführlichen Kommentare eigentlich auch kein Hexenwerk). Selbstverständlich sind auch die Zeilen, die schon im Original auskommentiert waren, für die Fehlersuche irrelevant...

            
            # [...]
            ############################################
            ## disable magic quotes for php request vars
            
                php_flag magic_quotes_gpc off
            
            # [...]
            
            <IfModule mod_rewrite.c>
            
            ############################################
            ## enable rewrites
            
                Options +FollowSymLinks
                RewriteEngine on
            
            # [auskommentiertes]
            
            ############################################
            ## rewrite API2 calls to api.php (by now it is REST only)
            
                RewriteRule ^api/rest api.php?type=rest [QSA,L]
            
            ############################################
            ## workaround for HTTP authorization
            ## in CGI environment
            
                RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
            
            ############################################
            ## TRACE and TRACK HTTP methods disabled to prevent XSS attacks
            
                RewriteCond %{REQUEST_METHOD} ^TRAC[EK]
                RewriteRule .* - [L,R=405]
            
            
            # [auskommentiertes]
            
            ############################################
            ## always send 404 on missing files in these folders
            
                RewriteCond %{REQUEST_URI} !^/(media|skin|js)/
            
            ############################################
            ## never rewrite for existing files, directories and links
            
                RewriteCond %{REQUEST_FILENAME} !-f
                RewriteCond %{REQUEST_FILENAME} !-d
                RewriteCond %{REQUEST_FILENAME} !-l
            
            ############################################
            ## rewrite everything else to index.php
            
                RewriteRule .* index.php [L]
            
            </IfModule>
            
            
            ############################################
            ## Prevent character encoding issues from server overrides
            ## If you still have problems, use the second line instead
            
                AddDefaultCharset Off
                #AddDefaultCharset UTF-8
            
            # [...]
            

            [Anmerkung: Verkrampfte Formatierung zwecks Bugreport extra so belassen, sollte trotzdem lesbar sein]

            Es wäre übrigens eine gute Idee, das schonmal selbst zu machen - verkürzt nämlich die Zeit, die sich andere damit befassen müssen, erheblich :P

            Prognose meinerseits:

            Das Problem könnte hier:

                RewriteRule .* index.php [L]
            

            begraben liegen, da hier keine Parameter an index.php angehängt werden. Aber auch die vielen Workarounds, die alle an .* angreifen und deren Sinn ich noch nicht verstehe, könnten problematisch sein.

            Grüße,

            RIDER

            --
            Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller Erreichbar manchmal im Self-TS (ts.selfhtml.org) oder sonst - wenn online - auf dem eigenen TeamSpeak-Server (fritz.campingrider.de) oder unter: # Facebook # Twitter # Steam # YouTube # Self-Wiki # ch:? rl:| br:> n4:? ie:% mo:| va:) js:) de:> zu:) fl:( ss:| ls:[
            1. Hallo,

              vielen Dank für deine Hilfe, so langsam fällt bei mir der Groschen :-).

              Muss man sowas eigentlich immer in der .htaccess anpassen oder kann es auch sein, das ich die Umleitung stattdessen im Backend des Shops konfigurieren kann?

              Falls es im Backend des Shops konfiguriert werden kann, bedeutet das dann, dass dann über die Einstellung im Backend des Shop die .htaccess-Datei verändert wird

              oder

              ist die Konfiguration der Umleitung per Shop-Backend dann unabhängig von der .htaccess Datei?

              Falls eine Umleitung sowohl im Shop-Backend als auch in der .htaccess Datei konfiguriert ist, was hat denn dann Priorität?

              1. Aloha ;)

                Muss man sowas eigentlich immer in der .htaccess anpassen oder kann es auch sein, das ich die Umleitung stattdessen im Backend des Shops konfigurieren kann?

                Falls es im Backend des Shops konfiguriert werden kann, bedeutet das dann, dass dann über die Einstellung im Backend des Shop die .htaccess-Datei verändert wird

                oder

                ist die Konfiguration der Umleitung per Shop-Backend dann unabhängig von der .htaccess Datei?

                Das kann man so nicht so einfach beantworten, das kommt auf die konkrete Umsetzung an. Primär gibt es zwei bis drei Möglichkeiten (die mir spontan einfallen, es gibt sicher noch mehr), eine Umleitung zu gestalten.

                Die hier angesprochene htaccess-Variante über mod_rewrite ist die, die intern im Server geschieht, der Benutzer bekommt hiervon nichts mit. Die Umleitung passiert hier in dem Moment, in dem der Server einen Request mit einem bestimmten URI bekommt, mod_rewrite sorgt dann dafür, dass intern im Server statt diesem URI ein ganz anderer (nämlich der durch die RewriteRule bestimmte) abgearbeitet wird, der Browser bekommt dann das Ergebnis. Neben mod_rewrite könnte das auf Servern potenziell auch anders umgesetzt sein. In einem vorgefertigten System könnte die "Umleitung" auch während der Bearbeitung der Anfrage durch den Server geschehen, z.B. indem andere php-Anweisungen durch den Server bearbeitet werden.

                Andere Umleitungen können clientseitig passieren, dabei bekommt der Browser beispielsweise auf einen bestimmten Request einen entsprechenden HTTP-Status (z.B. HTTP/1.1 301 Moved Permanently) mit entsprechender Angabe der Umleitungs-Location, der Browser lädt dann die dort angegebene Seite. Auch im HTML-Dokument können solche Angaben stehen und werden interpretiert, auch wenn kein entsprechender HTTP-Status mitgeliefert wird, und auch per JavaScript sind solche Umleitungen ereignisabhängig realisierbar. Charakteristisch für all diese Methoden ist, dass sich die URL im Browser bei der Umleitung für den User merklich ändert (bei serverseitig-internen Methoden geschieht eben das nicht).

                Das Shop-Backend kann in der Theorie beide Klassen von Umleitungen beeinflussen / konfigurieren. Was jetzt konkret in deinem Shop-Backend passiert kann ich dir per se nicht sagen, aber wie gesagt - clientseitige Umleitungen würdest du in der URL bemerken, du kannst das also wahrscheinlich selbst herausfinden.

                Falls eine Umleitung sowohl im Shop-Backend als auch in der .htaccess Datei konfiguriert ist, was hat denn dann Priorität?

                Das hat damit zu tun, wann in einem Request die jeweilige Umleitung geschieht. Von den oben genannten ist folgendes Ranking denkbar

                1. htaccess (Ausführung beim Eingehen des Request am Server)
                2. Interne, selbstgefrickelte Umleitung, z.B. in php (Ausführung während der Bearbeitung des Request am Server)
                3. HTTP-Statuscode (Ausführung beim Erhalt des header durch den Browser)
                4. HTML-Meta-Element (Ausführung nach Erhalt des Dokuments durch den Browser, während der Interpretation oder nach einer bestimmten Zeit)
                5. JavaScript (Ausführung nach Erhalt des Dokuments durch den Browser und nach Interpretation des Dokuments, nach Belieben, z.B. als Reaktion auf ein Ereignis)

                Grüße,

                RIDER

                --
                Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller Erreichbar manchmal im Self-TS (ts.selfhtml.org) oder sonst - wenn online - auf dem eigenen TeamSpeak-Server (fritz.campingrider.de) oder unter: # Facebook # Twitter # Steam # YouTube # Self-Wiki # ch:? rl:| br:> n4:? ie:% mo:| va:) js:) de:> zu:) fl:( ss:| ls:[