Ich habe keine entsprechende Warnung erhalten als Kunde und es kann wirklich nicht verlangt werden, dass die Kunden jeden Beitrag in irgendeinem Forum lesen, nur weil irgendein Problem mal auftreten könnte oder irgendwo aufgetreten ist. Wer die Zeit hat, hat halt zuviel Zeit. Ich z.B. habe jahrelang nicht in dieses Forum geschaut und hatte auch keinen Bedarf dafür. Ich sehe das Vorgehen als ungenügend an, jetzt eine Reparatur kostenpflichtig anzubieten für das hausgemachte Versäumnis. Wenn Sie das anders sehen, ist das halt so.
Ich habe jetzt auch ein Ticket ( 100623400 ) und bin nun auch im Club derer, die früher mal die Sprache englisch gelöscht haben. Außerdem kann ich keine Bestelldetailseite mehr ansehen, das steht auch im Ticket und ich hoffe, dass das nicht noch eine andere Baustelle ist. Nun hoffe ich dass ihr (die Gabioner :-D ) das Problem schnell lösen könnt. 49,- € sind da noch ein vertretbarer Preis - ich will da gar nicht feilschen ;-) Gruß Marcel
Ja bei uns leider auch, nach Update von v3.8.0.4 auf v3.10.0.1 . Sprachen wurden nicht deinstalliert, weitere wurden mal installiert. Klar ist 49 € vertretbar, aber dennoch kommt es zum Ärgernis und Shopausfall. Na gut, auch wir machen ein Ticket auf, bevor wir jetzt die ganze Datenbank checken müssen ;-
Du wirst ein anderes Problem als die meisten haben, habe ich dir im anderen Thread auch schon geschrieben, das übliche Problem mit Doppelposts im Forum. Deine Datenbank wird eher teilweise Reste enthalten und inkonsistent sein.
Hallo Wilken, bei meinem Kunden ist nichts inkonsistent, warum auch. Ich habe ja versucht es in kurzen Worten zu erklären, wie soll eine Inkonsistenz auftreten in nur einem Versionssprung von v3.8.0.4 auf v3.10.0.1. Da leuchten bei mir gleich die Alarmleuchten, da kann es nur ein anderes Problem geben (komme noch aus alten XT Zeiten von vor 20 Jahren bald, habe XT SprachId Probleme nicht das erste mal auf dem Tisch, hatte hier ja nur für meinen Kunden geschrieben - habe hier kein eigenes Login - so ja auch irgendwie leider nicht möglich) . Der Kunde hatte damals zuvor noch ein 304 System, irgendwann hat er dann Gambio den Export Auftrag gegeben den 304er zu Gambio zu portieren (ich glaube das erste GX3 war zu diesem Zeitpunkt gerade fertig bzw. in Arbeit). Der Kunde hatte im XT System 5 Sprachen installiert. Wenn man es genau nimmt hätte Gambio schon zu diesem Zeitpunkt beim Datenexport die SprachIDs korrigieren können wenn man es dann später so genau nimmt. Aber warum, denn es lief ja, und das bis heute (nehme ich Gambio auch keinesfalls übel, ich weiß ja wie das so läuft, kostet eben alles Zeit). Was ich aber nicht verstehe ist dass man so sehr darauf rumreitet (ebenfalls mit vielen Doppelposts wie ich so sehen konnte - und auch bei Suche nach "getCodeById") dass immer die Kunden "einen Fehler" gemacht haben oder "nicht verstehen" dass sie eine Sprache nicht löschen dürfen, wenn es denn so wichtig ist das unbedingt DE auf ID1 und EN auf ID2 liegen soll (und nun muss) dann hätte Gambio das schon zuvor abfangen und klarer darstellen müssen. Letzen Endes aber muss es egal sein auf welcher ID eine Sprache liegt, man liest halt den Sprachcode aus und erhält die ID und gut. Vielleicht hat es ja auch noch einen anderen aktuelleren Grund den ich jetzt noch nicht sehe im alten XT war das so aber definitiv der Fall, und am DB- Sprachkonstrukt hat sich ja nichts geändert. Mich wunderte auch das sich da nichtmal jemand kurz ne Stunde oder zwei ransetzt um da ein kleines fix etc. hier zu posten (oder nach einem gefixten Shop das Bsp. posten, konnte sehen dass hier irgendwer nach Rat fragte aber keinen bekam, er soll ein Ticket aufmachen). Ein Ticket habe ich auch aufmachen wollen , Antwort: .... Auf Grund der derzeitigen Auftragslage kann zudem keine kurzfristige Angebotserstellung und Ausführung des Auftrags erfolgen. .... Kann selbstverständlich verstehen wenn viel zu tun ist, aber das kann man Kunden die ernshaft eCommerce betreiben nicht so zumuten, da hat schon ein kleines Fix, oder die Kunden mal auf die richtige Spur zu lotsen hohe Wichtigkeit, denn diese leben davon und können nichtmal eben den Shop 1-2 Wochen ausschalten. Klar machen wir Backups /Shadows etc., aber wie schon erwähnt das Ärgernis ist ja erstmal da, ich war schon etwas überrascht. Und das auch nur weil ich die jahrelange gute Arbeit von Gambio zu schätzen weiß, denn man muss ja klar zugestehen dass es in den letzten Jahren wenig Probleme bei Updates gab und das ist wichtig. Also, der Fehler kommt wie die Meldung auch schon aussagt aus der /GXMainComponents/Shared/LanguageProvider.inc.php . Mal kurz genauer hingeschaut liefert ein Aufruf in den Admin an die getCodeById() wahrscheinlich über Werte aus dem globalen meta array den Klassen Datentyp "IdType $id" plötzlich eine 1 . Ich habe schon nachgesehen, habe heute Nacht aber keine Lust und Zeit mehr da weiterzusuchen woher der Aufruf genau stammt, wichtig ist was er sendet und das ist plötzlich eine 1 (DE), die aktive SprachID mit der der Shopadmin gestartet wird. Fakt ist unsere languages table wurde nicht geändert (das habe ich mit den Versionen bis 3.8 verglichen), und da DE bei uns bei 2 anfängt und Spanisch bei 6 endet kam mir das schon "spanisch" vor ;- Irgendwie hatte ich hier irgendwo überflogen das du bei v3.7 ca. mitteiltest dass man am SprachID Problem bei gelöschten Sprachen was machen möchte, vielleicht war das ja die Lösung ;- Naja kleiner Spass, jedenfalls kommt der Fehler aus den neuen Dateien und nicht von uns. Habe es jetzt aber erstmal mit einem kleinen Schnipsel LanguageProvider angepasst, Vielleicht hilft es ja noch dem einen oder anderen (dann die $firstId und $lastId anpassen, die bekommt man aus der languages Tabelle). Code: public function getCodeById(IdType $id) { // *** $firstId=2; $lastId=6; $idl=strval($id); $idl=intval($idl); if ($idl<=$firstId) $idl=$firstId; else if ($idl>=$lastId) $idl=$lastId; else $idl+=1; $id=new IdType($idl); // *** // Database query. $this->db->select('code')->from('languages')->where('languages_id', $id->asInt()); Der Shop läuft zum Übergang erstmal wieder (hatte den alten Shop ja bereits zurückgestellt), kann noch keinen Fehler entdecken. Die getCodeById() wird wohl auch sauber global (front und backend) verwendet, was natürlich Voraussetzung ist. Sollte da was anderes bekannt sein wäre ne Info nett. Da ich wohl ca zwei Stunden benötigen würde die lang IDs der ca. 20 tables in der DB in Reihenfolge zu stellen, stellen wir uns dann wohl hinten an ;-
Auch wenn die letzte Meldung im Ticket schon etwas her ist noch ein paar ergänzende Infos: In einem recht alten und vielfach aktualisierten Shop hatten wir das gleiche Problem. Die genaue Fehlermeldung war folgende: Code: PHP Fatal error: Uncaught UnexpectedValueException: No language code has been found in /htdocs/GXMainComponents/Shared/LanguageProvider.inc.php:189 Stack trace: #0 /htdocs/GXMainComponents/Services/Core/Manufacturer/Repositories/ManufacturerRepository.inc.php(123): LanguageProvider->getCodeById(Object(IdType)) #1 /htdocs/GXMainComponents/Services/Core/Manufacturer/ManufacturerReadService.inc.php(72): ManufacturerRepository->getById(Object(IdType)) #2 /htdocs/system/classes/products/ProductInfoContentView.inc.php(569): ManufacturerReadService->getById(Object(IdType)) #3 /htdocs/system/classes/products/ProductInfoContentView.inc.php(104): ProductInfoContentView->_assignRichSnippetData() #4 /htdocs/system/classes/products/ProductInfoContentView.inc.php(138): ProductInfoContentView->prepare_data() #5 /htdocs/product_info.php(101): ProductInfoContentView->get_html() #6 {main} Die Fehlermeldung lies sich ebenfalls auf obiges Codestück im Bereich "Manufactures" eingrenzen. Es scheint so dass sich in den Updates oder durch andere Einflüsse die verwendeten Language-IDs mal geändert haben und nicht mehr überall zusammen passen. Kurz nachgeschaut (Tabelle languages) welche verwendet werden: 1 = en 2 = de Schauen wir mal in die manufactures bzw. deren Verknüpfungstabelle manufactures_info Dort wurden nur ID=0 genutzt - kann ja nicht passen. Da wir keine Einstellungen vornehmen (wir importieren und erzeugen damit auch die Daten dort) war es ein leichtes die Vorhandenen Daten zu "duplizieren" (mit ID=2, geht leicht per Export, Suchen & Ersetzen im Editor und wieder Import) und erneuten DB-Update der vorhandenen ID=0 auf 1. Siehe da - schon war die Fehlermeldung verschwunden und alles lief normal! Falls ihr gerne mal über die Tabelle suchen möchtet wo sich alles language-Felder finden dann geht das am einfachsten übers DB-Schema folgendermaßen: Code: SELECT * FROM `INFORMATION_SCHEMA`.`COLUMNS` WHERE `TABLE_SCHEMA`='<eure-gambio-db-hier-eintragen>' AND `COLUMN_NAME` LIKE '%language%' ORDER BY TABLE_NAME; In der aktuellen Shopversion gibt es also 57 Vorkommen - nicht wenig wenn die Sprache wirklich gelöscht wurde. Daher sind die Aufwände mehr als berechtigt. Dennoch die Warnung - wenn ihr nicht wisst was ihr tut, lasst die Finger davon und greift lieber auf das wirklich günstige Angebot zurück euch die Probleme von den Gambio-Leuten reparieren zu lassen!
Wie ich merke, waren die letzten Monate viele betroffen von diesem Problem. Schließe mich der obigen Kritik gegenüber dem Gambio-Team an, hier die Kopie meiner Antwort an das Gambio-Team: Hallo Herr ..., unser Shop arbeitet schon seit Jahren nur in der deutschen Sprache und auch unser Versand beschränkt sich nur auf Deutschland. Es ist also höchst unwahrscheinlich, dass irgendwelche Standardsprachen gelöscht wurden. Der Shop lief die letzten Jahre bis zum jetzigen kostenpflichtigen Update ohne Probleme und auch das Einloggen von weiteren Benutzern klappte. Nun haben wir 150 Euro für ein Jahr mit Update und Support bezahlt und auf einmal läuft das Shopsystem nach diesem Update nicht mehr, Sie unterstellen mir irgendwelche Löschungen und wollen jetzt noch weiteres Geld für einen speziellen Support erhalten. Ich finde das sehr inkompetent und eigentlich schon hinterhältig. Ich werde mich diese Woche hinsetzen und versuchen, den Fehler in Ihrem Shopsystem selbst zu suchen und zu beheben... ...und werde wahrscheinlich auch diesen Zusatz-Support anmelden müssen, frustiert,..
Der Shop wird, solange es die Firma gibt und ohne dass es zwischendrin mal einen Unfall durch ein fehlerhaftes Update oder ähnliches gegeben hat mit englischer und deutscher Sprache ausgeliefert. Fehlt eine der beiden, berufen wir uns ohne wenn und aber auf eine Löschung durch den Nutzer. Von dieser Devise werden wir keinen cm abweichen, in keinem Fall. Ausnahme: Sollte durch einen jetzigen oder ehemaligen Gambio Mitarbeiter die Löschung einer Sprache vorgeschlagen worden sein oder durchgeführt worden sein, irgendwann in all den Jahren, dann wäre das ein Fehler unsererseits. Es genügt dann sich bei uns zu melden und ein Exzerpt der Nachricht durchzugeben, wir können bei uns alle Kommunikation der Jahre wieder heraussuchen und das eben checken. Das wäre dann eine Begründung für einen Kulanzfall ohne Berechnung, dann ginge eine Reparatur unfraglich auf unsere Kappe. Bei allen anderen reparieren wir das, trotz gesichertem Eigenverschulden des Kunden, zum Sonderpreis. Den haben wir als entgegenkommen und Akt der Diplomatie schon vor einer Weile von jahrelang gültigen 100 Euro auf 50 Euro gesenkt. Damit wird keiner hier reich, aber es reicht meistens den Aufwand der bearbeitenden Personen abzudecken. Dazu gehören Auftragsmanagement, Backup, eine Analyse der Datenbank, die Überlegung von individuell für den Shop sinnvollen Massnahmen, gezielte Korrekturen am jeweiligen Objekt und dann noch kommende Nachbearbeitung, wie die Beantwortung kommender Rückfragen.
Wenn es ganz am Anfang mal ein Button gab, welches dem Shopbetreiber anbot, eine Sprache zu löschen, die er nicht braucht, dann muss der Betreiber auch später wieder ein Buttun anbieten, eine Sprache zu installieren, wenn sie für den Betrieb notwendig ist, Alles andere ist fehlende Kompetenz des Betreibers. Trotzdem danke für die Antwort.
Der Fehler ist laut diesem Thread nun seit über einem Jahr bekannt. Dennoch gibt es weiterhin weder im automatischen Updateprozess eine Überprüfung, noch eine simple Warnung in der Installationsanleitung. Und darum: Die Mitarbeiter sind von den Bestellungen abgeschnitten, Ticket #100740870.