Pliki html czy php? Strona zbudowana w html+css.

Możesz przyjąć taki podział:

• index.php, w którym decydujesz na podstawie adresu, która strona ma być ładowana np. home.php lub blog.php
• page/home.php, który składa się z powtarzalnych części strony np. template/header.php, template/footer.php
• page/blog.php, j/w + na podstawie adresu umieszczasz zmienną treść np. z bazy danych, pliku

Zostan przy sposobie 1. uzyj css i js do zalaczania plikow no menu, nie musisz wtedy zmieniac kazdego pliku html

A czy wadą tego rozwiązania, ładowania menu za pomocą js nie jest to, że jak ktoś ma wyłączoną obsługę js to wtedy lipa, nie będzie menu?
ps. choć użytkownicy tej strony raczej nie grzebią w takich ustawieniach :)

@kartonpierwszy: Mało kto ma wyłączony JS, tym bym się nie przejmował. A jak ma, to walisz stosowany komunikat, że potrzebna jest włączona obsługa JS.

wwzsyteki szanuajce sie strony powinny miec komuniakt ze masz miec wlaczone JS a jak jestes na IE albo EDGE to ze tych przegaldarek nie obslugujemy, i z dopiskiem PRECZ LAMUSY! :)

Jeśli masz statyczną stronę, tylko HTML i CSS, i chcesz zwiększyć jej jakoś poprzez jej modularyzację, to ja raczej poszedłbym we frontowe technologie.

Widać, że Twoja strona nie potrzebuje backendu, więc nie potrzebnie byłoby go dodawać. Moim zdaniem mógłbyś stworzyć swój front albo w Vanilla JS, albo w Vue, albo w React albo Angular. To jest oczywiście trochę wyższa szkoła jazdy niż sam HTML i CSS, ale to byłby krok w dobrą stronę. Na pewno lepszą niż modularyzacja widoku w PHP.

Frameworki/biblioteki js-owe i inne odpadają. Wymaganiem klienta było bez takich dodatków, lub jak najmniej. Stąd html+css. Żadnego backendu nie potrzebuje, to statyczna strona. Poprzez include chciałem tylko ułatwić późniejszą edycję.

kartonpierwszy napisał(a):

Frameworki/biblioteki js-owe i inne odpadają. Wymaganiem klienta było bez takich dodatków, lub jak najmniej. Stąd html+css.

Ale to jest jakieś sensowne wymaganie? Może klient po prostu nie wie o czym mówi, i nie wie czego chce. Być może jest spora szansa że nawet by się nie zorientował w jakiej technologii napisałeś stronę?

Żadnego backendu nie potrzebuje, to statyczna strona. Poprzez include chciałem tylko ułatwić późniejszą edycję.

No, ale jeśli chcesz dodać PHP do swojego projektu, to to co zrobiłeś to własnie dodałeś backend :D

Przeglądarki nie wspierają include'ów HTML'a (no chyba że na <iframe/>ach), więc jedyne co Ci pozostaje to albo modularyzacja na froncie, albo na backendzie. Przy czym backendu za bardzo nie potrzebujesz, więc moim zdaniem szkoda go dodawać niepotrzebnie. Nie mógłbyś takiej strony hostować np na Github Pages wtedy.

Klient wie co mówi raczej, ma firmę hostingową od lat. Także przy tym zostajemy. Dla mnie także super projekt, bo przetyrałem się przez html+css :). Same kursy to jednak tylko wprowadzenie. Prawdziwy projekt super weryfikuje wiedzę i uczy.

Co do tego php i backendu, fakt, ale to jakby minimalna ingerencja. Jakie są minusy tego, że wrzucę to w php względem zostawienia tego w html? Odpada hostowanie np na ghpages, co jeszcze? To nie problem na tą chwilę.

kartonpierwszy napisał(a):

Klient wie co mówi raczej, ma firmę hostingową od lat. Także przy tym zostajemy. Dla mnie także super projekt, bo przetyrałem się przez html+css :). Same kursy to jednak tylko wprowadzenie. Prawdziwy projekt super weryfikuje wiedzę i uczy.

Ja bym powiedział że "prawdziwy projekt super weryfikuje czy hacki działają czy nie i uczy workaroundów które nie są książkowe".

Ale co ja tam wiem.

No to zrob mu na php zebys mial latwe dolaczanie stron i tyle. Albo moze w ogole po wejsciu na strone niech sie sciga plik Word czy Excel i ludzie se beda sami czytali. "klient wie co mowi" - to tylko tobie sie tak wydaje

kartonpierwszy napisał(a):

Same kursy to jednak tylko wprowadzenie. Prawdziwy projekt super weryfikuje wiedzę i uczy.

Jeśli poznajesz jakiś kolejny region wiedzy z dobrego źródła, kursy, książki, wiedza innych użytkowników, i wydaje Ci się że nie mają zastosowania w prawdziwym życiu, to na 99% ich nie zrozumiałeś, albo próbowałeś je niepoprawnie zaaplikować. Te rzeczy dlatego są w książkach i kursach dlatego że działają i zostały sprawdzone w boju, nie są tam "po to żeby były".

Zgadzam się, z pewnością nie zrozumiałem = myślałem że rozumiem. I właśnie robienie takiego projektu, który ma działać, pozwala to zweryfikować, wiedzę wyniesioną z nauki ... z różnych źródeł.
Ok, dzięki za pomoc, z Worda i Excela zrezygnuje :).
Pozdrawiam.

kartonpierwszy napisał(a):

Cześć Panie i Panowie, mam pytanie odnośnie 1ego mojego projektu/strony.

Robię stronę internetową, html + css. Strona główna typu onePage, do tego ok 15 podstron. Zastanawiam się, czy zostawić wszystko w plikach html, tak po prostu, jak jest zrobiona, czy przerobić stronę na pliki php, żeby móc skorzystać z include i poszczególne elementy, jak sekcje/menu powyciągać do osobnych plików php i je zaciągać do strony/podstron: Zastanawiam się nad:

1. Zostawiam w html - wszelkie zmiany w powtarzających się elementach trzeba ogarniać na każdej podstronie.
2. Dziele wszystko, co się da na mniejsze elementy do plików php i zaciągam je za pomocą include lub require do danej strony/podstrony. Nie wiem, jakie są wady tego rozwiązania względem 1ego, ale z pewnością zaletą jest wprowadzanie zmian danego elementu tylko w 1ym miejscu.
3. Połączyć oba sposoby ( jeśli tak się da i ma to sens?). Widzę to tak, że mam np główną stronę (w php czy html?) i tylko niektóre elementy, np. powtarzające się, zaciągam za pomocą include/require. Np menu, stopkę.
   Jak najlepiej to zrobić. Jakie są wady i zalety poszczególnych rozwiązań?
   Nie znam php, zastanawiam się tylko nad użyciem include do mojego pomysłu.
   Będę wdzięczny za pomoc.

Okej, powiem Ci dokładnie czemu uważam Twój pomysł za średni.

Teraz, kiedy Twoja strona jest tylko w HTML i CSS, to praktycznie jest "gotowa". Możesz komuś dać takie statyczne pliki, i on może je wrzucić gdziekolwiek, i to jest dokładnie to co zobaczy odwiedzający Twoją stronę. Moim zdaniem to co teraz masz, jest bardzo dobre.

Ty jednak chcesz wprowadzić jakąś modularność do swojego rozwiązania, spodziewam się że po to żeby nie mieć duplikacji w różnych podstronach. Masz dwa "standardowe" wyjścia:

• Wyjście frontowe, tzn dodać jakiś JS'a (Vanilla, Vue, React, Angular, od biedy jQuery), i zbudować w przeglądarce wynikowy kod. Moim zdaniem to byłoby dobre, bo mając coś takiego, nadal masz same static files'y które możesz wrzucić gdziekolwiek. Miejsce na którym będą stać (CDN, Gituhub Pages, dowolny server) nie musi o nich nic wiedzieć, wystarczy że je zaserwuje. Nie musisz nawet mieć środowiska uruchomieniowego tam gdzie będą stać, wystarczy sam Apache lub Nginx.
• Wyjście backendowe. Ty na to mówisz "dodanie include()'ów i require()'ów", ale tak na prawdę to co chcesz zrobić, to nie mieć już statycznych plików HTML/CSS, tylko aplikację internetową która je generuje w locie. I to ma taką wadę, żę:
  • Po pierwsze, przywiązanie do jednego języka programowania, nie ważne czy użyjesz PHP, Python, Ruby czy dowolny inny, jeśli zaczniesz pisać w nim, to jesteś do niego przywiązany.
  • Po drugie, nakładasz wymagania na server który będzie je serwował, ponieważ on już nie tylko musi mieć server (jak Apache/Nginx) ale musi mieć też środowisko uruchomieniowe w postaci PHP lub Pythona lub co tam sobie wybierzesz, dodatkowo w odpowiedniej wersji. Dużo dodajesz nowych wymagań, a zysk dosyć mały.

Wiec, jeśli już koniecznie chcesz to zrobić w PHP i dodawać include() i require(), to być może mógłbyś to potraktować jako "generator stron", zamiast stronę?

Tzn, dodałbyś u siebie swoje include'y, i użyłbyś swojego lokalnego PHP'a żeby wygenerować wynikową stronę, i tą wynikową stronę klient by sobie wrzucił na swój server?

Jeśli poszedłbyś w taką stronę, to masz dwa wyjścia:

• Albo korzystać z PHPowych include()ów i require()ów, czyli po prostu pozamieniać swoje pliki .html na .php, co jest moim zdaniem w miarę prostę, ale gorsze.
• Napisać swój generator. Robota na pół dnia, ale za to odseparujesz się od języka programowania, i będziesz mógł sam kontrolować to które kawałki są wsadzane gdzie.

Ok, to już nabiera kolorów w mojej głowie.

@TomRiddle jest jeszcze trzeci sposób, budowanie htmla webpackiem. Frontedowiec z którym obecnie współpracuje tak robi, że ma podzielony html na części i buduje przez komendę statyczne pliki html.

kartonpierwszy napisał(a):

Ok, to już nabiera kolorów w mojej głowie.

Mogłoby to wyglądać tak:

• Sposób z generatorem, robisz pliki
  index.html z treścią
  Kopiuj

  <!DOCTYPE html>
  <html>
    <!-- include footer.html -->
  </html>
  

  Drugi plik footer.html z dowolną treścią, i piszesz program, może w PHP, może w Python, w czym chcesz, który Ci "wsadzi" footer.html do index.html, i wypluje zbudowaną stronę do jakiegoś folderu build/ lub innego. I to samo zrobi dla innych podstron. To jest w miarę spoko, bo cały Twój projekt, nie wiedziałby nic o narzędziu z którego korzystasz, a jedynie osadzałbym komentarze HTML w treści. To jest moim zdaniem "najczystsze" podejście.
• Sposób z integracją z jakimś językiem, np PHP
  index.php z treścią
  Kopiuj

  <!DOCTYPE html>
  <html>
      <? include 'footer.php' ?>
  </html>
  

  Ale to ma kilka wad:
  • Po pierwsze, łatwo możesz namieszać, i w tym PHP tworzyć jakieś cuda jak pętle, if'y, i masę innych złych rzeczy, które powinno zrobić się inaczej.
  • Po drugie, nie możesz łatwo zmienić języka, bo każdy jeden plik z HTML który masz wiedziałby o języku, więc się jakby "przywiążesz do niego".
  • Po trzecie, to co generujesz byłoby zależne od konfiguracji PHP, np php.ini oraz od wersji samego języka.

mr_jaro napisał(a):

@TomRiddle jest jeszcze trzeci sposób, budowanie htmla webpackiem. Frontedowiec z którym obecnie współpracuje tak robi, że ma podzielony html na części i buduje przez komendę statyczne pliki html.

No, to też jest dobry pomysł. Mógłbyś podać przykład dla @kartonpierwszy

Panowie, dziękuję za pomoc, pomysły.
Pozdrawiam.

Są też gotowe generatory "static pages", np. HUGO
dłuższa lista generatorów
Choosing the Best Static Site Generator for 2021