Wady pisania własnego sklepu internetowego od zera

[LolikZabójca2]

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ę?

[gnysek]

Co Ty za farmazony tutaj pitolisz? Chociaż zajrzałeś w dokumentację Presty? Możesz sobie nadpisać każdą klasę i każdy moduł, dodawać wtyczki, odpalać eventy (hooks). Robię sklepy internetowe od 10 lat w dużo większych systemach i nigdy nie było problemu z nadpisaniem czegoś - chociaż nie powiem, jest to pracochłonne, ale i tak na pewno mniej niż napisanie oryginalnego kodu. Jak nie masz kontroli nad kodem, jak presta jest otwartoźródłowa? Możesz z tym kodem zrobić wszystko. Zresztą, nawet wersje premium systemów sklepowych które znam pozwalają nadpisać wszystko, tylko nie można ich publicznie udostępniać (np. na githubie) w wersji premium.

 

Pisanie własnego sklepu skoro masz takie zerowe pojęcie o innych systemach, to proszenie się o kłopoty. Tak naprawdę to nawet nie masz zapewne pojęcia jakie etapy zamówienia wyróżniamy, jak powinna wyglądać kolejność przetwarzania koszyka i masz zerowe pojęcie o metodach dostaw/płatności, a będziesz musiał napisać wtyczki do tego od zera, bo większość firm daje wtyczki właśnie do gotowych sklepów. Zresztą, otwierając sklep pamiętaj też o tym, czego wymaga od Ciebie prawo, już poza programowaniem. Zwłaszcza, jak zostawisz dziurę w swoim systemie.

[LolikZabójca2]

8 godzin temu, gnysek napisał:

Co Ty za farmazony tutaj pitolisz? Chociaż zajrzałeś w dokumentację Presty? Możesz sobie nadpisać każdą klasę i każdy moduł, dodawać wtyczki, odpalać eventy (hooks). Robię sklepy internetowe od 10 lat w dużo większych systemach i nigdy nie było problemu z nadpisaniem czegoś - chociaż nie powiem, jest to pracochłonne, ale i tak na pewno mniej niż napisanie oryginalnego kodu. Jak nie masz kontroli nad kodem, jak presta jest otwartoźródłowa? Możesz z tym kodem zrobić wszystko. Zresztą, nawet wersje premium systemów sklepowych które znam pozwalają nadpisać wszystko, tylko nie można ich publicznie udostępniać (np. na githubie) w wersji premium.

 

Pisanie własnego sklepu skoro masz takie zerowe pojęcie o innych systemach, to proszenie się o kłopoty. Tak naprawdę to nawet nie masz zapewne pojęcia jakie etapy zamówienia wyróżniamy, jak powinna wyglądać kolejność przetwarzania koszyka i masz zerowe pojęcie o metodach dostaw/płatności, a będziesz musiał napisać wtyczki do tego od zera, bo większość firm daje wtyczki właśnie do gotowych sklepów. Zresztą, otwierając sklep pamiętaj też o tym, czego wymaga od Ciebie prawo, już poza programowaniem. Zwłaszcza, jak zostawisz dziurę w swoim systemie.

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.

[Konrad-GM]

1 godzinę temu, LolikZabójca2 napisał:

Napisanie sklepu internetowego na własne potrzeby od zera to maks tydzień programowania.

xD

 

1 godzinę temu, LolikZabójca2 napisał:

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.

xDD

 

Akurat większość problemów dot. zabezpieczenia to wbrew pozorom wcale nie SQL injection.
 

1 godzinę temu, LolikZabójca2 napisał:

Chciałbym usłyszeć o tym z jakich konkretnie powodów odradzasz tworzenie takiego sklepu bo mogłoby mi to pomóc podjąć decyzję.

Community i battle-testy.

 

1 godzinę temu, LolikZabójca2 napisał:

A i rozwijanie takiego sklepu byłoby prostsze pod kątem programowania dla mnie(znam kod na pamięć i jest prostrzy).

Czyli nie wiesz, co jest wymagane, stawiam na żadne bądź b. małe doświadczenie w programowaniu takich rozwiązań  

Nie twierdzę, że pisanie własnego sklepu to zło, sporo się można nauczyć, ale po tym co napisałeś stwierdzam, że nie masz doświadczenia z tematem (i dlaczego z góry zakładasz, że Twoje rozwiązanie będzie "lepsze"... jak nie będzie ).

 

[LolikZabójca2]

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,

[Konrad-GM]

Nie jestem jasnowidzem i nie mogę powiedzieć co jest niezabezpieczone, sporo zależy jak napiszesz taki sklep. Możesz poczytać sobie o łatkach zabezpieczeń innych kombajnów jak np. Wordpressa żeby mieć ogólny zarys czym jest chociażby taki XSS i np. w jakich niespodziewanych miejscach można umieścić kod  https://wordpress.org/news/category/security/
 

23 minuty temu, LolikZabójca2 napisał:

Z punktu widzenia sprzedawcy to wygląda inaczej niż programisty. (...) 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.

Może też dlatego @gnysek poleca użyć gotowca jak Presta, bo podejrzewam, że działa marketingowo a nie próbuje podbić rynek swoim autorskim super frejmworkiem 

Jak dla mnie pisz własny sklep, jeżeli to nie jest pisane dla klienta a tylko do celów własnych, to sporo się nauczysz i nabierzesz doświadczenia jak to działa od kuchni. PS. Presta też jest mocno podatna na zmiany i czcionki spokojnie mógłbyś zmienić  

Edit: Może rzuć okiem na OctoberCMS, dość ciekawe rozwiązanie, można w dość łatwy sposób pisać szablony bezpośrednio w HTMLu i doklejać kod PHP, mega prosty CMS i w dodatku podstawowa instalacja ma minimalnie wymagane pluginy.

 

[gnysek]

Śmiałem się długo, no ale odpiszę

Cytuj

Napisanie sklepu internetowego na własne potrzeby od zera to maks tydzień programowania.

xxxxD Nie wiesz nic o programowaniu w takim razie

 

Cytuj

Etapy... To nie jest sprawa dla programisty tylko specjalisty od sprzedaży

no ale kto te etapy programuje co? wiesz chociaż jaki jest standard branżowy w e-commerce?

 

Cytuj

Metody płatności i dostaw to też nie sprawa dla programisty.

buahahahahahaahah tutaj to się już turlałem srogo po podłodze. To 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.

 

Cytuj

Dać wszędzie PDO, żeby MySQL inject nie było

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.

 

 

 

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.

 

Zresztą nie wiem co aż tak bardzo chcesz zmieniać w gotowcach. Pewnie połowę rzeczy da się tam wyklikać tylko nie wiesz

 

 

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. Powiedz, jakie to braki ma Presta? Mogę zaproponować Magento, ale to jest dopiero kombajn.

 

[Threef]

15 godzin temu, LolikZabójca2 napisał:

biznesie liczy się optymalizacja czasu potrzebnego do stworzenia takiego sklepu

Dlatego nikt nie zabiera się za pisanie sklepu od podstaw (pomijając brak wiedzy) tylko od razu uderza się do agencji która zrobi to w krótkim czasie i bez komplikacji. Bazując na doświadczeniu i zaufanym teamie.

 

Chcesz sobie zacząć już to pisać? Zacznij od generowania PDF faktury. Po 2 tygodniach pracy nad tym przemyśl ponownie co chciałeś zrobić.
Tylko nie ośmieszaj się, że nie wiesz co ma być na fakturze. Zapytaj specjalisty od sprzedaży. On na 100% będzie wiedział.

[LolikZabójca2]

19 godzin temu, Konrad-GM napisał:

Może też dlatego @gnysek poleca użyć gotowca jak Presta, bo podejrzewam, że działa marketingowo a nie próbuje podbić rynek swoim autorskim super frejmworkiem 

 

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ł.

Cytuj

Jak dla mnie pisz własny sklep, jeżeli to nie jest pisane dla klienta a tylko do celów własnych, to sporo się nauczysz i nabierzesz doświadczenia jak to działa od kuchni. 

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.

[Konrad-GM]

Godzinę temu, LolikZabójca2 napisał:

Gnysek nie jest marketingowcem i dlatego nie do końca rozumie w czym rzecz

Podejrzewam, że Ty nie jesteś programistą, a marketingowcem, z którymi @gnysek ma pewnie masę doświadczenia w pracy ;P

 

Godzinę temu, LolikZabójca2 napisał:

Dlatego proszę ogólnie o konkrety, a nie "nie, bo nie i wybierz prestę"

Ale nie jesteś programistą, żeby zrozumieć na czym to polega, dlatego ciężko będzie przekazać Ci konkretną wiedzę techniczną (nie da się jej przekazać w jednym zdaniu, żeby napisać stronę ecommerce), skoro nie wiesz jakie to jest skomplikowane - chociażby taka obsługa bramek płatności, jeszcze gorzej, jak będzie trzeba obsłużyć ich kilka, kolejne abstrakcje, kolejne interfejsy które trzeba, niestety, zaprogramować. BTW. To jest prosta i konkretna odpowiedź z doświadczenia a nie z wywyższania się.  

 

Godzinę temu, LolikZabójca2 napisał:

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.

Albo napisz swoją wtyczkę, w takim np. Presta masz masę gotowych interfejsów w systemie i możesz je obsługiwać jak CI się tylko podoba bez myślenia, jak zaimplementować kolejkowanie zamówień czy obsługę bramek płatności, w tym skonfigurować serwer SMTP i wygenerować oraz wysyłać maile (np. z fakturami) do klientów - a to chyba jest ważne w marketingu?
 

Godzinę temu, LolikZabójca2 napisał:

szukam odpowiedzi technicznych dlaczego to miałby być zły pomysł.

Bo przeważnie nie jest to tak dobry pomysł jakby się wydawało, zwłaszcza, jak nie ma się doświadczenia z programowaniem. Starsi koledzy też pewnie tak myśleli, ja np. napisałem własny sklep dla własnych potrzeb (i kilka innych stron), masa zabawy z tym była... generalnie polecam napisać swój sklep, sporo się nauczysz i zrazisz do takich przekonań   

 

Godzinę temu, LolikZabójca2 napisał:

XSS - czy ten problem mnie wgl dotyczy skoro nikt poza mną nic nie będzie mógł umieścić na mojej stronie?(...) Nie planuję wielkiego CMSa tylko zwykłą stronkę ze sklepem i prostym formularzem dodawania produktów z panelu admina.

Ale tu jest już jakaś funkcja, przez którą będziesz umieszczał dane, dodajmy do tego formularz zgłoszeniowy, że ktoś chce kupić jakiś przedmiot, może nawet bramkę płatności  XSS podałem dla przykładu, pierwsza strona Google pod hasłem "common ecommerce website vulnerabilities" - https://lirax.org/6-common-security-vulnerabilities-in-e-commerce-systems/

 

Godzinę temu, LolikZabójca2 napisał:

October_(CMS) - poczytam, dzięki

Jak dla mnie fajny CMS, kilka stron na nim postawiłem i działa naprawdę nieźle - w tym w łatwy sposób można dodawać podstrony bezpośrednio w HTMLu (z wbudowanym silnikiem template'ów). Generowałem w nim PDFy, wysyłałem customizowane maile, zarządzałem użytkownikami (poza adminami/redaktorami ofc.)... Ale nie stawiałem na nim sklepów, tutaj własną wtyczkę musiałbyś dopisać (co jest banalne w October CMS), albo skorzystać z wtyczek z marketu

[LolikZabójca2]

Cytuj

Podejrzewam, że Ty nie jesteś programistą, a marketingowcem, z którymi @gnysek ma pewnie masę doświadczenia w pracy ;P

 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.

 

Cytuj

Ale nie jesteś programistą, żeby zrozumieć na czym to polega, dlatego ciężko będzie przekazać Ci konkretną wiedzę techniczną (nie da się jej przekazać w jednym zdaniu, żeby napisać stronę ecommerce), skoro nie wiesz jakie to jest skomplikowane - chociażby taka obsługa bramek płatności, jeszcze gorzej, jak będzie trzeba obsłużyć ich kilka, kolejne abstrakcje, kolejne interfejsy które trzeba, niestety, zaprogramować. BTW. To jest prosta i konkretna odpowiedź z doświadczenia a nie z wywyższania się.  

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.

 

Cytuj

Bo przeważnie nie jest to tak dobry pomysł jakby się wydawało, zwłaszcza, jak nie ma się doświadczenia z programowaniem. Starsi koledzy też pewnie tak myśleli, ja np. napisałem własny sklep dla własnych potrzeb (i kilka innych stron), masa zabawy z tym była... generalnie polecam napisać swój sklep, sporo się nauczysz i zrazisz do takich przekonań   

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

 

Cytuj

Ale tu jest już jakaś funkcja, przez którą będziesz umieszczał dane, dodajmy do tego formularz zgłoszeniowy, że ktoś chce kupić jakiś przedmiot, może nawet bramkę płatności  XSS podałem dla przykładu, pierwsza strona Google pod hasłem "common ecommerce website vulnerabilities" - https://lirax.org/6-common-security-vulnerabilities-in-e-commerce-systems/

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.

Cytuj

Cross-site Scripting:

The end user is always vulnerable to this type of attack. The cross-site scripting or XSS ref 6 attack can be deadly when the enemy operates. When it occurs, the process usually leverages 2 major factors. 

1. The confidence the end-user has in a URL that contains the affected site’s name

2. The lack of output and input verification being performed by the web app

Jak mam to rozumieć? 

[Threef]

Nie rozumiesz. Stoisz twardo przy swoim pytając jakie możesz napotkać problemy, podczas gdy jest ich setka. Siądź chwilę i rozpisz sobie co jest ci potrzebne do twojego sklepu. Samo wyświetlanie produktów z bazy to nic. Pomyśl o procedurze sprzedaży. Wystawiania faktur, pilnowaniu czy produkty są "in stock". Procedurach bramek płatnościowych. Przechowywaniu danych usera. GDPR. Rozliczaniu płatników z poza polski.

Nie będę wymieniał już. To ty twierdzisz że "programiści gdy projektują takie rzeczy to robią to technicznie, a nie czując potrzeby klienta" więc chyba wiesz czego potrzebuje twój sklep.

Jak będziesz miał taką listę to możesz zacząć gdybać ile czasu by ci to zajęło. I to powinien być twój punkt wyjścia. W tym momencie tylko marnujesz siły próbując pytać o szczegóły.

[LolikZabójca2]

2 godziny temu, Threef napisał:

Nie rozumiesz. Stoisz twardo przy swoim pytając jakie możesz napotkać problemy, podczas gdy jest ich setka. Siądź chwilę i rozpisz sobie co jest ci potrzebne do twojego sklepu. Samo wyświetlanie produktów z bazy to nic. Pomyśl o procedurze sprzedaży. Wystawiania faktur, pilnowaniu czy produkty są "in stock". Procedurach bramek płatnościowych. Przechowywaniu danych usera. GDPR. Rozliczaniu płatników z poza polski.

Nie będę wymieniał już. To ty twierdzisz że "programiści gdy projektują takie rzeczy to robią to technicznie, a nie czując potrzeby klienta" więc chyba wiesz czego potrzebuje twój sklep.

Jak będziesz miał taką listę to możesz zacząć gdybać ile czasu by ci to zajęło. I to powinien być twój punkt wyjścia. W tym momencie tylko marnujesz siły próbując pytać o szczegóły.

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.

[Threef]

Dalej nie zrozumiałeś. Siądź sam i przemyśl co ma mieć twój sklep. Mając taką listę możesz wrócić z konkretnymi pytaniami.

 

GDPR widzę że już nie rozumiesz. Nie jest "dane mają być bezpieczne" bezpieczne mają być w każdym serwisie który operuje na danych. GDPR ma pozwalać użytkownikowi na wgląd w swoje dane, możliwość ich edycji oraz usunięcia. I to nie jest zwykłe "usuń z MySQL".

 

Jeżeli chcesz dalej próbować to droga wolna. Ale systemy jak Presta i Magento powstały właśnie po to aby uniknąć 80% tych problemów. Nie łatwo się się je konfiguruje ale też nie robi się tego samemu. 

[Chell]

• integracja stocków z serwisem magazynowym
• koszyk
  • promocje
  • rabaty
  • potencjalny race condition ze wszystkim, co "daje" jakąś kasę userowi
• wysyłka
  • integracja z dostawcami, chociaż najdrobniejsza, żeby user znał chociaż numer przesyłki
  • koszty zależne od regionu / wagi przesyłki
• generowanie
  • maili aktywacyjnych, maili potwierdzających zamówienie
  • pdfów z umowami, fakturami
• security
  • rejestracja, logowanie
  • nie trzymanie haseł w plainie
  • reset hasła
  • ogólnie cała autoryzacja i autentykacja
• bramki płatnicze
  • generowanie linków
  • powrót usera
  • case udany/nieudany
  • obsługa callbacków z bramki
  • co jakiś czas zbiorcza odpytka bramki o status wszystkich płatności, jakby callback z jakiegoś powodu nie przeszedł
  • wygasanie płatności 
  • ogólnie licz 4 dni robocze na bramkę jeżeli już kiedyś jakąś podpinałeś + 3 dni na rzeczy, które powinny działać, bo są wg. dokumentacji, ale z jakiegoś powodu nie działają (ze 2 miesiące temu podpinałem Soisy, wymieniłem z nimi kilka maili o co chodzi, oczywiście nic mi nie umieli powiedzieć, po czym ich zjebałem że wg dokumentacji callback jest w jsonie, więc raczej nie spodziewasz się nulla w body, a dane tak naprawdę przychodzi w x-www-form-urlencoded - aż dodali to do dokumentacji)
• GDPR
  • anonimizacja usera tak, żeby było legalnie, ale żeby nie tracić całych serii danych z nim związanych

piszesz, że user będzie wprowadzać ilości produktów, mieć konto z danymi i w ogóle - przecież pisałeś, że tylko Ty będziesz wprowadzał treści na stronę? to jak to jest, to będzie podatne na XSS czy nie?

"przygotowanie wydruku FVAT, albo ustawienie ilości w magazynie to żaden problem" - to napisz to fakturowanie, skoro na cały projekt zakładasz tydzień to pewnie z tym się wyrobisz w 2h

"autorski system programu lojalnosciowego" - have fun, w firmie sporo takich tworzymy i obsługujemy, i to wszystko co piszesz (i co ja pisze) to tylko wierzchołek góry lodowej funkcjonalności programu lojalnościowego, a każdy taki system jest utrzymywany i rozwijany przez minimum 3 programistów 8-16

przyznaj się, chcesz po prostu własny Avon ale nie chcesz bulić jakiejś firmie bańki za kilka podstron

 

edit: to totalnie brzmi jakbym cie zniechęcał, ale nie zrozum mnie źle - to, tak, jak pisze Konrad, bardzo ciekawy i rozwijający projekt, ale podchodzisz do tego wszystkiego zbyt olewczo, i zaprzegasz w to kasę klientów mimo tego, że masz zerową świadomość ryzyka

[gnysek]

10 lat piszę sklepy internetowe, zrobiłem ich ponad 50, piszę czasem sam bramki do nowych systemów, czy systemy dostaw, a ten mi mówi, ze to kilka linijek... to nie jest tak, ze ja je piszę pod jakiś system, dlatego zajmują mnóstwo kodu, to jest tak, że się nie da krócej, bo ja już znam system i wiem gdzie oszukać i czego nie muszę zrobić, byle to działało. Jak mówię - nie masz nawet pojęcia za co się bierzesz, albo w ogóle nie chcesz 90% funkcjonalności sklepu, które są przydatne MARKETINGOWO i dla SPRZEDAWCY a nie dla programisty. Sporo rzeczy przyspiesza prace, jak da się je zobaczyć w panelu admina (status zamówienia, numery paczek, status płatności) ale rozumiem, wolisz je sprawdzać osobno. I bez odpowiedniego flow dla klienta.

 

Pytanie czy robisz prawdziwy sklep, czy tylko mikro-sklepik na dwóch klientów rocznie.

[LolikZabójca2]

12 godzin temu, Threef napisał:

Dalej nie zrozumiałeś. Siądź sam i przemyśl co ma mieć twój sklep. Mając taką listę możesz wrócić z konkretnymi pytaniami.

 

GDPR widzę że już nie rozumiesz. Nie jest "dane mają być bezpieczne" bezpieczne mają być w każdym serwisie który operuje na danych. GDPR ma pozwalać użytkownikowi na wgląd w swoje dane, możliwość ich edycji oraz usunięcia. I to nie jest zwykłe "usuń z MySQL".

 

Jeżeli chcesz dalej próbować to droga wolna. Ale systemy jak Presta i Magento powstały właśnie po to aby uniknąć 80% tych problemów. Nie łatwo się się je konfiguruje ale też nie robi się tego samemu. 

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.

Cytuj

piszesz, że user będzie wprowadzać ilości produktów, mieć konto z danymi i w ogóle - przecież pisałeś, że tylko Ty będziesz wprowadzał treści na stronę? to jak to jest, to będzie podatne na XSS czy nie?

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.

Cytuj

"przygotowanie wydruku FVAT, albo ustawienie ilości w magazynie to żaden problem" - to napisz to fakturowanie, skoro na cały projekt zakładasz tydzień to pewnie z tym się wyrobisz w 2h

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?

Cytuj

"autorski system programu lojalnosciowego" - have fun, w firmie sporo takich tworzymy i obsługujemy, i to wszystko co piszesz (i co ja pisze) to tylko wierzchołek góry lodowej funkcjonalności programu lojalnościowego, a każdy taki system jest utrzymywany i rozwijany przez minimum 3 programistów 8-16

przyznaj się, chcesz po prostu własny Avon ale nie chcesz bulić jakiejś firmie bańki za kilka podstron

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).

 

Cytuj

edit: to totalnie brzmi jakbym cie zniechęcał, ale nie zrozum mnie źle - to, tak, jak pisze Konrad, bardzo ciekawy i rozwijający projekt, ale podchodzisz do tego wszystkiego zbyt olewczo, i zaprzegasz w to kasę klientów mimo tego, że masz zerową świadomość ryzyka

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.

 

Cytuj

1. integracja stocków z serwisem magazynowym
2. koszyk
   1. promocje
   2. rabaty
   3. potencjalny race condition ze wszystkim, co "daje" jakąś kasę userowi
3. wysyłka
   1. integracja z dostawcami, chociaż najdrobniejsza, żeby user znał chociaż numer przesyłki
   2. koszty zależne od regionu / wagi przesyłki
4. generowanie
   1. maili aktywacyjnych, maili potwierdzających zamówienie
   2. pdfów z umowami, fakturami
5. security
   1. rejestracja, logowanie
   2. nie trzymanie haseł w plainie
   3. reset hasła
   4. ogólnie cała autoryzacja i autentykacja
6. bramki płatnicze
   1. generowanie linków
   2. powrót usera
   3. case udany/nieudany
   4. obsługa callbacków z bramki
   5. co jakiś czas zbiorcza odpytka bramki o status wszystkich płatności, jakby callback z jakiegoś powodu nie przeszedł
   6. wygasanie płatności 
   7. ogólnie licz 4 dni robocze na bramkę jeżeli już kiedyś jakąś podpinałeś + 3 dni na rzeczy, które powinny działać, bo są wg. dokumentacji, ale z jakiegoś powodu nie działają (ze 2 miesiące temu podpinałem Soisy, wymieniłem z nimi kilka maili o co chodzi, oczywiście nic mi nie umieli powiedzieć, po czym ich zjebałem że wg dokumentacji callback jest w jsonie, więc raczej nie spodziewasz się nulla w body, a dane tak naprawdę przychodzi w x-www-form-urlencoded - aż dodali to do dokumentacji)
7. GDPR
   1. anonimizacja usera tak, żeby było legalnie, ale żeby nie tracić całych serii danych z nim związanych

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ąć?

 

Cytuj

10 lat piszę sklepy internetowe, zrobiłem ich ponad 50, piszę czasem sam bramki do nowych systemów, czy systemy dostaw, a ten mi mówi, ze to kilka linijek... to nie jest tak, ze ja je piszę pod jakiś system, dlatego zajmują mnóstwo kodu, to jest tak, że się nie da krócej, bo ja już znam system i wiem gdzie oszukać i czego nie muszę zrobić, byle to działało. Jak mówię - nie masz nawet pojęcia za co się bierzesz, albo w ogóle nie chcesz 90% funkcjonalności sklepu, które są przydatne MARKETINGOWO i dla SPRZEDAWCY a nie dla programisty. Sporo rzeczy przyspiesza prace, jak da się je zobaczyć w panelu admina (status zamówienia, numery paczek, status płatności) ale rozumiem, wolisz je sprawdzać osobno. I bez odpowiedniego flow dla klienta.

 

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 

[gnysek]

2 godziny temu, LolikZabójca2 napisał:

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.

 

Ale przepraszam, myślisz, ze kto mi zleca zadania, programista? Pfff. Zadania zleca klient, który zaprogramować, to potrafi najwyżej pralkę. I ja wszystko robię tak, jak on chce i jak wg. jego wizji ma to wyglądać, a nie ja wg. mojej wizji. Jak wrzucam 30 różnych skryptów śledzących, obrazków, google tag managerów, facebook pikseli i chuj wie czego jeszcze, to nie dla tego, że programista uważa, że tak jest lepiej, tylko dla tego, ze przyszedł MARKETINGOWIEC i SPECJALISTA OD SPRZEDAŻY i on takie gówna każe wklejać. Także jest dokładnie na odwrót niż myślisz, bo programiści to są leniwe istoty i robią na skróty, a same formularze i proces sprzedaży upraszczaliby jak się da. Dla mnie wystarczą dwa statusy zamówienia - "oczekujące" i "zrealizowane", ale pan właściciel sklepu potrzebuje 50, a potem sam się w tym gubi. A to okienko tutaj, a to newsletter tam, a to bannerek w tym miejscu, a to pierdoła w tamtym. Każdy sklep ma naprawdę inne wymagania i robienie projektu już pod dwa wymaga, żeby pisać modułowo. I tak się to rozrasta potem.

 

Zapytałeś co musisz wiedzieć przed robieniem sklepu, my, z doświadczeniem mówimy, że na takie coś nie ma się co porywać, bo to jest za duży projekt, i to nie dla tego, że piszemy sklepy na gotowcach, tylko dla tego, że w ogóle mamy doświadczenie w programowaniu (którego Ty w ogóle nie masz, skoro mylisz bezpieczeństwo sklepu z używaniem PDO), albo twierdzisz, że coś da się napisać w godzinę, skoro nawet zrobienie HTMLa i CSSa dla niektórych rzeczy zajmie dłużej, żeby coś się prawidłowo wyświetlało.

 

Owszem, jak chcesz to próbuj, ja jednak nadal będę twierdził, że użycie gotowca jest szybsze, niż pisanie samemu. Ja bym się tego nie podjął, bo żeby zrobić coś uniwersalnego, dla więcej niż jednej osoby wiem, że musiałbym spędzić chyba z kilka lat, żeby to napisać.

 

Jeśli jednak ktoś o sklepach mówi CMS, no to w sumie wszystko mówi na temat poziomu rozmowy i tego, ze nie rozumie faktów które przytaczamy. Żaden z systemów sklepowych, Magento, Presta, Sylius, WooCommerce, OpenCart, ZenCard czy X-Card nie jest CMSem. Część z nich posiada moduł CMS, część z nich działa pod CMSami, ale żaden nie jest.

 

Jedyne z czym się zgodzę, to że prowadzenie sklepu niestety jest drogie i fajnie minimalizować koszty, ale właśnie skorzystanie z gotowca kosztuje w sumie 0zł. I naprawdę sporo da się wyklikać, bez programowania i jestem pewien, że jakbyś powiedział czego potrzebujesz, to większość tych funkcji jest bez wtyczek. Martwisz się też co w momencie, gdy sklep ma aktualizacje. No cóż, to patrzysz co zaktualizowali, jeśli trzeba to poprawiasz kod (chociaż jak poprawka dotyczy jedynie bezpieczeństwa, to jeśli musisz coś poprawić to sam miałeś błąd bezpieczeństwa) i tyle. Nie wrzucasz przecież poprawki na żywca na serwer na pałę. A co do argumentów, że znajomi mają mnóstwo malware itp. - no cóż, jak nie potrafią skonfigurować dobrze serwera, to mają. U mnie klienci nigdy nie mieli z tym problemu, bo zawsze chociażby zmieniamy ścieżkę do panelu admina, blokujemy ją pod konkretne IP, dodajemy htpassword czy nawet wymagamy konkretnego ciasteczka w przeglądarce najpierw. I to są akurat rzeczy do zrobienia w godzinę.

 

Jestem też ciekaw tych faktur. Generujesz fakturę, wtedy wysyłasz ją księgowej i jak będzie zła to poprawisz? Coś chyba tutaj jest nie tak, przecież jak user już pobrał fakturę, to po ptakach. A jak ją sobie wpiszę w KPiR to co, potem mi się skarbówka przywali, bo nie umiałeś dobrze faktury wygenerować?

 

Nie mniej, czekam na pierwsze efekty, na pewno podpowiemy co jest źle i ostrzeżemy przed jakimś fatalnym błędem, zanim pakujesz się w maliny. Pamiętaj tylko, że od początku ostrzegaliśmy, że na maliny w ogóle masz nie iść

[Threef]

 

10 godzin temu, LolikZabójca2 napisał:

muszę wszystko zbadać bardzo dokładnie. Każdą możliwość. Chcę podejmować świadomie każdą decyzję, opierając się na faktach, a nie przeczuciach.

 

10 godzin temu, LolikZabójca2 napisał:

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.

 

Twoje podejście w tym momencie to: "Jakoś się zrobi", "przecież to tylko podpięcie", "damy radę", "wiem jak". Ale wszystko wskazuje, że nie masz pojęcia jak. Jest to naiwne myśleć, że każdy może siąść i zaplanować, a co więcej napisać sklep internetowy.

 

Samochód też ma 4 koła, drzwi, karoserię, i silnik, który jeździ na paliwo. Paliwo trzeba podawać i działa. Jak ktoś chce to można radyjko zamontować... xD

[gnysek]

Ja myślalem, że ten sklep już powstał, to miało być dwa dni pisania Ale ostatnie zdanie Threefa mówi wszystko w temacie na temat skomplikowania sprawy.

[Ranmus]

@LolikZabójca2

 

Dziwię się, że Gnyskowi i spółce chce się z Tobą jeszcze pisać. Po tym co piszesz ewidentnie widać, że masz bardzo małe doświadczenie w ecommerce i mimo tego co Ci piszą rozmówcy, starasz się z nimi dyskutować o rzeczach, o których nie masz pojęcia ze względu na właśnie brak należytego doświadczenia. Nie chcę Cię urazić, no ale nie jesteś partnerem do rozmowy z nimi na takie tematy, skoro i tak wiesz swoje. To ja nie robię w ecommerce (bardziej duże systemy specjalistyczne, niesprzedażowe) a mam większą wiedzę na ten temat od Ciebie i mogę jedynie potwierdzić to co pisze reszta. Nawet nie zdajesz sobie sprawy z tego, że zahaczasz tylko o wierzchołek góry lodowej. Nie znasz realnych case'ów, konsekwencji spieprzenia czegokolwiek w tym zakresie. Śmiesznie się czyta tę całą dyskusję.

[Vianom]

Nie wiem jak Wam, ale mi to trochę trąca trollingiem, oby to była prawda  

Jeśli nie, to chyba mamy dobry przykład efektu z wykresu poniżej.