Jump to content

Daresh

Members
  • Posts

    2,596
  • Joined

  • Last visited

  • Days Won

    24

Everything posted by Daresh

  1. Dzięki za info, cieszę się że się udało, ciekawe czy klienci poradzą sobie z określeniem który paczkomat ma pobranie. Tymczasem zaktualizowałem moduł w głównym poście o zmiany wprowadzone przez autorów SuperCheckout, choć to raczej nie jest wystarczające do tego żeby działało z tym modułem, skoro jak widać zmienili również 3 swoje pliki. Ale moduł ma też kosmetyczne poprawki w kodzie, więc tak czy inaczej warto zaktualizować.
  2. A chętnie przyjmę plik po zmianie, jeżeli nie będzie on psuł wstecznej kompatybilności to może wdrożę te zmiany w głównym module. Jednak jak widać więcej zmienili po swojej stronie.
  3. Włączyć tryb debug, może on wyjaśni gdzie może leżeć źródło błędu.
  4. Ktoś komu się udało pisał, że trzeba włączyć "Włącz kompatybilność z modułami wysyłkowymi"
  5. Ten przewoźnik wyróżnia się tym, że w bazie danych ma uzupełnioną kolumnę "module", problem jednak może być z tym, że będą dwie mapki i się moduł może pogubić, ale spróbować zawsze warto.
  6. Nie, bo to jest specjalny przewoźnik, który jest oznaczony w bazie danych jako przewoźnik powiązany z modułem, dzięki temu presta może wyświetlić przy nim dodatkowe informacje pochodzące z modułu (czyli przycisk wyboru paczkomatu).
  7. Jaka to wersja presty? Sprawdziłem właśnie na 1.6.1.24 i nadal można ustawiać nagłówki poszczególnym zdjęciom produktów:
  8. Czy ten sklep jest na prawdę tak rozgrzebany że nie ma możliwości po prostu go zaktualizować? Wyższa Presta działa na PHP 7.1 co pozytywnie wpływa na jej wydajność.
  9. To nie włączaj, presta nie jest zgodna z PHP 7.4, 7.2 to max.
  10. Baselinker musi być połączony przez API presty + musi być zezwolony dostęp do zasobu bl_order
  11. To powinno być wystarczające żeby adres dostawy podmienił się na adres paczkomatu.
  12. Najlepiej było by zaktualizować sklep do 1.6.1.24 i przejść już całkiem na PHP 7. A te komunikaty to w zasadzie ostrzeżenia, wyłączenie trybu debug powinno je wyciszyć.
  13. Image number is just image number, it's linked to product in the database
  14. Na pewno PHP jest za wysokie, choć nie musi to być przyczyną tego akurat problemu. Ustaw 7.2.
  15. Nie jest to do końca problem. Przewijanie się tego komunikatu w logach sklepu wynika z działania samej presty. Praktycznie przy każdym odświeżeniu strony sklepu (bo dzieje się to w głównym Front Controllerze), presta sprawdza czy w ciasteczku jest ustawione ID koszyka. Jeżeli tak to wykonuje kolejne sprawdzenie czy dla tego ID koszyka nie istnieje przypadkiem już zamówienie. Jeżeli okaże się, że zamówienie istnieje to znaczy, że koszyk trzeba wyczyścić i presta to robi, a skutkiem ubocznym jest ten właśnie komunikat. Czyli w większości przypadków to co się dzieje to druga część tego komunikatu, czyli "order has already been placed using this cart". Robiłem testy rozbijając warunek na dwa i przypadek "Cart cannot be loaded" nie pojawił mi się nigdy, zawsze chodziło tylko o fakt że zamówienie już istnieje. Dlaczego tak się dzieje, że zamówienie istnieje i jeszcze istnieje dla niego koszyk? Winne są tutaj moduły płatności. Może to być zachowanie celowe lub wynikające z lenistwa autorów tych modułów. W momencie gdy moduł płatności robi swoje, często przekierowuje klienta do jakiegoś zewnętrznego systemu płatności. Tylko teraz pytanie - czy klient dokona płatności poprawnie i wróci, czy nie dokona płatności, czy może coś tam jeszcze się dziwnego wydarzy, nad czym sklep już nie ma kontroli? Pojawia się więc dylemat programisty - czyścić koszyk czy nie? Jeżeli wyczyścimy koszyk, a klient przy płatności się rozmyśli i wróci na sklep to trafi na pusty koszyk i może już mu się nie chcieć kompletować zamówienia ponownie. Jeżeli nie wyczyścimy i klient wróci z błędem, to może spróbować raz jeszcze zapłacić. Jeżeli nie wyczyścimy koszyka, a klientowi zamówienie utworzy się poprawnie to wówczas zauważy to presta i za nas koszyk wyczyści. Więc można z lenistwa nie przejmować się w ogóle czyszczeniem koszyka i zrzucić wszystko na to że presta i tak tego pilnuje. Komunikat jest trochę mylący i mówi o dwóch rzeczach, co jest ewidentnym błędem programistów presty, bo tak naprawdę to nie informuje jednoznacznie co się stało, jednak doświadczenie pokazuje, że na 99% to co się stało to po prostu klient wrócił z systemu płatności (lub klepnął zamówienie w jakimś prostym module płatności typu przelew), presta zauważyła ten fakt i wyczyściła koszyk, przy okazji zostawiając ślad w logach. Jeżeli więc ten komunikat widzimy w momencie gdy w sklepie zostało złożone poprawnie jakieś zamówienie to zupełnie nie ma się czym przejmować i jedyne co można zalecić to go zignorować. Co innego gdyby występował w jakimś innym momencie bo to by raczej oznaczało niemożliwość utworzenia koszyka na podstawie ID zapisanego w cookie, ale gwarantuję że o takiej sytuacji szybko poinformowali by klienci zgłaszając, że sklep w trakcie zakupów sam wyczyścił koszyk lub po prostu pierwsza z brzegu osoba testująca sklep by to zauważyła. Jeżeli natomiast klienci zgłaszają nam problemy ze złożeniem zamówienia a ten komunikat jest, to znaczy że klientowi wysypało się coś w module płatności i nie doszło do końca, ale zamówienia na sklepie zostało jednak utworzone. Następnie klient odświeżył stronę i zobaczył ten komunikat, czyli znów zadziałał opisany wyżej mechanizm sprawdzający presty. W takiej sytuacji jednak błędu trzeba szukać gdzie indziej, w samym module płatności który nie wykonuje do końca swojej pracy.
  16. Wygląda jak jakiś konflikt między stylami InPostu a szablonu, pewnie do rozwiązania przez frontendowca.
  17. Na tyle na ile pozwalają na to opcje konfiguracji przewoźnika w prestashop.
  18. The module is all or nothing. Effects strongly depend on the actual original images that you have. What we can do is: you can send me a couple of original images that you have and consider problematic, give me information about the sizes you have set, then I can upload those images to some product on my shop where I have the module installed and you'll see what the effect will be.
  19. W tej chwili nie mam więcej pomysłów. Trochę to wygląda tak jakby nie podpięły się JS-y i kliknięcie powodowało to co zwykłe kliknięcie przycisku.
  20. PHP na pewno jest za wysokie dla tej wersji presty, ale nie wiem czy to może być tutaj przyczyną.
  21. Dla standardowego koszyka i gołej presty trzeba instalować najnowszą wersję, a nie poprzednie.
×
×
  • Create New...

Important Information

Cookies ensure the smooth running of our services. Using these, you accept the use of cookies. Learn More