Bardzo prosty blog

Question

Github

Blog

Mam do zaprezentowania przykład bardzo prostego bloga. Strona nie jest wykonana estetycznie i niestety bardzo zaplątałem się w kodzie. Spełnia jednak podstawowe założenia, co do działania.

-można przeglądać artykuły klikając w nawigację z prawej

-po przejściu na /admin.php mozna zalogować się do panelu, który stanowi powiedzmy BARDZO prosty CMS.

-login i hasło to asd. można edytować wybrane artykuły, usuwać je i dodawać nowe

-do dyspozycji mamy prosty edytor wykonany nieco toporną metodą na iFrame'ie na podstawie youtube'owego tutoriala(edytor nie działa poprawnie na moim telefonie, nie wiem jak z tabletem, zauważyłem też dziwne zachowania na Chrome'ie)

-kod wrzucony na GitHuba nie jest w pełni aktualny, bo pewne zmiany wprowadzałem już na serwerze

-kod na Githubie może też zawierać pewne elementy lub fragmenty, które nie zmieniają nic w projekcie

-klasa Controller nie ma prawie nic wspólnego z MVC, choć początkowo zamierzałem się do tego

-w zapytaniach pierwszy raz użyłem PDO. Czy prepare() zabezpiecza mnie przed wstrzyknięciem SQL-a?

-Config.php łączy z inną bazą danych w kodzie na Githubie

Wiem, że nie jest to projekt dostatecznie przygotowany do oceny, proszę jednak o zerknięcie i spędzenie choćby kilku chwil nad nim. Nie miałem zapału, żeby stylizować tę stronę, mam jednak nadzieję, że działa w miarę poprawnie i proszę o jakikolwiek, choćby negatywny odzew.

Answer 1

Garść ogólnych sugestii o samym kodzie:

• Od rozwiązania z nowym plikiem na każdą akcję się odchodzi - buduje się jeden routing, kieruje wszystkie żądania aplikacji na jeden plik z routingiem (np. index.php) i to tam zachodzi decyzja jaki kontroler wywołać. To co masz jest dość niewygodne, nieczytelne, powoduje chaos.
• W katalogu głównym są podstrony, pliki CSS, JS i jeszcze jakieś fragmenty templatek. Nie uważasz, że warto byłoby podzielić to na podkatalogi dla czytelności?
• Właściwie każde pole formularza powinno mieć etykietę (label).
• Strona nie jest responsywna.

•  <script type = "text/javascript" src = "panelScript.js"> </script>

  Atrybut type jest niepotrzebny. Mi szczerze mówiąc średnio podoba się robienie tylu spacji (zapisałbym np. src="" a nie src = ""), ale to już raczej kwestia bardziej wizualna. Pewne jest jednak, że trzymałbym się jednej konwencji, a u Ciebie widać raz tak a drugi raz tak.

• https://github.com/Excavelty/Blog/blob/master/addPost.php#L10 - polecam klasę DateTime zamiast funkcji date(), tu akurat mało się z tym dzieje, ale ogólnie klasa ta daje dużo większe możliwości i wygodniejsze operacje.

• Zamiast ręcznego dołączania plików proponuję autoloading przez Composera i PSR-4 - tu jest mało właściwych plików z klasami PHP, ale gdyby było ich więcej to dołączanie każdego byłoby niewygodne.

• https://github.com/Excavelty/Blog/blob/master/deleteArticle.php#L5 - widzę też wszędzie po kolei metody statyczne, które nie są specjalnie zalecane. Nie są też niczym złym, ale nie nadużywałbym ich po prostu tam gdzie nie trzeba.

• https://github.com/Excavelty/Blog/blob/master/getArticlesToNav.php#L6 w takim miejscu jak tutaj (gdy nic nie bindujesz) można po prostu użyć metody query().

• Kod HTML jest gdzieniegdzie mieszany z kodem PHP (logika z widokiem), to później bardzo utrudnia czytanie i rozumienie tego kodu. Możesz separować to samemu, albo skorzystać np. z systemu szablonów Twig.

• Kod PHP nie przestrzega też standardu PSR-2. Nie jest to oficjalny standard PHP, ale bardzo popularny, spotkasz go w bardzo wielu miejscach i myślę, że warto go znać (a ja lubię przestrzegać w swoich projektach).

 

 

-kod wrzucony na GitHuba nie jest w pełni aktualny, bo pewne zmiany wprowadzałem już na serwerze

Szkoda, po to jest GitHub czy systemy kontroli wersji, aby z nich korzystać. Poprawkami "prosto na produkcji" wszystko zaburzasz i narażasz na problemy.

-kod na Githubie może też zawierać pewne elementy lub fragmenty, które nie zmieniają nic w projekcie

To po co tam jest? Wprowadza to tylko nieporządek.

-w zapytaniach pierwszy raz użyłem PDO. Czy prepare() zabezpiecza mnie przed wstrzyknięciem SQL-a?

Tak, użycie bindowania zabezpiecza Cię w pełni przed atakiem sql injection.

-Config.php łączy z inną bazą danych w kodzie na Githubie

Dość oczywiste, najwygodniej zrobić jakiś plik z bazową konfiguracją i go mieć w repozytorium, a każdy indywidualnie tworzy na jego bazie plik właściwy, który powinien być ignorowany przez gita.

Comments

Bardzo dziękuję za tak treściwą ocenę:

-tak, kod jest chaotyczny, ale nie potrafię rozdzielić logiki od HTML-a, czasami po prostu nie wiem jak to zrobić, nie umiem sobie wyobrazić jak inaczej sobie poradzić

-co do PSR-2 to widzę, że zalecacie to bardzo często. Ja niestety z tego standardu wyniosłem chyba tylko tyle, że inaczej otwiera się klamry i żeby nie używać domknięcia tagu php(chyba, że inaczej się nie da, ale jak Pan zasugerował wyżej należy oddzielić PHP od HTML i już wtedy się da). Z tego co pamiętam to zostawia się też pusty wiersz, ale jakie są względy tego, to za bardzo nie wiem

-rzeczywiście kod powinien być aktualny, ale jestem dosyć niecierpliwy w tym względzie. Postaram się popracować nad lepsza organizacją kodu.

- co do metod statycznych to nie wiem jak sobie radzić. Na początku chciałem porobić singletony, ale odniosłem wrażenie, że jednak te instancje nie są zupełnie niezbędne.

---

-tak, kod jest chaotyczny, ale nie potrafię rozdzielić logiki od HTML-a, czasami po prostu nie wiem jak to zrobić, nie umiem sobie wyobrazić jak inaczej sobie poradzić

Polecam Twiga, on to na Tobie wymusi. W PHP nie będziesz wyświetlał nic, a w szablonach nie wykonasz kodu PHP. Aby cokolwiek do takiego szablonu przekazać będziesz musiał wywołać odpowiednią metodę i przekazać to przez argumenty.

-co do PSR-2 to widzę, że zalecacie to bardzo często. Ja niestety z tego standardu wyniosłem chyba tylko tyle, że inaczej otwiera się klamry i żeby nie używać domknięcia tagu php(chyba, że inaczej się nie da, ale jak Pan zasugerował wyżej należy oddzielić PHP od HTML i już wtedy się da). Z tego co pamiętam to zostawia się też pusty wiersz, ale jakie są względy tego, to za bardzo nie wiem

Ja zalecam często, bo jest po prostu w PHP bardzo popularny i bardzo często spotykany. Określa on sporo rzeczy, wszystkie są wypisane tutaj: https://www.php-fig.org/psr/psr-2/
Specjalnych względów części reguł może nie być żadnych - po prostu zostało przemyślane, że tak wydaje się czytelnie i tyle, ale też nigdy się nie zagłębiałem. Pasuje mi osobiście taki styl, co jednak nie oznacza że muszą tak pisać wszyscy.

-rzeczywiście kod powinien być aktualny, ale jestem dosyć niecierpliwy w tym względzie. Postaram się popracować nad lepsza organizacją kodu.

Warto.

- co do metod statycznych to nie wiem jak sobie radzić. Na początku chciałem porobić singletony, ale odniosłem wrażenie, że jednak te instancje nie są zupełnie niezbędne.

Robić normalne klasy i normalne obiekty - pisać tak, aby takie pojedyncze wyrwane z kontekstu metody były rzadkością, a nie zwyczajem.

Answer 2

Nie jest wcale źle - jest ładnie. Oryginalna, stonowana, dobrze dobrana kolorystyka. Prostota nigdy nie może być zarzutem, a często jest zaletą. Strona dobrze wyświetla się na mobillce w obu orientacjach. Czcionka jest wystarczająco duża i czytelna (na 8-calowym tablecie). Moim zdaniem osbna wersja na mobilkę jest w tym przypadku zbędna (chyba, że na komórkę). Jedynym widocznym mankamentem jest dość niewyraźne menu z prawej (trzeba poprawić kolor czcionki).

Comments

Dziękuję za opinię.

Answer 3

Tez aktualnie robie taki projekt :) ja jeszcze w panelu zarządzania pozwolilem sobie na różne kategorie artykułów też nie zle komplikuje :) do edytowania i tworzenia artykułu możesz użyć gotowego CKE editor ja osobiecie straciłem na nim włosy ale myśle zee i tak prostsze rozwiązanie niż samemu to teraz robic w css'sie. Powodzenia i wytrwałości

Comments

Bardzo dziękuję. Można wpisać sekcję, ale aktualnie nic to nie zmienia, chociaż przechowuję to w bazie danych. Również życzę wytrwałości:).