sower

Ale gdzie na lewą stronę? - do bloku kategorii?

może na początek wyłącz cache w wydajnościach

W pierwszej kolejności ustawa w konfiguracji kraju (lokalizacja->kraje) w formacie adresu dodaj telefon_komórkowy (phone_mobile)

ale gdzie? podczas standardowej rejestracji czy składania zamówienia

usuń prawą kolumnę to zobaczysz różnicę

No ale co tu oceniać? Sklep na tempetce z TM w dodatku z wieloma błędami wygląd karty produktu i widoku kategorii tragiczny - tak swoją drogą po co prawa kolumna?

a w ship2pay są przypisane do tych nowych sposobów dostaw sposoby płatności?

_product_attribute - tabela służąca do utrzymania kompatybilności wstecznej - np. przy migracji ze starszych wersji _product_attribute_shop - to w sumie główna tabela gdzie są przetrzymywane i pobierane dane o atrybutach przez sklep/sklepy - tak jak napisał tabela ta jak i pozostałe z przyrostkiem _shop pojawiły się wraz ze opcją multistore Presta w wersji 1.6 - używa domyślnie tabel z przyrostkiem _shop

Po pierwsze - takie rozwiązanie nie jest zgodne z obowiązującym w naszym kraju jak i w EU prawem Po drugie - klient kupując produkt kupuje produkt nie usługi dodatkowe Po trzecie takie rozwiązanie implementuje się na karcie produktu gdzie klient sam wybiera co chce - np nadruk jako atrybut, np wykonanie projektu jako atrybut (z wpływem na cenę, a możliwość dodania własnej grafiki robi się po przez dostosowanie produktu Tworzenie takiego moduł j/w nie ma kompletnie żadnego sensu bo przy pierwszym upierdliwym kliencie trafisz do uokik-u za wprowadzanie konsumenta w błąd - zapominasz, że proces zakupu podlega pod umowę cywilno-prawną zawieraną między klientem/konsumentem a właścicielem sklepu a pojęcie ceny produktu jest w naszym prawie jasno zdefiniowane - polecam przestudiowanie ustawy o prawach konsumenta

bez linku nikt ci nie pomoże - może być 9999999 przyczyn takiego zachowania jednak najczęstszym jest reskaling robiony przez przeglądarkę odczytującą funkcje zaimplementowane w templetce np w jakimś frameworku, w plikach css, w jquert itd itp - lub po prostu jakiś błąd w css-ach

a skąd ty wziąłeś taką tabelę order_product ? przeczytaj dobrze post który zacytowałeś

a na jakim hostingu masz ten sklep?

a masz atrybuty w produktach? włączony magazyn?

da się - z poziomu phpmyadmina albo skryptem

tak czytam i czytam i nie bardzo rozumiem standardowy moduł crossselling domyślnie wyświetla produkty na hooku hookshoppingCart , który jest zaimplementowany w większości templetek. Więc skoro są powiązane w zamówieniach produkty do dodanego do koszyka produktu to one się wyświetlą - of kors jeżeli moduł jest zainstalowany i działa poprawnie

tu masz rację.......... ale czy podążanie w tym samym kierunku co Magento jest dobrym pomysłem..............nie wiem, tak samo jak nie wiem czy nie jestem pewien czy robienie z presty takiego wymagającego/"zasobożernego"systemu jest dobrym pomysłem...................ale co tam trzeba się przestawić i tyle

możesz zrobić upgrade - ale to ryzykowne bez odpowiedniej wiedzy albo poszukać jakiegoś "narzędzia" albo zlecić to komuś możesz jeszcze pobawić się w eksportowanie danych z bazy 1.6 i po ich zmodyfikowaniu zaimportowanie ich do bazy sklepu na 1.7

hm.......... z tego co widzę, to dla 1.6 na stronie presty jest jeszcze dostępna stara wersja modułu tzn 1.6.7 nie wiem z jakiego to powodu jeszcze nie opublikowali wersji 2.0.2 dla 1.6 - pewnie dla tego, że 1.7 jest z d...py i nie chcą pozwolić aby ludzie sobie problemów narobili masz 2 rozwiązania -> 1. poczekać na zaktualizowanie modułu 2. zmodyfikować moduł zmieniająć $this->ps_versions_compliancy = array('min' => '1.7.0.0', 'max' => _PS_VERSION_); na $this->ps_versions_compliancy = array('min' => '1.6.0.0', 'max' => _PS_VERSION_); ewentualnie zainstalować wersję modułu 1.6.7 i przez ftp podmienić pliki w katalogu modułu Punkt 2 przećwiczony przy aktualizacji 2 sklepów z 1.6 do 1.7 oczywiście nie obyło się bez problemów tak p.s to przy okazji poruszania tematu wersji 1.7 - to stanowczo odradzam czy to upgrade czy stawianie sklepu na tej wersji - patrząc na ilość błędów i samom architekturę silnika i templetki to robi się z tego jakiś przeładowany kombajn dodatku obciążony brakiem kompatybilności wstecznej. Co z tego wynika dla przeciętnego użytkownika - dla tych, którzy mają już sklepy na starszych wersjach - koszt migracji do 1.7 wzrasta mogę śmiało zaryzykować twierdzenie, że 2-3 krotnie. A samo wdrożenie nowego sklepu na 1.7 także będzie droższe. Idąc dalej - presta w wersji 1.7 ma już wymagania dotyczące "serwera" porównywalne do Magento a co za tym idzie jeżeli dla małego czy średniego sklepu wystarczał jakiś dobry współdzielony hosting to niestety dla 1.7 potrzebny już będzie VPS - czyli 3-5 krotnie droższy hosting. To tyle w temacie 1.7

a którą wersję presty masz?

hm........... a skąd tą "wiedze" posiadasz? Standardowy moduł 1-click upgrade w wersji 2.0.2 (2016-12-29) - pozwala na upgrade do 1.7.0.3

może prościej zrób ugrade na tej 1.6 do 1.7 i po problemie przeniesienie bazy danych jest złym pomysłem - z prostej przyczyny - bazy między wersjami się różnią

lepiej zleć to komuś

W tłumaczeniach sklepu a dokładniej twojej templetki - o ile jest zgodna ze standardem

to ja zadam proste pytanie - czy te kody dodałeś do plików tpl w takiej samej postaci jak te które wkleiłeś w poście? bo jeżeli tak to nie zadziała z prostej przyczyny - braków informacji przykład goadservicesq.push( [ "_PRODUCT", { identifier: 'identyfikator-produktu', availability: 'dostepnosc-produktu' } ] w preście nie ma takiej wartości jak identyfikator-produktu, dostepnosc-produktu w te miejsca musisz wstawić odpowiednie wartości generowane przez prestę

1. Zapoznać się z podstawami SEO i SEM 2. Ustawić odpowiednie treści w ustawieniach meta i seo w sklepie 3. Zaimplementować odpowiednie treści w h1 , h2, h3 ..............................