LolikZabójca2

Robię prosty sklep na preście który będę stopniowo rozbudowywał i przystosowywał do swoich wymagań. Póki co wymagania są małe to... nie, wciąż nie jest łatwo Dlatego wybierałem kiedy mogłem WooComerce, bo personalizacja tam była bardzo intuicyjna, ale zabrakło funkcjonalności. W PrestaShop nic nie jest intuicyjne, więc muszę się dowiedzieć co i jak. 1)Mam tutaj ustawienia strony głównej. Motyw domyślny. Jak zamienić dany kontentener miejscem(np. text block chcę mieć między slider a home products) oraz jak dodać własny moduł do widoku? To znaczy nie własny, ale po prostu załóżmy, że potrzebuję wrzucić drugi text block. 2) Jest fajna opcja, że mogę wybrać różne warianty kolorystyczne produktu, aby były dostępne. Ja potrzebuję jednak czegoś jak na allegro. Mam produkt np, czerwony t-shirt i biały t-shirt. Chcę aby po wejściu w czerwony, była widoczna też opcja, że jest i biały i można kliknąć i przełączyć. Natomiast różnica polega na tym, że na liście produktów chcę mieć i taki i taki. Mimo, że to ten sam produkt w innym kolorze. Fajnie też jakby zamiast koloru w formie kwadracika był podgląd produktu w danym kolorze i jeszcze lepiej żeby po najechaniu np. na wariant czerwony zdjęcie w maturce produktu czarnego chwilowo pokazywało wariant czerwony(jak na Alieexpress).

Możemy nawet prosić o kontakt użytkownika z prośbą o edycję danych. Poza tym taki formularz to nie problem. Usunięcie danych to usunięcie(nawet nie wszystkich zgodnie z RODO) danych z bazy. Widzę codziennie problemy kolegów z taką prestą. Widzę co chwilę rzeczy typu "jak usunąć wirusa". Bo ciągle presta ma jakieś backdoory. We własnym sklepie idzie się w tym połapać, w takiej prescie już nikt się nie łapie, bo jest ogromna. Stąd tyle błędów. Po prostu w tym temacie chcę pomocy z przygotowaniem się do pisania takiego sklepu. O tym czy da się te rzeczy zrobić w Presta założę inny. Muszę dokładnie zbadać każdą możliwość. Póki co to widzę więcej gadania "nie da się" niż faktycznych problem. Mocno wyolbrzymiane jest wszystko. Dobre pytanie bo łatwo zweryfikować czy int to int itp. Formularze tego typu to co innego. Jak googlowałem o XSS to tam są informacje o wrzucaniu komuś złośliwego kodu JS, czy PHP i odpalaniu go na różne sposoby. O to pytam. Bo tutaj póki co nie widzę takiej opcji. Ale wiesz o tym, że ja będę miał wszędzie FVAT 23% i w dodatku to idzie potem do księgowej która to sprawdza? Rozumiem, ale meczy mnie takie gadanie trochę. Wiem jaki chce program lojalnościowy i wiem ile się go pisze. Być moze mieli inny. Być może pisali program lojalnościowy pod Prestę albo Magneto wtedy to może trwać latami. I właśnie tego chcę uniknąć. Każdy kto pisał w HTML/CSS/PHP stronę wie, że to kilka operacji na MySQL tylko(o ile piszemy to od zera a nie pod CMS). W tym problem, że podchodzę do tego tak, że chcę uniknąć ryzyka na ile mogę zdobywając najpierw odpowiednią wiedzę. I przykro mi, że zamiast pomocy otrzymuję informacje z cyklu nie rób tego, bo X programistów to nie umie zrobić w Y dni. No ja chcę konkrety, bo to mi nic nie mówi. Zrobię temat o własnym sklepie i zbiorę informację. Potem o tym jak dane rzeczy wdrożyć w Prestę. Na koniec to porównam. Tymczasem ciężej mi zebrać informacje kiedy muszę męczyć się z tłumaczeniem tego, że potrzebuje konkretów, a nie gadania nie bo nie, albo X lat tym się zajmuje i robię na CMS i jest lepiej. Znam też programistów co umieją robić strony tylko na WP i robią to całe życie i NIEKTÓRE strony potrafię szybciej od zera napisać niż oni w WP. I potem sa problemy z edycją czy backdoorami takiego WP plus strona muli przez co spada w Google, a strona w HTML/CSS/PHP potrafi zajmować kilkaset linijek kodu i mieć mniej niż 1mb. Steve Jobs mówił think different - nie torpedujcie jakiegoś pomysłu tylko dlatego, że każdy mówi, że robi się inaczej niż ja proponuje. Pomyślmy o tym w sposób rzeczowy. Zastanówmy się. Właśnie dlatego, że chodzi o dane klientów nie możemy sobie pozwolić na nie konkretne dyskusje. Potrzebuję konkretów. O i to jest właśnie konkrety. To może mi dać jakieś wskazówki. Więc rozważmy to. 1. - nie mam serwisu magazynowego i mieć nie będę. Tylko baza MySQL sklepu. 2 - tego się nie obawiam. A jako, że będę to pisał sam, to będę mógł zrobić promocje czy rabaty tak jak ja chcę. 3 - Numery przesyłek przekopiuje i wkleję bo i tak zamawiam kurierów przez pośredników, a nie bezpośrednio(dla małej firmy wychodzi taniej). Koszty zależne od regionu odpadają(Polska), wagi też. Ceny przesyłek i tak w większości sklepów są stałe. I to są takie rzeczy które np są w prescie a mi nie są potrzebne dlatego pójdzie mi szybciej. No a jakbym potrzebował to co za problem przydzielać każdemu produktowi np. i klasę przesyłki i wybierać w koszyku najdroższą? Można też po KG ale w detalicznym ecommerce takich technik się raczej nie używa. Zasady przesyłki muszą być maksymalnie proste dla klienta. Jeśli się będzie musiał nad tym zastanawiać, pewnie procent zrezygnuje tylko z tego powodu, że nie rozumie skąd dana cena wysyłki i nie ma czasu się nad tym zastanawiać. Dzisiejsi klienci sklepów internetowych oczekują maksymalnej prostoty. 4 - umów nie będzie. Faktury będę generował. Maile wiem jak wysyłać. 5.1 No tu pytanie czy wiem na 100% jak to zrobić czy myślę że wiem. Na pewno PDO żeby nie było MySQL Injection. Na pewno na każdej podstronie weryfikowanie czy nikt się nie "podszywa" pod kogoś kto ma uprawnienia do danej informacji na stronie weryfikując sesję. Coś jeszcze? 5.2 - To wiem, będę pamiętał na pewno. 5.3 - damy radę. 5.4 no to pewnie to co w 5.1 pisaliśmy. Jeśli nie to możecie mi coś dodać od siebie. 6 - no pewnie zależy też od dostawcy bramki. O tym muszę się dowiedzieć jak najwięcej i będę czytał dokumentacje wkrótce. Może nawet jeśli podejmę decyzję że robię od zera to zacznę od napisania obsługi bramek żeby sprawdzić czy podołam. 7. Mógłbyś rozwinąć? No właśnie. Wiedza programistów o ecommerce kończy się na tym, że sprzedaż to dla nich sprzedawca w sklepie, a nie techniki sprzedażowe opracowywane przez specjalistów od sprzedaży. Ciężko programiście uświadomić sobie co na prawdę jest czym. Marketing i sprzedaż to mega skomplikowane sprawy. Ja też pisałbym pod prestę jakiś dodatek dłuuuugo. Dlatego wolę własny silnik gdzie napisanie podstrony to raptem kilkaset linijek, a często kilkadziesiąt, a dodanie jakiegoś widgetu czy formularza to kilkadziesiąt linijek. To zupełnie inny kaliber. Osobie która ma obroty w sklepi 5-10tyś/msc nie są potrzebne programy magazynowe, integracja z systemem dostaw itp. Kuriera zamawia się na jednej stronie, na sklep przekopiowuje numer przesyłki do formularza i gotowe. Z boku możesz dodać przycisk śledź paczkę, a jak bardzo chcesz integrujesz z API jednego z wielu silników który obsługuje śledzenie paczek od wszystkich kurierów i poczt, a nie każdego z osobna. Proste i skuteczne. To ma działać. Dla programisty "dobrze dla klienta" oznacza co innego niż dla gościa od sprzedaży i marketingu. W innych miejscach trzeba doszukiwać się problemu niż w tym, że nie będzie programu magazynowego czy bezpośredniej integracji z systemem wysyłki zamówień. Takie rzeczy się robi jak ma się conajmniej setki przesyłek dziennie. Jeśli sklep zacznie wychodzić poza to powiedzmy 10tyś obrotu miesięcznie to się zainwestuje w rozbudowę. Na początku każdego biznesu jest minimalizowanie kosztów, żeby zbadać rynek i pomysł w praktyce i nie stracić mnóstwa pieniędzy w razie czego. No i żeby nie czekać z próbowaniem swoich sił aż uzbieramy kilkadziesiąt tysięcy złotych tylko zacząć tu i teraz. Można wydawać dużo, a można poświęcić swój CZAS na to by zbadać możliwości jak zaoszczędzić pieniądze. Jasne w sytuacji firmy która z góry wiadomo że będzie miała ponad milion obrotu rocznie robi się odwrotnie. Pompuje się kasę żeby oszczędzić każdą minutę czasu. Zrozumcie też jedno. Nie jest to temat o tym co lepiej wybrać. Dlaczego? Bo ja zbiorę informację jakby to wyglądało. Potem zbiorę jak wyglądałoby przerobienie na preście. Wtedy wypiszę sobie co jakie ma zalety, a jakie wady. I wtedy będzie miejsce na taką dyskusję i rozważania. Podchodzę do tego bardziej poważnie niż może Wam się wydawać. Dlatego zanim podejmę taką decyzję chcę 'zasymulować' jedną i drugą opcję, żeby zobaczyć w takiej 'praktyce' co wyniknie(nie do końca praktyce, bo symulacji tylko, ale to lepsze według mnie niż rozmowa ogólnikami, lepiej mieć sytuację czarno na białym co jakie wady i zalety ma). Tu nie chodzi o to, że ja się uparłem, żeby go pisać od zera na 100%. Chodzi o to, że w tym temacie takie jest moje zadanie, że ja się będę upierał, żeby zrobić wszystko żeby się "udało"(tzn na razie w sensie teoretycznym), a Wy swoimi uwagami pozwolicie mi nie być właśnie olewczym i dostrzec to, czego moje mniejsze doświadczenie w pisaniu sklepów nie pozwala(bo pisałem rożne strony, nawet ruletki internetowe, ale nigdy sklepy). Nie obraźcie się, że się tak upieram przy swoim. Takie moje zadanie w tym temacie. Ale nie chcę tak ciągle gadać o tym, czy ta presta to dobry pomysł czy nie. Chciałbym, żebyśmy na chwilę zapomnieli, że CMSy istnieją. Potem porozmawiamy o tym, jak pewne rzeczy można zrobić w CMSie pokroju Presty. A na sam koniec porównamy co wynikło z jednego i drugiego tematu. To bardzo ważne dla mnie, bo pakuję mnóstwo energii i pieniędzy(względnie, dla mnie to mnóstwo pieniedzy, bo wiadomo, że są tacy co lekką ręką mogą i bańkę wydać na taki sklepik) i muszę wszystko zbadać bardzo dokładnie. Każdą możliwość. Chcę podejmować świadomie każdą decyzję, opierając się na faktach, a nie przeczuciach. Tego nauczyło mnie dotychczasowe doświadczenie jako przedsiębiorcy. Mam nadzieję, że teraz lepiej rozumiecie dlaczego ten temat wygląda tak, a nie inaczej. I dlaczego sprawiam wrażenie takiego któremu się nic nie wytłumaczy. Bo w tym temacie zakładam opcję, że robię od zera i koniec. Chcę sprawdzić co z niego wyniknie. Zakładam tak na potrzeby tego rozważania, a nie że na prawdę jestem 100% pewien, że to super pomysł. Ale mój sposób pracy nie przyjmuje do wiadomości ogólników, bo całe życie spotykam ludzi którzy mówią, że "jak czegoś nie robi się to się nie da, bo ktoś by to już zrobił" i nie jest to bliskie mojemu podejściu do rzeczy. Dzięki wielkie za wkład w temat, bo mimo wszystko parę konkretów padło

Sklep nie ma ogarniać podatku w przypadku płatnika zza granicy, bo takiej osobie nic nie sprzedam(koszta wysyłki). Presta też nie ogarnia domyślnie takich rzeczy. Dzisiaj gadaliśmy ze znajomym o problemach które sprawiają, że faktury z Presta zawsze są inne niż po sprawdzeniu przez ksiegową. Na razie nikt nie podał mi konkretnego powodu dlaczego nie. Ja nie potrzebuję wystawiania faktur. Towar będzie in stock kiedy będzie odpowiednia ilość na magazynie. To jeden wpis obok każdego produktu w MySQL. Wygląda mi to trochę jak typowe "nie da się, bo każdy tak mówi". No tak się firm nie prowadzi. Jeśli pomysły rozpatrujemy na te które robią wszyscy i te których się nie da. No póki co każdy mi mówi, że nie bo nie. Tylko sprawdzę jeszcze kwestię bramek płatności bo to jedyny konkret. Ale to nie powinno też sprawiać większych problemów. GDPR czyli RODO - okej ale z tego co wiem to tam nie ma żadnych konkretnych wymagań. Tylko, że dane mają być bezpieczne. Jesteśmy wszyscy programistami, a słyszę, że przygotowanie wydruku FVAT, albo ustawienie ilości w magazynie to problem programistyczny który przezwyciężą tylko nie liczni. Przecież takie rzeczy jak "in stock" to się robi w pierwszym roku nauki programowania.

tzn jestem też programistą. Tylko też marketingowcem i stąd rozumiem dlaczego jest taki problem z komunikacją jednych z drugi. W każdym razie to nie jest istotne takie, po prostu wygodniej mi napisać ręcznie i tyle, nie wchodźmy w szczegóły bo rozmowa marketingowca z programista na takie tematy to jak rozmowa z fanem Linuxa który mówi, że konsola też jest wygodna xd Wiecie, wszystko zależy od punktu siedzenia. Dla programisty presta jest idealna. Dla informatyka Linux. Dla usera Windows, a dla marketingowca Presta to bariera w kreowaniu takiego sklepu, jaki chce. Ależ jestem. Piszę strony internetowe, czy programy. Ale pewnie mniej doświadczonym od Was. Robiłem różne portale posiadające wiele podstron wczytywanych na podstawie MySQL, z panelem admina i edycją treści z jego poziomu. Po prostu chcę się dowiedzieć jakie byłyby utrudnienia w przypadku sklepu bo tu jest wiele newralgicznych danych, Co do bramek płatności rzeczywiście poczytam o tym. Programuję od kilku lat w tym także komercyjnie, ale sklep to po prostu duże ryzyko w razie kary za RODO. W tym cała rzecz Oooo fajny link. To teraz podyskutujmy, bo mnie zaciekawiłeś. MySQL Inject to raczej wiadomo jak ominąć. A czy przepełnienia bufora może spowodować coś więcej niż tylko nie wczytanie strony? Jak to działa w praktyce? Jak unikać zdalnego wykonanie poleceń? Czym jest dokładniej ten opisany background? Manipulacja ceną to raczej mały problem, bo wystarczy po prostu po stronie serwera obliczać ceny produktów a nie clientside. I o czym uprzedził mnie Gnysek sprawdzać czy przedmioty są w odpowiedniej ilości. Jak mam to rozumieć?

Gnysek nie jest marketingowcem i dlatego nie do końca rozumie w czym rzecz. Dlatego proszę ogólnie o konkrety, a nie "nie, bo nie i wybierz prestę". WIdzę jaki problem z nią mają marketingowcy. Albo znajdziesz na coś wtyczkę(najczęściej nie) albo się zgadasz że sklep będzie gorzej sprzedawał. Tu nie chodzi o to, że nie ma wtyczki która robi coś, ale takiej która robi w odpowiedni sposób. Właśnie ciężko opisać programistą różnicę, bo trzeba by podać chociażby podstawowe przykłady z marketingu, ale myślę, że po prostu taka dyskusja jest zbędna. Tutaj nie chodzi mi o przekonanie kogokolwiek do swojej czy czyjejś racji, tylko szukam odpowiedzi technicznych dlaczego to miałby być zły pomysł. Tak dla siebie. Tylko ja bym go używał. XSS - czy ten problem mnie wgl dotyczy skoro nikt poza mną nic nie będzie mógł umieścić na mojej stronie? Właśnie wydaję mi się, że presta jest tak wielka, że zabezpieczenie jest dużo trudniejsze i te łatki to tak na prawdę łatają najczęściej jakieś przeoczenia, a na tak małej stronie która będzie miała maks 10tyś linijek kodu to raczej nie będzie takich problemów. Nie planuję wielkiego CMSa tylko zwykłą stronkę ze sklepem i prostym formularzem dodawania produktów z panelu admina. October_(CMS) - poczytam, dzięki @gnysek xxxxD Nie wiesz nic o programowaniu w takim razie - dobra coś sobie wyjaśnijmy, bo chyba źle się rozumiemy. Ja nie chcę pisać CMSa dla innych. Tylko sklep dla siebie. Robiłem nie sklepy, ale strony o podobnej złożoności. Ile czasu zajmie napisanie strony z listą produktów z sortowaniem itp, podstroną produktu i panelem do dodawania produktów? No to nie jest długo. Robiłem strony o podobnej złożoności od zera. Np. dla muzyka stronę w której miał na stronie głównej widok playlist, w każdą można było wejść i sprawdzić listę utworów z danymi o nich, z informacjami o albumie ogólnie, w każdy utwór jak wszedłeś miałeś linki do różnych platform do odsłuchu itp. Tutaj będzie możliwe, że nawet mniej podstron. Właściwie to trzy podstrony - strona główna, strona kategorii i strona produktu - nie licząć panelu admina. Który nie ma być rozbudowany. Okno tytułu produkt, kategorii, opisu z gotowym silnikiem do obsługi wizualnie HTMLa w inpucie itp. "no ale kto te etapy programuje co? wiesz chociaż jaki jest standard branżowy w e-commerce?" i dlatego my jako marketingowcy się wkurzamy i ja wolałbym napisać to od zera. Bo programiści gdy projektują takie rzeczy to robią to technicznie, a nie czując potrzeby klienta. "przepraszam kto implementuje obsługę bramek płatności? Jak myślisz, ze to działa? Przecież musisz wypuścić ze sklepu klienta do bramki z kwotą i numerem zamówienia, a potem sprawdzić, czy już opłacił. Ja Ci powiem - z doświadczenia, taki kod bramki (gdzie numer karty/przelew robimy po stronie bramki a w sklepie nie pobieramy żadnych danych) to jest kilkadziesiąt plików kodu po kilkaset linijek. I nikt tego nie napisał w tydzień. Paczkomaty czy DHLa też rozumiem w godzinkę rozpykasz, chociaż dużym firmom zajmuje to koło miesiąca." - wybór dostawy to zaznaczenie punktu w formularzu. Nie wiem o czym mówisz. A przekierowanie na stronę płatności i sprawdzenie czy odebrano płatność to dwa pliki. To jest różnica pisania od zera vs presta czy inny wielki CMS gdzie wszystko zajmuje mnóstwo linijek kodu. "Tu znowu śmiechłem. Niedawno odkryliśmy w jednym z systemów, że można ręcznie zedytować ukryty input z ilością sztuk i wpisać 0,1, dzięki czemu kupisz wszystko za 10% ceny. To nie jest SQL injection." no to słuszna uwaga, żeby po prostu w PHP sprawdzać czy nie ma miejsc dziesiętnych. Ale to prosta rzecz. No i dobra załóżmy że kupiłeś 0.1 sztuk. I co wtedy? Przecież ja jako sprzedawca dostanę na zamówieniu 0.1 sztuki i się zorientuję że coś jest nie tak. Ja się bardziej obawiam o jakimś sposobie na wydobycie danych klientów bo kary za RODO są spore. I o tym mówię. 0.1 sztuki to żaden problem bo widać to od razu i nikt nie spakuje 0.1 sztuki do paczki widząc coś takiego, prawda? "Powinno dać Ci do myślenia, dlaczego gotowe sklepy internetowe mają tak dużo plików i są tak wielkie, a nie na 2000 linijek. Serio. Jak chcesz sprzedawać 5 rzeczy, to nie baw się w Presty, tylko wordpresik + woocommerce." - no mają dużo plików bo są bardzo elastyczne, obsługują wtyczki, motywy, szablony itp. Wordpress to ta sama historia. Mi szybciej napisać stronę dla kogoś od zera niż w WP, tym bardziej sklep. No a sam Woo ma wiele wad względem presty i nadaje się na sklepy bardzo małe albo określone. Co do możliwości presty... No właśnie tego programista nie zrozumie. Dla programisty jeśli np. jest formularz zamówienie to jest. A nie wie nawet, ze umieszczenie imienia i nazwiska w jednym polu może wpłynąć na sprzedaż. Nie wie, że czcionka przycisku "zamów" może wpłynąć na zakup. No jest dużo takich szczególików. Po prostu nie chcę rozmawiać o tym, bo to za długi temat i jałowy, bo jakby bez sensu jest ta rozmowa bo ja nie chcę nikogo przekonywać. Mi chodzi o to, że macie większe doświadczenie jako programiści i możecie powiedzieć mi jakie konkretne problemy mogą mnie spotkać podczas pisania takiego sklepu od zera. A nie o tym czy od strony marketingowej to dobry czy zły pomysł. Edytowanie takich szczegółów w presta zajmie mi więcej niż napisanie tego od początku. Tym bardziej że zanim połapię się co jest czym w takim kombajnie to miną wieki. "Próbuj, chętnie zobaczę za tydzień co masz Mogę nawet zrobić review i pokazać wszystkie dziury, bo pewnie bez problemu je znajdę, z zamkniętym jednym okiem." no bardzo chętnie skorzystam z takiej pomocy, bo na pewno będziesz mógł lepiej niż ja ocenić kwestie techniczne. Tylko najpierw wolałbym upewnić się czy warto zanim stracę czas na coś takiego. Może już na tym etapie możecie mnie przed czymś ostrzec. No z tym inputem 0.1 to słuszna uwaga, będę pamiętał, ale pytanie czy nie ma poważniejszych problemów które moglyby doprowadzić do wycieku danych. Dodam, że "silnik" to de facto mój sklep i nie będzie nikomu taki "silnik" udostępniany i nie musi być dostosowany do instalowania szablonów czy coś. Ja będę go edytował w kodzie. Tylko produkty będzie dodawało się przez formularz i jakieś podstawowe ustawienia, resztę bym edytował w kodzie źródłowym. Np. dodanie autorskiego systemu programu lojalnościowego na który nie ma wtyczki w presta zajmie dłużej niż HTML + PHP dla mnie. Chcę też mieć dokładną kontrolę nad każdym pikselem strony od strony designu. Chodzi mi o to, że obsługa CMS wymaga przestudiowania kodu CMS, Własna, prosta strona = prosty kod + znany nam kod. Łatwo go rozwijać nam i dodać jakiś moduł i nie trzeba płacić za wtyczki które i tak prezentują wizję autora wtyczki, a nie moją i musiałbym je przerabiać. Co jak ustaliliśmy jest nie możliwe bo co update musiałbym to robić od nowa, albo zrezygnować z aktualizacji.

No właśnie to napiszcie mi jakie problemy z zabezpieczeniem można dodać. Ten tydzień to nie jest powód do śmiechu. Takie stronki pisałem w tyle. Ja nie muszę mieć zaawansowanego systemu zarządzania treścią. Trzeba z robić stronę główną, kategorii, produktu i wczytywać odpowiednie dane na odpowiednią z bazy i w sumie to nie jest długie do napisania. Moje rozwiązanie nie będzie lepsze obiektywnie. Ale dla mnie. Z punktu widzenia sprzedawcy to wygląda inaczej niż programisty. Ja nie potrzebuję kombajnu który obsługuje miliony możliwości tylko to co mi jest aktualnie potrzebne, Co będę musiał zmienić mogę zmienić w kodzie, nie muszę być przygotowany na to, że sklep będzie w 100% obsługiwany przez geeków. Ja wiem, że presta z programistycznego punktu widzenia i możliwości jest genialna. Ale w biznesie liczy się optymalizacja czasu potrzebnego do stworzenia takiego sklepu i dodania do niego kolejnych opcji. W sprzedaży ważne jest co jaką czcionką, w którym miejscu i jak jest zapisane, a nie czy kod jest super. Dlatego wolałbym własne rozwiązanie, ale obawiam się głównie spraw bezpieczeństwa i tego, że o czymś nie wiem i mnie zaskoczy jakiś problem już w trakcie prac. Dlatego proszę o pomoc Was, bo pewnie są tu osoby z większym pojęciem o tym niż ja i mam nadzieję, że zwrócicie mi uwagę na jakieś konkretne problemy które będę musiał pokonać próbujac napisać taki sklep. Żebym wiedział na co dokładnie się piszę, o czym nie wiem ze względu na moje małe doświadczenie,

Przecież takie CMSy to głównie ogromny kod bo muszą obsługiwać wszystkie wtyczki itp. Napisanie sklepu internetowego na własne potrzeby od zera to maks tydzień programowania. W dodatku te CMSy są tak duże, że nikt ich już nie ogarnia i co chwile są jakieś newsy że jakieś wycieki spowodował bug w danej wersji. Nie wiem czy własny sklep zabezpieczyć to taki duży problem by było. Dać wszędzie PDO, żeby MySQL inject nie było, sprawdzać na każdej podstronie czy dana osoba faktycznie jest zalogowana i nie widzę za wielu problemów. Etapy... To nie jest sprawa dla programisty tylko specjalisty od sprzedaży. I tu jest problem. Presta ma wiele, wiele braków które dostrzegam w kwestii właśnie wpływania na sprzedaż. Metody płatności i dostaw to też nie sprawa dla programisty. Natomiast edytowanie takiego CMS to droga przez mękę trochęI(o ile chodzi ci o duże zmiany, a nie delikatne korekty) i wydaję mi się bardziej ryzykowne niż pisanie od zera sklepu. Natomiast nie wiem czy na pewno zabezpieczenie takiego sklepu jest takie proste. Dlatego zadałem to pytanie. Liczę na zwrócenie uwagi na jakieś konkretne problemy które mogą utrudnić pisanie bezpiecznego sklepu od zera, albo takich które da się rozwiązać, ale trzeba o nich pamiętać. Dużo łatwiej też byłoby mi edytować własny sklep napisany pewnie w maks 2-3 tyś linijek kodu który dobrze znam. Chciałbym usłyszeć o tym z jakich konkretnie powodów odradzasz tworzenie takiego sklepu bo mogłoby mi to pomóc podjąć decyzję. Sama edycja presty to dla mnie dwa duże problemy - duży kod, kod którego nie znam, w którym zajmie mi znalezienie czegokolwiek długo i mogę nie wiedzieć o czymś w kwestii bezpieczeństwa itp, a drugi to taki że zwyczajnie nie wiem co z aktualizacjami. No bo jak zrobić duże zmiany w sklepie tak, aby pogodzić je z aktualizacjami? Po prostu myślę, że napisanie od zera takiego sklepu zajmie mi dużo mniej niż odnalezienie się na tyle w takim ogromnym CMSie, żeby wprowadzić zmiany praktycznie we wszystkim, bo tak duże braki od strony marketingowej i sprzedażowej widzę w gotowych rozwiązaniach presta. A i rozwijanie takiego sklepu byłoby prostsze pod kątem programowania dla mnie(znam kod na pamięć i jest prostrzy). Moi koledzy po fachu godzą się na kompromisy w kwestie projektowania takiego sklepu i biorą co wtyczki oferują, ale ja wolałbym sklep który na prawdę spełnia wszystkie normy sprzedażowe i marketingowe na najwyższym poziomie. Żeby była jasność - to nie jest tak, że ja jestem w 100% przekonany do tego pomysłu. Po prostu nakreślam dlaczego tak bardzo wygodne to byłoby dla mnie, a oczekuję własnie wyprowadzenia mnie z ewentualnego błędu. Szczególnie pod kątem bezpieczeństwa takiego sklepu, bo nie wydaję mi się to skomplikowane, ale może to wynikać z mojej niewiedzy.

Chciał bym mieć pełną kontrolę nad działaniem i wyglądem mojego sklepu internetowego. Żeby cokolwiek zmienić w takiej Presta trzeba się natrudzić, a i tak możemy zrobić tylko to, na co znajdziemy jakąś wtyczkę. Nad większością rzeczy nie mam faktycznej kontroli. Z jakimi problemami wiązałoby się to, że napisałbym taki prosty silnik sklepu skrojony na miarę?

W przypadku szablonów do Woo jest do tego funkcja. No trudno. A wiecie może jak to rozwiązują firmy które hucznie ogłaszają edycje wtyczek na zamówienie? Druga sprawa jest jakiś kurs pisania wtyczek od zera w języku polskim?

Nie znajdę nic po Polski? W jaki sposób edytowa wtyczki, tak abym co ich aktualizację nie musiał tego robić od nowa?

Chciałbym nauczyć się edytować pluginy do prestashop i pisać nowe. Głównie z materiałami do nauki edycji gotowych mam problem, bo Google spami wynikami firm od edycji pod słowami kluczowymi. Znacie jakieś źródła do nauki? Polecicie coś? Najlepiej w języku Polskim, ale jeśli nie ma to trudno, może być i angielski.

W jaki rozsądny sposób można dopisać sobie takie rozszerzenia tak, aby działały one z GMS i były multiplatformowe?

Same save'y chciałem zapisywać w chmurze Google i nie chciałem właśnie korzystać z ini i to mnie ciekawi. Czy tak jak w dokumentacji muszą to być pliki ini czy własne też. Co do trzymania informacji o zakupach to jest pewien problem. U mnie będą to głównie lootboxy z przedmiotami użytkowymi. Które np. będziemy mogli dać naszym wojownikom, pracownikom, czy przydzielić do jakiegoś budynku i ciężko byłoby całość trzymać server-side. Z drugiej strony chyba będę musiał pomyśleć jednak nad tym głębiej, jak się pomyśli zawsze jakieś rozwiązanie się znajdzie, a tak jak mówisz, trzymanie wszystkiego po prostu w save'ie będzie zagrażało edytowaniem save'a. Tylko pytanie w jaki sposób to rozwiązać. Gracz może edytować np, żeby jego wojownik miał legendarny item. Mam taki pomysł, że każdy przedmiot gracza i jego "podwładnych" będzie musiał być też zapisany po stronie serwera i będą musiały się wzajemnie potwierdzać. Tylko co wtedy jeśli ktoś gra bez internetu? Mogę zrobić by się to synchronizowało dopiero po połączeniu do sieci, ale wtedy w taką kolejkę do synchronizacji też można dodać coś. Jeśli założymy, że samo otwarcie lootboxów będzie wymagało połączenia z siecią, to wciąż jest taki problem, że te same itemki będzie dało się też zdobyć w toku gry. Czyli mówiąc inaczej ktoś będzie mógł i tak je sobie dodać. Najlepszym rozwiązaniem byłoby trzymanie "zasobów gracza" po stronie serwera, ale jak w takim wypadku załatwić sprawę graczy którzy są np. chwilowo offline bo jadą pociągiem i stracili zasięg. Odebrać im opcje rozgrywki? Trochę kontrowersyjny pomysł.

Czy zarówno w iOS jak i Androidzie(bądź jednym z nich) jest opcja zakupów abonamentowych, tak żeby komuś kto podłączy kartę pobierało się automatycznie co miesiąc X pieniędzy? Czy w obu platformach da się ustalać różne ceny na różne regiony? Czy można stosować na tych platformach jakieś zewnętrzne/konkurencyjne rozwiązania bramek płatności niż te wbudowane w iTunes/Google Play?

Czyli jeśli chciałbym zrobić na urządzeniach Apple chmurę to muszę na własnym serwerze polegać? I czy wiecie może czy używanie własnej chmury w przypadku Google Play jest zgodne z regulaminem? Po co mi zapis w chmurze? No dlatego, żeby użytkownicy którzy nie wiedzą jak przerzucać zapisy między urządzeniami, nie irytowali się gdy im telefon padnie bądź go wymienią i cały zapis pójdzie sobie pobiegać krótko mówiąc. Zakładając, że potencjał gry biznesowy widzę głównie w lootboxach, a więc rozwoju światów, to nie mogę sobie na to za bardzo pozwolić by user tracił zapisy gry. Co do Google Play - tam jest instrukcja dla plików ini. Czy mój własny format może być uploadowany?

Może wytłumaczę Ci swój tok myślenia, a Ty mnie popraw w czym się mylę xd Chodzi o to, że telefon o rozdzielczości 1080p nie ma wcale ekranu większego niż 720p, tylko rozdzielczość. Więc a) jeśli zwiększę pole widzenia zamiast rozdzielczości tekstur to będzie wszystko słabiej widoczne, b ) wtedy jakość wyświetlanego obrazu będzie taka sama, a nie do tego chyba jest rozdzielczość. Wydaję mi się, że zrobię po prostu w 720p. Ale takie pytanie z natury tych głupich które jednak lepiej zadać, bo jak się coś źle rozumie to będzie jeszcze bardziej głupio: czy rozdzielczość w grze mobilnej to po prostu rozmiar view_wport/hport(zakładając tylko jeden view)?

tak, ale mam na myśli to, że grafika w większej rozdzielczości to więcej zajętego ramu przez zasoby. Zastanawiam się czy zrobienie gry w 1080p to nie jest za dużo dla low-endowych telefonów.

Jeszcze jedno - jak rozwiązać kwestię rozdzielczości? Robić w 720p(dla oszczędności ramu) i skalować view do 1080p na przykład, robic w 720p i zostawić view w 720p, czy może jeszcze jakoś inaczej?

Chyba zadałem za dużo pytań na raz. Więc zadam bardziej precyzyjne pytania i streszczę je. Moja gra będzie posiadała otwarty świat i potrzebuję możliwości zapisu do pliku tekstowego save'ów. Mam w związku z tym takie pytania: 1. Jakich funkcji użyć i do jakiej lokalizacji zapisywać grę żeby działał poprawnie i na iOS i na Androidzie i Windows/Mac/Linux? 2. Czy takie zapisy będą zgodne z chmurą na Google Play(i odpowiednikiem na iTunes jeśli jest - wybaczcie nie mam iPhone'a)? Taki plik tekstowy z savem mogę wysyłać na chmurę Google Play i odpowiednik na AppStore(pewnie jest tam też cloud save)?