powershop24.pl

Miałem niedawno podobny problem na Preście 1.6.0.8. Okazało się że trzeba usunąć plik cache/class_index.php. Ale problemem może być równie dobrze to, że klienci podczas składania zamówienia nie zaznaczają zgody na przetwarzanie danych osobowych przez Okazje.Info. K.

W edycji kategorii. K.

Moduł "Własny blok informacyjny CMS". K.

Witam! Próbowałem właśnie skonfigurować logowanie poprzez PayPal zgodnie z instrukcją do modułu. Aplikację założyłem, moduł skonfigurowałem. Przycisk "Zaloguj się PayPal" przy logowaniu pojawia się, tyle że po wciśnięciu przycisku na chwilę pojawia się okno PayPal (bez zawartości) i po chwili znika. Na konsoli pojawiają się błędy: Uncaught TypeError: Cannot read property 'querySelectorAll' of null api.js:5 (anonymous function) api.js:5 (anonymous function) api.js:8 (anonymous function) Pod poniższym linkiem ekran z błędem: http://screencast.com/t/88K9bWRmC5 Błąd pojawia się jeszcze przed wciśnięciem przycisku logowania przez PayPal. Czym to może być spowodowane? Podejrzewam że może to mieć związek z szablonem. Szablon kupiony na templatemonster.com. Presta 1.6.0.8, moduł PayPal v. 3.7.2. Sklep: www.powershop24.pl K.

Wrzuć linka do Twojego sklepu. K.

Witam! Mam ustawioną w sklepie darmową wysyłkę za zakupy powyżej 500zł. Czy jest jakiś sposób aby wyłączyć darmową wysyłkę dla krajów innych niż Polska? Lub chociaż zmienić minimalną wartość zamówienia dla pozostałych krajów? Presta 1.6 K.

Wielkie dzięki! Zadziałało. K.

Preferencje -> Motywy -> Dodaj szablon. K.

Witam! Na pulpicie Prestashop 1.6 znajdują się statystyki "Najczęściej przeglądane". Niestety pojawia się na nich wielokrotnie tylko jeden produkt (ekran poniżej). Wygląda jakby zapytanie SQL było skopane. Który moduł/plik odpowiada za generowanie tych statystyk?

Samo dodawanie klientów do innej grupy też nic nie da bo jest to już czynność post factum, kiedy klient już się zarejestrował i złożył zamówienie. Ma sens tylko przy nowych zamówieniach i to dopiero po zalogowaniu się takiego klienta. K.

A czy istnieje jakiś sposób aby automatycznie dopisywać klienta zagranicznego z Unii (niekonsument_UE) do innej grupy (wszystko w cenach netto) na podstawie kraju i wypełnionego numeru UE VAT? Kraj klienta i numer UE VAT jest ustawiany na poziomie adresów i na podstawie tam wprowadzanych danych można by rozpoznać czy przypisać klienta do tej specjalnej grupy klientów niekonsument_UE. Pomyślałem o napisaniu w bazie triggera który po wypełnieniu adresu rozliczeniowego, sprawdzi te 2 pola i jak są uzupełnione to ustawi klientowi domyślna nową grupę. Tylko że nie bardzo wiem jak rozpoznać z poziomu bazy danych który adres jest faktycznie rozliczeniowym? Gdzie zapisywana jest informacja o tym który adres jest adresem dostawy a który rozliczeniowym? K.

W takim razie widzę u siebie problem polegający na tym, że wszyscy nowi klienci, już po uruchomieniu sklepu na wersji PS 1.6, zakładali hasła wg nowego klucza. Zmiana klucza na poprzedni (z wersji 1.4) spowoduje że nowi się nie zalogują. Jest jakiś sposób żeby przekonwertować hasła aby korzystały z innego klucza? K.

A skąd to pobrać i jak wgrać w docelowej bazie? Sam ostatnio przenosiłem klientów z 1.4 do 1.6, ale poprzez pliki CSV. Klienci się zaciągnęli, ale wiem że były problemy z logowaniem bo hasła były odrzucane. K.

Jeszcze tabelę adresów powinieneś przenieść (ps_address).

Ship2Pay nie będzie działał, ale ten poniższy moduł (Payments to carriers) działa prawidłowo: http://www.prestashop.com/forums/topic/326247-prestacenter-payments2carriers-free-for-ps-15-and-16/ Oczywiście przed jego zainstalowaniem trzeba odinstalować i usunąć Ship2Pay. K.

Póki co nie działa pod 1.6.0.8. Tu więcej na ten temat: http://prestadesign.pl/topic/5525-wersja-16-problem-z-mailami-po-zakupie/page-2?hl=ship2pay K.

Znalazłem przyczynę. Problem (błąd) polega na tam, że nowa wersja PS 1.6.0.8 w pliku PaymentModule.php składa html-a z listą produktów do wiadomości w oparciu o plik order_conf_product_list.tpl. Wcześniejsza wersja PS 1.6 składała html-a bezpośrednio w pliku PaymentModule.php. Sęk tym że plik order_conf_product_list.tpl znajduje się tylko w katalogu z tłumaczeniami wiadomości dla języka angielskiego, natomiast dla polskiego już go tam nie ma. Wystarczy przekopiować pliki *.tpl z katalogu mails\en do mails\pl i będzie działać prawidłowo. W ten sposób składany jest html z listą produktów do wiadomości w najnowszej wersji PS1.6.0.8: $product_list_html = $this->getEmailTemplateContent('order_conf_product_list.tpl', Mail::TYPE_HTML, $product_var_tpl_list) K.

Na 100% ze wszystkich. Na co dzień pracuję z bazami danych, w tym MySQL, więc mam świadomość tego co usuwam z bazy. Poza tym z tego co widzę, to w PS1.6 order_id ma na kolumnie autoincremement, więc sytuacja powielenia numeracji po usunięciu nawet samego nagłówka zlecenia nie powinna wystąpić. Pierwsze zlecenie utworzone po produktywnym uruchomieniu sklepu ma id=15. Poprzednie 14 zamówień testowych poleciało wcześniej do kosza. Każde nowe zamówienie, począwszy od 15 generuje powiadomienie bez listy produktów. Spróbuję jeszcze coś pokombinować z szablonami wiadomości. K.

Wielkie dzięki. Teraz wszystko gra jak należy. K.

Jednak chyba nie działa. Przynajmniej u mnie nie na 1.6.0.8. Pokazuje wszystkie możliwe płatności. K.

Od początku był na 1.6. 2 dni temu został uruchomiony produktywnie po wgraniu aktualizacji do 1.6.0.7 i 1.6.0.8. Wcześniej testowałem na 1.6.0.6. i na tej wersji nie było problemów z wiadomościami. Dodatkowo przestał mi działać w tej najnowszej wersji moduł ShipToPay (http://addonspresta.com/pl/darmowe-moduly/48-ship-to-pay.html). Działał w 1.6.0.6. Teraz wygląda to tak jakby w ogóle nie był uruchamiany, pomimo tego że jest włączony i prawidłowo skonfigurowany. Sprawdzałem też podobny moduł Paymants2Carriers (http://www.shopdesign4u.com/pswiki/index.php?title=Payments2Carriers) ale ten też nie działa. Jedyna jeszcze rzecz która się zmieniła, to taka, że ten sklep w wersji testowej wcześniej działał pod adresem http://foral2.vot.pl/ps1.6, teraz działa pod www.powershop24.pl. Pliki nie były przenoszone, zostało tylko zmienione przekierowanie domeny na inny katalog. Adres sklepu został oczywiście też zmieniony w konfiguracji (Preferencje -> SEO & URL). Sam sklep też działa prawidłowo, nie ma błędów. K.

order_conf.htmlorder_conf.txt Problem pojawił się po aktualizacji Presty do wersji najpierw 1.6.0.7 a później 1.6.0.8. Sklep został uruchomiony produktywnie 2 dni temu, wcześniej testowałem na wersji 1.6.0.6 i nie było problemu z wiadomościami. Zlecenia z wersji testowej zostały usunięte z wszystkich tabel związanych z zamówieniami. W załączniku szablony wiadomości.

A działa pod 1.6.0.8? Bo mi właśnie przestał działać i nie wiem czy to u mnie problem czy generalnie z tą najnowszą wersją? Krzysiek

To siedzi w pliku global.css: http://screencast.com/t/hhCPgICtIz1 K.

Nazwa się wyświetla, tylko że ma biały kolor czcionki. K.