Hallo, ich hab mir schon vor längerer Zeit mal von Holger Schrörs einen parallelen Testshop einrichten lassen. Der spinnt aber jetzt (der Shop!), und ich weiß nicht warum. Er hat genau wie mein Echtshop 2.0.17 und hat früher gut funktioniert. Es fing schon damit an, dass er mich nicht reinließ und als Fehler einen Fehler im CMS-System behauptet hat. Barbara hat mir empfohlen, die .htaccess einfach rauszuschmeißen, danach kam ich rein. Wenn er an der DB2 hängt, die denselben Inhalt hat wie DB1 vom Echtshop, kann ich zwar auf die Admin-Startseite kommen, aber bei jedem Aufruf eines Links auf dieser Seite werde ich rausgeschmissen und soll mich neu einloggen, und dann immer so weiter. Wenn ich ihn an die DB3 dranhänge (selbstverständlich habe ich die vier config-Dateien geändert), die den ursprünglichen Inhalt hat, kriege ich gar niczhts zu sehen außer der Fehlermeldung WARNING(512): "SQL Error" in /var/www/vhosts/web31.norfolk.concept69.de/httpdocs/testshop/inc/xtc_db_error.inc.php:34 (Details) Backtrace: #0 trigger_error called at [/var/www/vhosts/web31.norfolk.concept69.de/httpdocs/testshop/inc/xtc_db_error.inc.php:34] #1 xtc_db_error called at [/var/www/vhosts/web31.norfolk.concept69.de/httpdocs/testshop/inc/xtc_db_query.inc.php:68] #2 xtc_db_query called at [/var/www/vhosts/web31.norfolk.concept69.de/httpdocs/testshop/includes/application_top.php:222] #3 include called at [/var/www/vhosts/web31.norfolk.concept69.de/httpdocs/testshop/index.php:27] Früher hat das alles gut funktioniert, und m.E. habe ich in der ganzen Zeit nichts verändert. Was will der bloß von mir? Liebe Grüße Marieluise
Hallo Marieluise, vielleicht ist da eine andere php Version eingestellt, mit der der Shop nichts anfangen kann.
Nee, das ist derselbe Server, unter derselben Domain, da kann nur eine php-Version für alles gelten. Das isses nich. Irgendwie hat das damit zu tun, dass er das Template nicht findet. Der Nächste bitte?!
Datenbankfehler. Nur lösbar mit der vollen SQL Fehlermeldung aus dem Log. Die sind nie am Bildschirm, da gibts aus Sicherheitsgründen nur einen Fingerzeig.
Aha. Danke für den Hinweis. Auf meinem Server hab ich heute gesehen, dass die DB3 keiner Domain zugeordnet war. Da man einer Domain höchstens 2 DB zuordnen kann, hab ich sie halt meiner absolut gleichberechtigten frafithe-Domain zugewiesen. Ich kriege dieselbe Fehlermeldung im Browser. In der error log sieht es anders aus. Die Log-Dateien geben Folgendes aus: Gestern: vor Entfernung der .htaccess: [Sat Jan 28 15:12:41.347662 2017] [authn_file:error] [pid 17113] (2)No such file or directory: [client 79.220.7.7:44356] AH01620: Could not open password file: /home/www/web31/html/testshop/.htpasswd [Sat Jan 28 15:26:49.160209 2017] [authn_file:error] [pid 7442] (2)No such file or directory: [client 79.220.7.7:45748] AH01620: Could not open password file: /home/www/web31/html/testshop/.htpasswd Ich HABE gar keine .htpasswd! Danach, auf DB 2 gerichtet, wo ich zwar reinkam, aber aus dem Admin-Menü dauernd rausgeschmissen wurde: [Sat Jan 28 16:30:39.532869 2017] [:error] [pid 25223] [client 79.220.7.7:50870] [client 79.220.7.7] ModSecurity: collections_remove_stale: Failed deleting collection (name "ip", key "41.100.88.104_b5c80922486cf267633d40bd3190f70ede4c144b"): Internal error [hostname "www.ohrsicht.de"] [uri "/shop/images/product_images/thumbnail_images/128_0.png"] [unique_id "WIy5HqtM7y9cAuMie4jdqwAAAA4"], referer: http://ohrsicht.de/shop/ Auf DB 3 gerichtet, wo ich die rosa Browser-Fehlermeldung kriegte: [Sat Jan 28 16:39:35.208305 2017] [auth_basic:error] [pid 12173] [client 79.220.7.7:42156] AH01618: user frafithe@gmail.com not found: /testshop (frafithe@gmail.com ist mein Username für den Echtshop) Heute (ich habe frafithe.de/testshop angesurft statt ohrsicht.de/testshop, was sonst nicht den geringsten Unterschied macht, Anbindung nach wie vor auf DB3): Auf einen einzigen Aufruf eine ganze Kaskade von error logs: [Sun Jan 29 16:46:01.711681 2017] [proxy_fcgi:error] [pid 16195] [client 79.220.7.7:45218] AH01071: Got error 'Primary script unknown\n' [Sun Jan 29 16:46:01.952446 2017] [proxy_fcgi:error] [pid 4032] [client 79.220.7.7:45226] AH01071: Got error 'Primary script unknown\n' [Sun Jan 29 16:46:18.389491 2017] [proxy_fcgi:error] [pid 28265] [client 82.208.44.79:46330] AH01071: Got error 'Primary script unknown\n' [Sun Jan 29 16:46:18.402755 2017] [proxy_fcgi:error] [pid 3991] [client 82.208.44.79:46332] AH01071: Got error 'Primary script unknown\n' [Sun Jan 29 16:46:18.416086 2017] [proxy_fcgi:error] [pid 28266] [client 82.208.44.79:46334] AH01071: Got error 'Primary script unknown\n' [Sun Jan 29 16:46:18.429450 2017] [proxy_fcgi:error] [pid 27211] [client 82.208.44.79:46336] AH01071: Got error 'Primary script unknown\n' [Sun Jan 29 16:46:18.444780 2017] [proxy_fcgi:error] [pid 3990] [client 82.208.44.79:46338] AH01071: Got error 'Primary script unknown\n' [Sun Jan 29 16:46:18.459688 2017] [proxy_fcgi:error] [pid 4946] [client 82.208.44.79:46342] AH01071: Got error 'Primary script unknown\n' [Sun Jan 29 16:46:18.482708 2017] [proxy_fcgi:error] [pid 15540] [client 82.208.44.79:46344] AH01071: Got error 'Primary script unknown\n' [Sun Jan 29 16:46:18.496330 2017] [proxy_fcgi:error] [pid 5017] [client 82.208.44.79:46346] AH01071: Got error 'Primary script unknown\n' [Sun Jan 29 16:46:18.510161 2017] [proxy_fcgi:error] [pid 4030] [client 82.208.44.79:46350] AH01071: Got error 'Primary script unknown\n' [Sun Jan 29 16:46:18.525455 2017] [proxy_fcgi:error] [pid 28222] [client 82.208.44.79:46352] AH01071: Got error 'Primary script unknown\n' Ich hoffe, das sind die benötigten Informationen. LG Marieluise
Genau weil du keine hast meckert der. Das ist ein perfektes Indiz, dass du in deiner htaccess Datei auf eine solche Datei verweist und führt zu "keiner kommt rein" Bei den restlichen Angaben blicke ich nicht durch, das sind aber Webserver Logs. Du brauchst das log des Shops (error.log aus logfiles Ordner), da steht drin was der Shop in der Datenbank für Probleme hat.
Du liebe Güte, was ich heute alles dazulerne! Ich hab den logfiles innerhalb des Shops noch nie Beachtung geschenkt. Denen des Webservers auch nicht, ehrlich gesagt, aber immerhin wusste ich, dass es sie gibt. Hier ist der ganze File von gestern und heute. Da sind anscheinend auch die fehlgeschlagenen Versuche drin, auf der Adminseite irgendwas aufzurufen. Damit ich hier nicht mit dem ellenlangen File den Thread so zumülle, hänge ich die Datei lieber dran ... Ich hab jetzt mal versuchsweise einfach die Zeile mit dem Passwort rausgenommen und die .htaccess wieder nutzbar gemacht. Komisch, in der htaccess, die Holger nach EInbringen seiner Module für den Echtshop geschrieben hat, steht nichts von dem, was hier in dieser vorkommt. Es wird auch nicht auf eine .htpasswd verwiesen; trotzdem wird danach gefragt. Da wir schon mal dabei sind: In meinem Webshop werde ich immer öfter nach dem Einloggen zu nochmaligem Einloggen aufgefordert, wenn ich auf Administrationsbereich klicke. Da reicht es dann immer, auf die Back-Taste zu drücken und noch mal den Administrationsbereich anzustreben. Es nervt trotzdem tierisch. Kann man die Ursache dieses Fehlers auch anhand dieser error-logs feststellen? Liebe Grüße Marieluise
Hast du teilweise SSL Verschlüsselung von Seiten aktiv oder noch schlimmer einen SSL-Proxy aktiviert? SSL Proxies sind diese Dinger, so sich die Domain beim betreten einer verschlüsselten Seite ändert. Das klingt nach Sessionverlusten und wäre typisch für diese Setups, das sollte man nicht mehr tun. Wenn dir das passiert, passiert das wahrscheinlich übrigens auch Kunden die in den Checkout wollen... Ansonsten sind da einige Krankheitem im Log, von SQL aber nur der hier: Code: Query: select configuration_key as cfgKey, configuration_value as cfgValue from configuration WHERE configuration_key != "CURRENT_TEMPLATE" Error: No database selected (error 1046) Die Datenbank die da in den configure Dateien stand war nicht anwesend.
SSL-Proxy habe ich nicht, aber natürlich ein SSL-Zertifikat. Aber das hat doch jeder Shop, oder? Was meinst du mit teilweise Verschlüsselung? Und das passiert ja auch nicht jedesmal und auch während ich eingeloggt bin, nie ein zweites Mal, wenn ich von der Homepage wieder in den Adminbereich will. Mir kommt aber gerade ein ganz anderer Verdacht; das will ich jetzt gleich mal ausprobieren. Ich glaube nicht, dass Kunden jemals nicht in den Checkout gekommen sind; das wüsste ich. Die beschweren sich sofort (meistens telefonisch), wenn irgendwas mit der Website mal nicht klappt. Ich hab ja schon eine besondere Art von Kundenstamm, die machen das. Das verstehe ich nicht. Ich habe in allen vier config-Dateien unter "define ('DB_DATABASE', 'usr ..." die richtige Datenbank eingetragen, hab's eben noch mal kontrolliert; wieso findet er die DB denn nicht? Liebe Grüße Marieluise P.S. Arbeitest du eigentlich auch am Sonntag 24 Stunden am Tag?
Unter uns, liest ja keiner: Ich arbeite mehr täglich, immer mal wieder Uns ist es wichtig, dass das Forum und unsere Kundschaft nie fies auf die Nase fällt, darum lugen wir immer mal wieder hier rein und schauen was so los ist. Wenn es irgendwo eine Katastrophe geben sollte, könnten wir dann das nötige tun um das schnellstmöglich abzustellen, das wäre im Interesse aller. Und wenn man schon mal schaut, kann man auch mal eben n Satz schreiben, wenn man denn mitreden kann. Klappt öfter mal
Hallo WIlken, mein Verdacht hat sich bestätigt. Ich hatte vor ungefähr einem Jahr eine besondere Startseite für eine von mir bevorzugte Buchhandlung gemacht, die bei mir wirklich unmäßig viel bestellt und dafür Sonderkonditionen kriegt. Weil das zu Fuß immer sehr mühsam war, hatte ich, da dort alle meine Titel bekannt sind und das Hin und Her mit den einzelnen Produktseiten dem Händler auch zu umständlich wäre, alle ca. 40 Titel geklont und als Link mit Warenkorbbutton auf die Startpage gestellt. Wenn ich mich als Admin in den Shop einlogge, sehe ich die normale UND diese Buchhandelsseite, und das waren wohl zu viele Daten. Und dieses Rausfliegen hatte ich seit einem Jahr immer mal wieder, also da gab es eine Koinzidenz. Ich habe gestern aus allen geklonten Artikeln die Bilder entfernt, d.h. die Startseite enthält nur noch die Kästchen mit den links. Heute habe ich mich mehrmals eingeloggt, ohne dass ich beim Ansteuern der Adminseite rausgeflogen bin. Das ist statistisch schon signifikant. Mal gespannt, ob das Problem jetzt endgültig weg ist. Liebe Grüße Marieluise
Ja, war auch nicht das Allheilmittel. Heute hat er es schon wieder getan! Vielleicht muss er immer noch zu viel hochladen.
Ich habe den starken Verdacht du suchst an der falschen Stelle, ohne aber zu wissen was dein Problem ist. Nur soviel: Mengen und solche Fehler passen nicht recht zusammen.
Du hast den Nagel auf den Kopf usw. Es wäre auch zu schön, wenn Koinzidenzen immer Gründe darstellen würden. Aber was soll ich machen? Das blinde Huhn sucht sein Körnchen an den unmöglichsten Stellen. Im error log tauchen diese Vorkommnisse übrigens nicht auf. Das System scheint im Einklang mit sich selber zu handeln. Das Verrückte ist ja, dass ich gar nicht wirklich rausgeschmissen werde. Ich krieg nur diesen Bildschirm gezeigt. Mit Backspace und nochmal Button komm ich ja sofort rein, und dann auch ganz richtig ohne Fiesematenten nach Adminshausen. Und während der Sitzung passiert es nie, immer nur am Anfang. Da war meine Idee doch gar nicht soo abwegig. Die vielen Bildchen tu ich trotzdem nicht wieder rein. Ich hatte deshalb auch schon mal ein Ticket aufgemacht, aber da kriegte ich nur zu lesen, auf euren Computern würde das nicht passieren. Ich kann mir aber nicht vorstellen, dass es vom Computer abhängt! Das wär ja noch schräger. Vielleicht kriege ich ja noch einen senkrechteren Einfall.
Also, ich brauche jetzt dringend einen Testshop. Den alten krieg ich trotz gefixter config-Dateien nicht zum Laufen. Holger hat auch wenig Zeit, den immer noch verborgenen Murks zu entdecken, den ich wohl mal damit verunstaltet habe. Was wäre die beste Methode: 1. Ich lade das gesamte Backup vom Life-Shop und seiner Datenbank in ein neues Parallelverzeichnis hoch und ändere in den vier config-Dateien Pfade und Datenbank? 2. Ich installiere GX 2.0.17 in ein neues Parallelverzeichnis und lade hinterher das Abbild meiner Live-Datenbank hoch? Das könnte aber daran scheitern, dass ich für 2.0.17 nur das Servicepack habe und nicht das ganze Softwarepaket. Das gibts hier nicht mehr als Download. 3. Ich schließe schlimmstenfalls meinen Live-Shop (wochenlang, wie ich mich kenne, weil am Layout total rumgebastelt werden muss und ich bei meinen ersten Versuchen mit StyleEdit 3 genau so wenig zurechtgekommen bin wie mit StyleEdit und CSS-Codes mich immer nur feindlich anstarren). Ich wurstele am Live-Shop rum, und wenn es nicht klappt, kann ich immer noch Restore machen und resignieren. 4. Ich schmeiße alles hin und verkaufe bei Ebay. Ihr seht, von 1 nach 4 wird es immer schlimmer. An 4 kann man den Grad meiner Verzweiflung ermessen. An 5, den Abräumer mit dem großen A, denke ich nur in meinen Albträumen. Liebe Grüße Marieluise
Du musst erstmal bereit sein alte Pfade zu verlassen, sonst wirst du verlieren. Erste Regel und nur wenn die gegeben ist lies weiter: 1. Lade die Dateien für eine frischen, neuen 3.3.2.0 Shop in einen leeren Pfad hoch. 2. Installiere diesen über den Installer, lösche danach das Installer Verzeichnis. 3. Besorg dir das Sammelupdate von 2.0.17 auf 3.3.2.0. Entpack es bei dir. Lad nur die Dateien aus gambio_updater/updates in dasselbe Verzeichnis des neuen Shops. 4. Leere die Datenbank des neuen Shops komplett, alle Tabellen, ganz weg. 5. Kopiere deine Datenbank des alten Shops in die leere Datenbank des neuen Shops. 6. Führe den Updater aus und aktualisiere so deine Datenbank. 7. Kopiere das Images Verzeichnis aus deinem alten Shop über das des neuen Shops Dann ansehen, und schauen wie es ist. Für alles was noch 2.0.x ist: Ende, jede Zeit die du investierst ist weitgehend vergebens. Dein Hoster wird dem alten Ding das Genick umdrehen. Kein Gambio Template im neuen mehr und schlauerweise auch kein Eyecandy, sonst biste absehbar wieder dabei und musst ran.
So einfach ist das? Viel, viel danke für deine verständliche Erklärung! Das Sammelupdate hatte ich schon vor ein paar Tagen entpackt und 3.3.2.0 stand vorher schon in den Startlöchern. Ich fange sofort damit an! Warum nach dem Hochladen der Datenbank Schritt Nr. 7 noch notwendig ist, ist mir ein Rätsel, aber ich mach's trotzdem. Herr Walser hat ja so recht.
Schritt 7 ist nötig, weil die Artikelbilder nicht in der Datenbank sind, sondern nur die Pfade. Kopierst du die eigentlichen Bilder nicht mit, fehlen die alle.