SvFricke

Warum 3.0.3? Ich verwende 3.0.5 und habe diese Probleme nicht.

Ich habe meinen Shop (lokal) von 5.1.4 auf 6.2.2 aktualisiert. Soweit alles problemlos. Templateanpassungen sind erledigt. Das einzige, was mir noch auffällt, ist eine unterschiedliche Behandlung der Versandkosten. Ich steuere das über ein gedachtes Produktgewicht. Deutschland ist versandkostenfrei. Im alten Shop wurde beim Checkout eines deutschen Kunden auch nur DE versandkostenfrei ausgegeben. Im neuen Shop hat der deutsche Kunde die Auswahl zwischen Versandkostenfrei und Versandkostenanteil EU. Im Versandpreis für EU ist DE enthalten mit Versand nicht erlaubt. Dies scheint nicht zu greifen, und die Option wird im Checkout mit angeboten. Hat jemand einen ähnlichen Fall und kann mit einem Tipp weiterhelfen?

Da der Kontakt-Spam in den letzten Tagen auch bei mir unangenehm zugenommen hat, habe ich das oben angegebene Plugin in meinem 5.1.4er auch mal installiert. Im Test funktioniert es gut. Mal sehen, ob die SPAM-Bots drauf reinfallen. Danke.

Eine Frage muss ich nochmal nachschieben. Ich möchte alle Produkte der Kategorie "1" mit Bestand >= "1" filtern. Das Ergebnisfeld von getArticles für products_categories ist ja ein Array(?). Wie muss ich das im json-Filtrer definieren. Wildcards funktionieren offenbar nicht. Sonst könnte ich anstatt products_categories auf products_model = A* abfragen. Kann ich die Ausgabe auch bereits in der Abfrage auf bestimmte Felder filtern?

OK - jetzt funktioniert es. Vielen Dank.

Das war es. Danke Jetzt kommt zumindest schon einmal eine Rückmeldung. (Was muss noch alles nach dem Upgrade gelöscht werden ? ) Die Meldung jetzt ist: {"result":false,"message":"Too few arguments to function getArticles"} Das json von oben auch mit "filter": [] bringt das Ergebnis. Muss ich nachher mal weiter probieren.

Der Zugriff erscheint in der Access.Log nur mit <POST /index.php?page=xt_api HTTP/1.1" 500 4875 "-" "-"> Server error log ist leer. Ich habe es jetzt mit Postman probiert. Danke für den Tipp. Der Request ist { "function": "getArticles", "paras": { "user": "meinUsername", "pass": "meinPasswort", "offset": "1", "blocksize": "10" } } Zu meiner lokalen Installation gibt es auch den Fehler 500 und in der PHP error Log steht: [22-Jan-2019 17:12:52 Europe/Berlin] PHP Fatal error: Cannot declare class nusoap_base, because the name is already in use in {lokalerPfad}\xtFramework\library\nusoap\nusoap.php on line 85

Hi, ich habe in meinem Shop 5.1.4 das PlugIn xt_api bereitgestellt und aktiviert. Ein entsprechender Benutzer wurde unter Einstellungen\Api angelegt. Jetzt möchte ich von einer externen Seite die Produkte abfragen. Bisher hat jeder Versuch einen Fehler 500 zurückgeliefert. curl_init aus meinem Test-php Skript liefert Code 2. Der Zugriffsversuch mit "Advanced Rest client" bringt nur den Fehler 500. Es müsste doch mit dem 5.1.4 funktionieren? Hat jemand Erfahrungen mit dem PlugIn und kann mit Tipps für einen Lösungsansatz mitteilen?

Als ich Probleme mit dem Sprachwechsel hatte, reichte ein Löschen des Template-Cache.

OK - egal - ich hatte nur aufgrund des Beitrags in meiner DB geprüft. Es ist dort 0. Bei der Neuinstallation XTC 6 wird die Tabelle mit CREATE TABLE `##_products_description` ( [snip] `reload_st` int(11) NOT NULL DEFAULT 0, [snip] angelegt.

Ist aber bei Neuinstallation auch "0".

Fehler 500 - Vielleicht findest du einen Hinweis auf den Fehler in der phperror.log oder der Web-Logdatei

Für einen Shop habe ich es so in meiner htaccess. Vielleicht kannst du daraus etwas für dich ableiten. RewriteCond %{HTTP_HOST} !^www\.domainname\.de$ [NC] RewriteRule ^(.*)$ https://www.domainname.de/$1 [L,R=301]

So - nochmal abschließend. Nachdem ich xtFramework lokal ersetzt habe und ich einige Versuche der Übertragung mit FileZilla hinter mir habe, habe ich jetzt auf dem Server noch einmal komplett gelöscht und aus meinem Editor die Dateien mit dem integrierten Transfer übertragen. Jetzt läuft alles wie es soll. Vielen Dank für die Unterstützung.

Danke für den Tipp! Die 2. Datei ist class.SQL_query.php im gleichen Verzeichnis. Jetzt kommt ein andere Fehler: Fatal error: Uncaught --> Smarty: Smarty->loadFilter() undefined method <-- thrown in /xxxxxx/verzeichnis/xtFramework/library/smarty/smarty-3.1.29/libs/sysplugins/smarty_internal_undefined.php on line 46 Bleibt denn nur, ein Update direkt auf dem Server durchzuführen? Hatte ich auch schon vor aber es scheiterte an der Lizenz-Datei. Zum Probieren hatte ich mir eine Demolizenz mit subdomain erstellt. Die gilt aber nur für 5er Shops und somit scheidet Update in der Subdomain quasi neben dem Liveshop aus. Schade, dass es hier keine Subdomain für development gibt. Localhost reicht ja hier nicht - wie man sieht. Hätte nicht gedacht, dass es hier so viele Fallen gibt, nachdem das Update lokal super funktionierte.