Tomasz Słomiński

Just little feature demand ... It would be nice if the module editor had an access to some stats on module usage: versions of presta, versions of php, mysql, languages. It will be great help in planning releases and managing support. I think that presta collects this info anyway, so making this info accessible (with all regard to privacy protection issues) shouldn't be very difficult...

Bonjour, Si il s'agit l'information spécifique a paiement Ingenico (Ogone), il existe le champ "COMPLUS", permettant de soumettre une valeur que vous souhaitez recevoir dans la demande de retour d'informations ou la sortie. (Vous trouverez plus d'infos dans votre back-office Ingenico dans l'onglet Support -> Manuels d'intégration & d'utilisation -> Guides Techniques -> Parameter Cookbook ) Par contre, ce champ n'est pas actuellement intégré dans le module Ogone pour Prestashop, pour l'ajouter il faut modifier légèrement le module et (peut-être) modifier la configuration de Payement (Bo Ingenico, onglet Configuration->Information technique > retour information sur la transmission -> Paramètres dynamiques du commerce en ligne) Cordialement Tomasz Slominski

Hello for those of you who are validating their modules on validator.prestashop.com and are interested in some automation (for example with some build or CI system like phing or Jenkins), there is a small validator client I wrote recently; basically it allows to run validation directly via php script like this: require_once 'vendor/autoload.php'; $oClient = (new Kiwik\Prestashop\Validator\Client()) ->setUser('[email protected]') ->setPassword('password'); $oResult = $oClient->validate(__DIR__ . DIRECTORY_SEPARATOR . 'module.zip'); print PHP_EOL . $oResult->getInsightUrl(); // validator result page print PHP_EOL . $oResult->getErrorsCount(); // number of errors Git repo & more details on : https://bitbucket.org/kiwik/pvc-public ts.

Oczywiście : http://xdebug.org/docs/remote

Jest sens, jeżeli masz problemy z wydajnością PHP. Z doświadczenia, moduły wyszukiwania większą część czasu wykonania spędzają w bazie danych, więc IMHO lepiej zacząć od profilowania zapytań SQL; kiedy już upewnisz się że na poziomie SQL wszystko jest jak należy, możesz zabrać się za PHP. Jeżeli już sie bawisz xdebugiem , to pamiętaj że dorzuca on swój narzut - nawet ok. 30% - do wszystkich wykonywanych funkcji (+ czas na I/O plików wynikowych), więc wyniki trzeba interpretować biorąc to pod uwagę .

Witam, we wtorek odbędzie się drugi Barcamp Prestashop. Jest możliwość przedstawienia problemów specyficznych dla polskiej wersji presta - jak na przykład polskie znaki w fakturze czy w ogólności faktura proforma. Jeżeli macie jakieś uwagi / pytania do ekipy dotyczące tego typu funkcjonalności, to zamieśccie je w odpowiedziach, a ja postaram się wydobyć od nich maksymalnie precyzyjne odpowiedzi. Ponieważ temat jest na czasie (prestashop chce się stać naprawdę sklepem międzynarodowym, i pracują usilnie w tym kierunku), więc jest szansa że trafne sugestie zostaną wdrożone w miarę szybko Pozdrawiam Tomasz Słomiński

najlepiej nie wywalać, tylko ściągnąc wszystkie zdjęcia i przekonwertować używając np irfan view, po czym wgrać ponownie

Witam, paczka językowa z prestashop.pl (z rewizji 15 svn) została zintegrowana z prestą i jest dostępna na oficjalnej stronie ( http://www.prestashop.com/en/downloads/ ). Zawartość jest w trakcie czyszczenia i sprawdzania, więc tłumaczenie może się jeszcze w ciągu najbliższych dni zmieniać. W najbliższym czasie spróbuję jeszcze dorzucić do głównego wydania polski instalator (chociaż , znając życie, to raczej do wersji 1.4). Wszelkie uwagi, uzupełnienia, nowe tłumaczenia itp. mile widziane. Pozdrawiam Tomasz Słomiński

w tej chwili oficjalne polskie tłumaczenie to 50% całości niedługo się to zmieni

Po pierwsze, nie jesteśmy konkurencją. Po drugie, podałem ci na szybko kilka konkretnych przykładów rzeczy które nie są moim zdaniem dobrze w waszym systemie zrobione. Mógłbym pewnie znaleźć dużo więcej, ale nie zamierzam robic audytu całego waszego systemu. Problem z walidacją, nieczytelny formularz, nieprawidłowy html - to rzuciło mi się w oczy w pierwszym formularzu jaki otwarłem, i tyle. Po trzecie, nie wątpię w to, że macie wiernych klientów i że się ciężko staracie. Ale z takim interfejsem będziecie musieli starać się 10 razy ciężej od kogoś kto ma interfejs czytelny i dobrze zaprojektowany. Po czwarte, nie każda krytyczna uwaga jest od razu jeżdżeniem po kimś.

jakoś nie udało mi się w konfiguracji dogrzebać do walidacji nipu. może nie szukałem tam gdzie trzeba? Żeby skończyć wątek, walidacja była tylko jednym z przykładów tego, że wasz system ma nieczytelny i nieprzyjazny dla użytkownika interfejs. Używałem już kilku programów księgowych, parę interfejsów też zaprojektowałem, i wiem że ma to niesamowicie duży wpływ na satysfakcję klienta. To tyle z mojej strony, zanim wątek zmieni się we flame'a.

Po coś są te wyrażenia regularne, a komisja europejska jest na tyle miła że udostępnia listę wszystkich formatów NIP-ów w internecie, i to za darmo. Praktyki firm są mi akurat doskonale znane, ale co to za problem dodać prosty walidator w javascriptcie który w razie czego wyświetli komunikat "wprowadzony NIP niezgodny z formatem oczekiwanym dla kraju kontrahenta, czy chcesz go zachować mimo to?"

No przepraszam, ale jak widzę na przykład pole "NIP" i obok input na 600 pikseli, bez żadnej walidacji, limitu znaków itp. to już wiem że jest problem i to poważny. Poza tym pola w takiej tabelce (btw, jak się robi wszystko w table to można by się na przykład przekonać do znacznika th) z obwódką są słabo czytelne (cell-spacing się kłania). Itd, itp. A nieprzejrzysty design to strata czasu. A tryb "de gustibus" to mógłbyś włączyć gdybym się czepiał że kolor tła nie taki (chociaż to też ma wpływ). PS. I popracujcie nad polską wersją językową.

wygląd + ergonomia = efektywność pracy + zadowolenie klienta

wow, sklep jak sklep, ale w interface systemu przenosi w przeszłość o dobre 10 lat...