Jump to content
xt:Commerce Community Forum

mm.gross

Members
  • Content Count

    12
  • Joined

  • Last visited

  1. Hallo, ich habe eine eigene "Überschreibung" des xt-responsive Templates erstellt. Während der Arbeit daran sind nach dem Löschen des Caches plötzlich alle fontawesome icons verschwunden. Auch ein erneutes Löschen des Caches und neu generieren des CSS hat keine Abhilfe gebracht, nach genauerer Untersuchung des Problems fiel mir auf, das in der minifizierten CSS-Datei die URLs für die Fonts falsch sind: Mein font-awesome-import in der Template.less: @import "../../xt_responsive/components/fontawesome/less/font-awesome.less"; Die generierte Template.css enthält folgende URLs für die Fonts: @font-face { font-family: 'FontAwesome'; src: url('../../xt_responsive/components/fontawesome/fonts/fontawesome-webfont.eot?v=4.7.0'); src: url('../../xt_responsive/components/fontawesome/fonts/fontawesome-webfont.eot?#iefix&v=4.7.0') format('embedded-opentype'), url('../../xt_responsive/components/fontawesome/fonts/fontawesome-webfont.woff2?v=4.7.0') format('woff2'), url('../../xt_responsive/components/fontawesome/fonts/fontawesome-webfont.woff?v=4.7.0') format('woff'), url('../../xt_responsive/components/fontawesome/fonts/fontawesome-webfont.ttf?v=4.7.0') format('truetype'), url('../../xt_responsive/components/fontawesome/fonts/fontawesome-webfont.svg?v=4.7.0#fontawesomeregular') format('svg'); font-weight: normal; font-style: normal; } Das entspricht exakt den URLs, die die Template.css der "Standard-Übersschreibung" xt_resonsive_MEIN-SHOP enthält. Trotzdem wird daraus in der /cache/style_1xt_responsive_MEIN-SHOP_header.css korrekterweise: @font-face{font-family:'FontAwesome';src:url('/templates/xt_responsive/components/fontawesome/fonts/fontawesome-webfont.eot?v=4.7.0'); [...] während es in der entsprechenden Datei meines Templates so aussieht: @font-face{font-family:'FontAwesome';src:url('emplate/../xt_responsive/components/fontawesome/fonts/fontawesome-webfont.eot?v=4.7.0'); [...] Woran könnte das liegen bzw. was kann ich tun, um den Fehler zu beheben? xtCommerce Version: 6.2.2
  2. Hallo Forum, Shopversion: 4.1.10 Paypalplugin: 2.1.6 folgendes Problem: Bezahlt ein nicht registrierter Kunde per Paypal Express werden an Paypal keine Versandkosten übermittelt. Das kann ja auch nicht geschehen, da erst zu einem späteren Zeitpunkt (nämlich erst wenn die Lieferadresse bekannt ist) eine zuverlässige Versandkostenberechnung möglich ist. Das führt allerdings dazu, dass die Versandkosten erst im letzten Schritt der Bestellabwicklung angezeigt werden. So weit ich weiß, würden deutsche Gerichte die Versandkosten am liebsten schon fix im Warenkorb sehen, eine derart späte Anzeige der Versandkosten führt also zu einem erheblichen Abmahnrisiko. Hier im Forum gibt es einen etwas älteren Thread, der sich am Rande mit dem Thema beschäftigt, aber die Kernaussage lässt sich zusammenfassen als "Is halt so" http://www.xt-commerce.com/forum/fragen-zur-software/81316-paypal-express-versandkosten-und-brutto-netto.html Außerdem bietet Paypal die Instant Update API an, die eigentlich die Versandkosten während der Autorisierung aktualisieren sollte, das passiert aber (zumindest bei uns) nicht. Ist die im aktuellen Plugin (noch) nicht implementiert oder handelt es sich hier um einen Konfigurationsfehler unsererseits?
  3. Hallo, ich möchte mich nochmal in Erinnerung rufen. Gibt es hier denn niemanden, der das Gutschein-Modul einsetzt und mir diese Frage beantworten kann?
  4. Hallo, eine Kundin von mir möchte gerne ihren Kunden die Möglichkeit geben, Geschenkgutscheine zu kaufen. Uns ist allerdings nicht klar, ob xt_coupons die Möglichkeit bietet, Gutscheine direkt als Artikel anzulegen. Die einzige "Lösung" die ich gefunden habe, wäre die Gutscheincodes manuell (per phpmyadmin) als Seriennummer einzutragen (s. http://www.xt-commerce.com/forum/fragen-zur-software/82473-gutscheine-als-artikel-verkaufen.html ) Allerdings ist dieser Thread schon zweieinhalb Jahre alt und ich habe die Hoffnung, dass sich in der Zwischenzeit was getan hat und das nur noch nicht dokumentiert ist, da ich meine Kundin auf keinen Fall manuell in der Datenbank rumspielen lasse. Also, gibts da mittlerweile eine echte Lösung oder ist das im oben verlinkten Thread genannte Vorgehen weiterhin der Weisheit letzter Schluß?
  5. 1. Hattest du die installierten Plugins davor schon geöffnet? Veyton arbeitet mit Tabs und wenn du einen Tab geöffnet hast, dann wird der natürlich nur aktualisiert, wenn du das manuell veranlasst. 2. Manchmal passen nicht alle Plugins auf eine Seite, schau mal, ob die bei dir auf mehreren Seiten angezeigt werden. Wo du die Seriennummern eintragen musst, kann ich dir leider nicht sagen, da ich das selbst nicht nutze.
  6. Ich komm mir gerade saublöd vor, weil ich nicht mal im Ansatz auf die Idee kam, nach der Query im Code zu suchen, ich habe einfach angenommen, dass das sowieso verschlüsselt ist, etwas dämlich von mir. Danke oldbear, das ist ja echt super, da kann ich ja alles so anpassen wie ich es gerne hätte.
  7. Ich grabe nur ungern 2 Jahre alte Threads aus, aber das hier ist das hilfreichste und fast das aktuellste, was das Forum zu dem Thema zu bieten hat. Wir setzen aktuell 4.0.15 ein und da besteht das Problem immer noch: Wenn eine Kategorie gelöscht wird, werden alle Produkte darin mitgelöscht, egal ob das die Hauptkategorie dieser Produkte war, oder nur eine zusätzliche Kategorie. Hat sich da was getan, funktioniert das in der 4.0.16 besser? Denn eigentlich kann es ja nicht so schwer sein, das Popup mit dem Hinweis, dass alles gelöscht wird umzuwandeln in eine Abfrage, z.B. "Alle Artikel mitlöschen", "Artikel die ausschließlich in dieser Kategorie sind löschen" (Das bedeutet auch, dass Artikel, deren Hauptkategorie gelöscht wird erhalten blieben, wenn sie noch in einer anderen Kategorie sind), Abbrechen
  8. Hallo chrispeg, auch wenn dein Posting schon ne Weile her ist, vielleicht hilft meine Antwort ja trotzdem, entweder dir oder sonst jemandem mit dem gleichen Problem. Dein Problem hat meiner Meinung nach weder etwas mit dem CNAME-Eintrag noch mit der Datenbank zu tun. Ich bin mir nicht mal sicher ob es überhaupt was mit xt-commerce zu tun hat. Ich weiß leider nicht, wann das Problem bei mir zum ersten Mal auftrat, aber entdeckt habe ich es, nachdem ich mod_rewrite aktiviert hatte und plötzlich beim ersten Aufruf der Seite einen 404 bekam (danach lief alles eine Zeit lang wunderbar, nach ein paar Stunden warten kam wieder ein Fehler). Den "Müll" am Ende der URL hatte ich schnell entdeckt, mod_rewrite wieder deaktiviert und alles lief super (logisch, unsinnige Parameter werden ignoriert, da das Skript sie garnicht abfragt, aber mod_rewrite versucht was sinnvolles draus zu machen und scheitert grandios), bis auf die Tatsache, dass meine URLs hässlich waren und der "Müll" auch bei deaktiviertem mod_rewrite noch vorhanden. Bei jedem Seitenrefresh verschwand der Fehler jedoch. Die Ursache des Problems habe ich nie gefunden, aber nachdem mir wie bereits erwähnt auffiel, dass der Fehler bei einem Reload verschwand, war mein Workaround ganz einfach: mod_rewrite soll die URL auf den Fehler überprüfen und wenn er auftritt einfach nochmal laden, so sieht meine .htaccess aus: RewriteEngine on RewriteBase / RewriteCond %{REQUEST_URI} !^/media/ RewriteCond %{REQUEST_URI} !^/extAdmin/ RewriteCond %{REQUEST_URI} !^/skin/ RewriteCond %{REQUEST_URI} !^/js/ RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteCond %{REQUEST_FILENAME} !-l RewriteCond %{REQUEST_URI} !^x0717a RewriteRule .* index.php [L] Wie und warum das funktioniert, weiß ich nicht mehr, ich habe mich damals über mod_rewrite schlau gemacht, aber durch seltene Anwendung des erworbenen Wissens, verschwindet das auch wieder. Du müsstest lediglich eine Regel abändern, nämlich zu der folgenden RewriteCond %{REQUEST_URI} !^x51e70 und dein Fehler sollte verschwinden (naja, in Wirklichkeit verschwindet der Fehler nicht, er wird lediglich umgangen, wie gesagt: keine Lösung, nur ein Workaround)
  9. Hallo???? Vielleicht mal eine offizielle Antwort auf die Frage? Immerhin haben wir noch Geld bezahlt für den Shop, da kann man doch wenigstens ein Mindestmaß an Support erwarten.
  10. Wirklich niemand eine Idee, woran das liegen könnte?
  11. Hallo alle zusammen, ich bin da auf einen merkwürdigen Fehler gestoßen: mod_rewrite ist aktiviert, funktioniert auch im Großen und Ganzen, aber an den Details haperts etwas. Wenn ich meinen Browser neu starte und dann auf die Seite gehe (oder halt noch nicht auf der Seite war seit einer gewissen Zeit), dann stimmen beim ersten Aufruf die URLs nicht. D.h. sie stimmen schon, allerdings hängt an jedem vom Shop generierten Link noch etwas dran, nämlich folgendes: "?x55b02=37019d009fee0ea07f4dc9d3adb5e273" Der Teil vor dem "=" bleibt immer gleich, der Teil danach ändert sich jedes Mal, ich vermute dabei handelt es sich um die Session-ID. Das Problem an der ganzen Sache ist, dass dadurch der Klick auf jeden beliebigen Link zu einem Fehler 404 führt. Danach oder nach einem einfachen Reload der Startseite ist der Fehler weg und alles funktioniert einwandfrei. Wie werde ich diesen Fehler los? Die .htaccess sieht so aus: AddType x-mapp-php5 .php AddHandler x-mapp-php5 .php RewriteEngine on RewriteBase / RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
  12. Ich habe ein Problem mit meinen Slave-Artikeln: Sind höchstens 10 Slave-Artikel zu einem Master angelegt, funktioniert alles problemlos. Sobald mehr angelegt werden, wird keiner der Artikel also auch nicht die ersten 10, im listing angezeigt. Ein templatefehler kann ausgeschlossen werden, habe das auch mit dem Default-Template überprüft. Muss ich da noch irgendeine Einstellung vornehmen oder bin ich etwa auf einen Bug im ms-Plugin gestoßen?
×
×
  • Create New...