@Gambio, seit 2 Stunden hatte ich Probleme mich als Kunde an mein Shop anzumelden. Es hieß die weiterleitung wäre so konfiguriert, dass die Umleitung nie enden würde. Als Admin könnte ich mich anmelden und auch in den Adminbereich einlogen und ohne Probleme arbeiten, aber im Frontend könnte ich nichts anklicken, da die folgende Meldungen erschienen: IE 11 und FF meinten: Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Chrome meinte www.feinkost-kraeutlein.de hat Sie zu oft weitergeleitet. Löschen Sie Ihre Cookies. ERR_TOO_MANY_REDIRECTS Ich habe persönlich keine Änderungen im Adminbereich ausgeführt, außer ca. 60 Produkte aktualisiert. Nun habe ich die Shop Einstellungen -> SEO -> Gambio SEO Boost mal kontrolliert. Die Einstellung für "index.php Suffix in zugehörigen URLs entfernen" war angeschaltet. Ich weiß nicht ob sie vorher auch angeschaltet war aber wenn ich sie ausschalte, dann habe ich keine Probleme mehr. Ich habe heute nur die Daten von 60 Produkten aktualisiert und einen neuen Kunde angelegt! Kann es sein dass diese Einstellung sich von alleine angeschaltet hat?
Hast Du die Einstellung jetzt wieder an? Denn ich kann den Shop nicht aufrufen. Hast Du noch irgendwelche Umleitungen in der .htaccess?
Hallo Barbara, nein, ich habe die Einstellung ausgeschaltet. Ich habe in der Einstellungen des Shops überhaupt nichts geändert. Habe die Version: 3.5.2.0 Das problem ist, unter IE 11 muss man unbedingt "/index.php" eingeben sonst kommt eine Fehlermeldung.
Ich bin mit Chrome unterwegs, da ging auch nichts. mit /index.php geht es jetzt. Hast Du die neue .htaccess im Shop? ich habe das auch in den SEO-Einstellungen an und habe keine Probleme.
Ich arbeite schon seit eine Woche mit der Version 3.5.2.0. Bis heute keine Probleme. Bei der Update habe ich Die .htaccess Datei so getauscht wie beschrieben. Wo war die .htaccess Datei? Ich kann es nochmals versuchen.
gm/seo_boost_an Wenn das nicht helfen will, als zweiter Test: Klau dir die includes/application_top.php aus der 3.5.3.0 beta1, wirf die mal in deinen Shop, schau obs dann weg ist.
Kurze Frage: Hast du da eine serverseitige HTTPS Zwangsumleitung konfiguriert, wollte mir das gerade mal in der Browserkonsole ansehen, da sieht das so aus. Wenn ja schleunigst raus damit, sowas macht nie einen Gewinn aber ziemlich oft ziemlich viel Ärger.
ja habe ich. Aber schon seit ein Paar Jahren. Bis jetzt gab es nie Probleme. Ich habe es gerade ausgeschaltet. muss warten bis es ausgeführt ist.
Nachdem Till Tepelmann (Gambio) freundlicherweise alles analysiert hat, hat er Festgestellt, dass die Zeilen: Code: RewriteEngine on ##some Hosters like 1&1 need the following line to be enabled, else all the following will fail all the time RewriteBase / # ----------------------------------------------------------------------------- # Dynamically detect Rewritebase and URI part past Rewritebase # ----------------------------------------------------------------------------- RewriteCond %{REQUEST_URI}::$1 ^(.*?/)(.*)::\2$ RewriteRule ^(.*)$ - [E=SUFFIX:%2] RewriteCond %{REQUEST_URI}::$1 ^(.*?/)(.*)::\2$ RewriteRule ^(.*)$ - [E=BASE:%1] den Fehler verursachen. Der Herr Till Tepelmann (Gambio) hat genau diese Befehle deaktiviert, damit die Website wieder läuft. Was auch verständlich ist. Deshalb habe ich mich mit dem Hoster "Alfahosting" in Verbindung gesetzt. Das ist die Antwort was ich von Alfahosting bekommen habe: Nach so eine Freschheit habe ich mich entschieden den Hoster zu wechseln. Weil "die Ursache des Fehlers in Ihren Skripten kostenpflichtig zu analysieren" die Skripte von Gambio liefen am Anfang ohne Probleme und da Alfahosting zur Zeit ständig am Erweitern ist, hätte zumindest erst die eigene Änderungen kontrollieren müssen, wie die Programmierer von Gambio es immer tun. Da die Website eine Woche mit dem selben ".htaccess-Datei" ohne Probleme funktioniert hat, dann könnte der Fehler nur entweder durch Änderung der Umgebungsvariablen seitens des Hosters entstanden sein oder durch Nutzung eines Moduls im Shop. Um das auszufinden habe ich eine Vollversion GX3_v3.5.2.0 in eine Subdomain installiert. Es hat alles wunderbar funktioniert und egal was ich tat, lief alles ohne Probleme. Dann habe ich diese Gelegenheit zum Anlass genommen um mein Shop komplett auf die Version 3.5.2.0 umzustellen und alle alten Lasten (Templates -> gambio, EyeCandy, StyleEdit usw.) los zu werden. Auch die Daten der alten Datenbank habe ich selektiv in der neuen Datenbank der Version 3.5.2.0 rübergeholt. nachdem ich alles lokal in XAMPP getestet hatte, habe ich die Datenbank und die Daten auf meine Domain bei den Hoster hochgeladen. Enttäuscht habe ich erleben müssen, dass die selbe Fehlermeldungen wie Vorher erscheinen. Das kann aber nicht sein! Ich hatte alles genau so gemacht wie bei der Subdomain!? Es gab nur einen Unterschied zwischen Subdomain und Hauptdomain. Die Subdomain war wie erwartet ohne SSL. So habe ich die Funktionen der ".htaccess-Datei" wieder aktiviert und kleine Änderungen in den beiden "configure-Dateien" ausgeführt. Ich habe den Code: Code: define('ENABLE_SSL', true); // SSL: true = active, false = inactive und ... define('ENABLE_SSL_CATALOG', 'true'); // SSL: 'true' = active, 'false' = inactive geändert auf: Code: define('ENABLE_SSL', false); // SSL: true = active, false = inactive und define('ENABLE_SSL_CATALOG', 'false'); // SSL: 'true' = active, 'false' = inactive VOILA, seitdem funktioniert alles Perfekt! Die Website ist trotzdem SSL geschützt. Im Frontend sowohl wie im Backend läuft alles Perfekt ohne Probleme.
Da ist noch ne Macke in der htaccess Datei der 3.5.2.0/3.5.3.0 beta1, die wir nach Relase der Beta gefunden haben und die zur finalen Version korrigiert sein wird. Genauer: Das sind unnötige Zeilen Code, die rausfliegen werden, aber syntaktisch korrekt sind. Anders: Die tun nichts, darum fiel das vorher nicht auf. Lustig ist: Die verursachen scheinbar nirgends ein Problem, ausser bei Alfahosting, deswegen brauchst du eine andere SSL Konfiguration, als jeder andere, du "würgaroundst" dich da, Das Problem bei dir waren vorher aber noch 2 anderen Zeilen Code darin, und die sind korrekt, gehen bei Alfahosting aber trotzdem nicht. Mir/uns ist Alfahosting schon recht oft mit Fehlleistungen aufgefallen, ich hab da auch 2-3x angerufen um zu versuchen Dinge zu klären, dabei passierte wenig konstruktives. Die sind damit mit ganz oben auf meiner schwarzen Liste von nicht empfehlenswerten Hostern, wir empfehlen immer allen Kunden von dort wegzuwechseln.
Ein Würgaround ist ein Workaround, der keinen Schönheitspreis gewinnt. Estugo ist super, Publicompserver auch. Allinkl hört man auch immer wieder, unser Draht zu den ersten beiden ist aber viel kürzer, das endet meist in Vorteilen für Shopbetreiber.
Danke euch für euere Antworten. ich habe auch keinen Schönheitspreis erwartet. Macht mir aber spass um auszufinden wo der Fehler ist. welche sind dann die unnötige Zeilen?
Hallo Cyrus, Ich weiß ja nicht, ob du einen eigenen Server haben möchtest, oder nur ein Web-Paket. Wenn Du Lets Encrypt nutzt, oder nutzen möchtest, oder den MySQLDumper, dann ist Estugo nicht die beste Wahl. Da muss man das Zertifikat alle 3 Monate manuell eintragen und perl ist deaktiviert. Dafür hat Estugo SSD-Festplatten. Vom Support nehmen sich Estugo und All Inkl nicht viel.