[PHP] Struktura CMS-a, budowa portalu

Jestem w trakcie tworzenia strony/portalu z możliwościa dodawania artykułów do pewnych kategorii, ich edycją, dodawaniem kategorii, rejestracją, logowaniem itd.

Adres: http://www.tdragon.ovh.org/rique/ (Wersja mocno niedopracowana, taka pre-alpha)

Jednak powoli zaczynam sie gubić w kodzie i zauważam, że cały kod nie wygląda tak jak powinien.

Struktura strony opiera się na czymś takim:

include ("ulubione_funkcje.php"); // połączenie z mysql-em, kodowanie haseł, generacja obrazka, szyfrowanie itd. rozne ciekawe funkcje

// zmienne globalne na początku skryptu
$date = date("Y-m-d H:i:s");
$adres = $_SERVER['REMOTE_ADDR'];
$referer = $_SERVER['HTTP_REFERER'];

Connect (); // polaczenie z mysql-em

// tutaj jest troche kodu, ktory sprawdza czy uzytkownik jest zalogowany

// tutaj jest kod odpowiedzialny za logowanie, przetwarzanie danych z formularza, czyli hasło i login. Jezeli sie zgadza to użytkownik dostaje sesje (mój odrębny system)...

// kod odpowiedzialny za wylogowanie, jak otrzyma GET z logout.


//natomiast struktura jest taka
switch ($_GET['section'])
{
 case 'rejestracja':
 // sprawdż czy podano dane z formularza, jeśli tak to dodaj je do bazy, jeżeli sie powiodło to wyświetl stosowną informacje, jeżeli nie to wyswietl  formularze do rejestracji.
 break;
}
Disconnect (); // rozłączenie z mysql-em

Kod html jest sztywno napisany na samym dole skryptu, jedynie zmienia się DIV na środku czyli content strony.

W innych profesjonalnych CMS-ach widziałem, że kod był podzielony na odrębne pliki.

Dla przykładu: register.php, index.php, maincore.php, articles.php, forgotpassword.php

U mnie stoi wszystko w indexie i nawet nie mam pojęcia jak to oddzielić od siebie.

i jeszcze

Czas generowania strony: -0.9954 sek.

W ogole cale Twoje podejscie jest zle. Zainteresuj sie programowaniem obiektowym, architektura trojwarstwowa, ewentualnie architektura MVC, SQL Injection. Te pojecia na poczatek ;)

Analizuj kod innych frameworkow czy CMS-ow.

SQL Injection, akurat przed tym to moje skrypty są zabezpieczone funkcjami ereg, albo addslashes zależenie od miejsca.

Szczerze?
Programowanie obiektowe traktuje jak mus, pamiętam tylko, że jedynie w celach wygody z JS napisałem obiektowo wyskakujące menu w AJAX-ie, bo łatwiej było stworzyć jedną wspólną klase dla wszystkich obiektów niż klepać kod dla każdego. Jednak w moim serwisie nie bardzo widze zastosowanie klas.

Poszukam coś na temat tego MVC, bo szczerze to pierwszy raz słysze. Analizowanie kody innych frameworków bywa naprawde trudne skoro każda linijka kodu wymaga szukania gdzie indziej, odwoływania sie do innych metod/funkcji, zmiennych.

Co do licznika generowania strony to nawet niewiem dlaczego tak sie dzieje.
Działa on na prostej zasadzie, pobiera czas na początku skryptu, pobiera czas na końcu skryptu i od ostatniego odejmuje pierwszy i zaokrągla do 4 po przecinku. Czemu pokazuje czasem - to nie mam pojęcia, na razie to bajer niż coś takiego praktycznego

albo addslashes zależenie od miejsca.

Powinieneś używać tego co baza oferuje (już nie mówiąc o tym, że POSIXowe eregi przy PCRE wypadają tragicznie słabo): mysql_real_escape_string (przestarzałe), mysqli_real_escape_string, albo PDO::quote.

Jednak w moim serwisie nie bardzo widze zastosowanie klas.

You're not thinking with port... er... OOP. :P
Jak podstrony zamkniesz w niezależnych kontrolerach, to odpadnie ci problem pt.

nie mam pojęcia jak to oddzielić od siebie.

bo zamiast wielkiego, brzydkiego switcha będziesz miał maks. kilkanaście linijek kodu wybierającego i uruchamiającego odpowiednią klasę na podstawie adresu (poszukaj - Front Controller, routing, dispatcher) - proste i elastyczne.
Tak samo możesz sobie ułatwić korzystanie z bazy (np. ORM), formularzy czy sesji.

Dla przykładu: register.php, index.php, maincore.php, articles.php, forgotpassword.php

Jeśli mówisz o php-fusion to to jest sieczka, nie CMS. ;)

Dzięki za podpowiedź.
No to otrzymałem kilka totalnie nieznanych mi pojęć.

Czuje sie obecnie tragicznie, na siłe wdrożyć OOP, którego tak nie lubie. Ma w teorii przybliżać prawdziwy świat, a jak dla mnie go utrudnia na siłe. Wszystkie framworki przyprawiają mnie o ból głowy.

Poszukam coś w takim razie na temat tych pojęć, bo w sumie nawet niewiem od czego zacząć.

Co do samego PHP-Fusion to z tego kodu coś rozumiałem, w przeciwieństwie do Joomli ;).

Front Controller to pojęcie z wspominanego wcześniej modelu trójwarstwowego MVC (Model-View-Controller), obecnie coraz bardziej popularnego, także w PHP. Ogólnie w MVC chodzi o podzielenie aplikacji na trzy warstwy - widok prezentujący dane w jakiejś formie (nie mylić z widokiem w bazie danych), model zajmujący się dostępem do danych i kontroler obsługujący akcje użytkownika. Front Controller - ogólnie rzecz biorąc - odpowiada za routing (przekazywanie danych do innych kontrolerów).

PiotrLegnica jeszcze wspomina, że samo addslashes() jest słabe, lepiej stosować funkcje mysql_real_escape_string() (nie mysql_escape_string()!) albo w ogóle dostęp do bazy danych zostawić PDO (dostępne od PHP 5.1), obiektowemu sposobowi dostępu do baz danych, ujednoliconemu. ORM to już trochę inna, wyższa działka, nie wiem czy jest sens na początku to wprowadzać - zresztą przy takim podejściu do OOP to chyba nie ma sensu ;-)

Jeżeli myślisz, że OOP utrudnia Ci zadanie - to nie stosuj go na siłę. Zrób sobie prosty system, może być i z rozbudowanym switchem, z wieloma plikami, cokolwiek. Programuj, ucz się. Kiedyś dojdziesz może do tego, że klasy, metody i wzorce projektowe to są jednak fajne ;-)

Na obecnym poziomie pomyśl o podzieleniu na funkcje, na includowanie w zalezności od tego co użytkownik aktualnie potrzebuje (if action==register include register.php). Nie wiem czy jest sens od razu pchać się w naukę MVC, ORM, OOP i innych trzyliterowych skrótów.

Sama nauka OOP nie jest trudna, to jest banał opanować całą składnie. Tylko wiedzieć potem jak to zastosować tak, żeby było wygodnie. Dziedziczenie, polimorfizm... no właśnie ;).

Mowa o tym, iż switch z includami jest złym rozwiązaniem, jednak jakie są jego wady, słabości?
W czym góruje nad nim MVC?

Możliwe, że jeszcze nie czas dla mnie na OOP. Jednak fajnie wiedzieć, że jest nademną jakieś lepsze rozwiązanie i będzie trzeba sie powoli stosować do niego, niżeli pozostawać w głupiej świadomości, że moje rozwiązanie jest najlepsze i nie iść już do przodu.

na razie tak jak mówisz spróbuje zrobić taki wirtualny OOP, czyli podziele kod na funkcje i wprowadze zależności między nimi tak, by można było je wykorzystać uniwersalnie.
Jak się już uda to może skusze sie na jakieś klasy, bo wtedy będzie dużo łatwiej to przekonwertować do obiektowości.

EDIT:
Co do posiadania w domu dużej ilości komputerów to wiem coś o tym, jak zajmowałem sie overclockingiem i podkręcałem wszystko co ma BIOS albo zworki. Z ilu komputerów to ja chciałem zrobić profesjonalny serwer i to nie raz. w SPACJA końcu zorientowałem się, że mam w domu graciarnie i sprzedałem większość. Aczkolwiek nadal w pokoju mam 3 ;).

Mowa o tym, iż switch z includami jest złym rozwiązaniem, jednak jakie są jego wady, słabości?

Jak urośnie ci do rozmiarów kilku kB to zobaczysz jego wady. ;) W sumie taki switch to też rodzaj Front Controllera, tylko mało elastycznego i wymagającego ręcznego dopisywania nowych akcji.

W czym góruje nad nim MVC?

Wprowadza czytelny podział aplikacji, ułatwia modyfikacje (tzn. w teorii, bo nawet najlepszy wzorzec da się zaimplementować tak, że będzie tylko przeszkadzał :P) - przy większych aplikacjach konieczność przeszukiwania tysięcy linii strukturalnego (albo pseudoobiektowego, bo i taki się zdarza) kodu w celu zrobienia jednej modyfikacji to koszmar (vide phpBB).

na razie tak jak mówisz spróbuje zrobić taki wirtualny OOP, czyli podziele kod na funkcje i wprowadze zależności między nimi tak, by można było je wykorzystać uniwersalnie.

Jak się uprzeć, to da się MVC zaimplementować na funkcjach (ba, pisałem coś takiego, może nawet uda mi się znaleźć), w sumie nikt nie mówił, że widoki, kontrolery czy modele muszą być obiektami.

Zabrałem sie za rozkładanie mojego kodu.
Dajmy na to, że na razie pozostane przy switchu.

Jednak jeszcze niewiem jak powinienem wmieszać PHP w HTML.

Obecnie mój kod wygląda mniejwięcej tak(to jest skrócona wersja oczywiście):

$gentime_start = microtime(); // licznik generowania strony
include ("includes.php"); // includy do skryptu
Connect (); // mysql

if ($LoggedAs = Zalogowany()) // sprawdz czy uzytkownik jest zalogowany
 define("ISLOGGED", true);
else
	{
   define("ISLOGGED", false);
	 Zaloguj ();
	} 

if ($_GET['type'] == 'logout') // jezeli logout to wyloguj
	Wyloguj ();
else
{
	$logstatus = WyswietlLogbar (); // inaczej przekaz do zmiennej logstatus, cały pasek w htmlu od logowania
}

// ankieta
if (!empty($_POST['pole']))
{
  $message = SprawdzAnkiete (); // sprawdz czy ktoś głosował, jak tak to dopisz do zmiennej message komunikaty
}

if (empty($_GET['aid']))
{
     switch($_GET['section'])
     {
          // narazie mam tutaj kod zamiast includów
     }
}
else
{
	// wyswietl poradnik o danym ID
}


echo $doctype;
echo "<html>";
echo "<head>";
echo $meta;	// znaczniki meta
echo $title; // tytul strony
echo $script; // javascript
echo $css; // css

echo "<body>";
echo "<div id='top'>";
echo "<div id='heading'>";
echo "<img  src='logo.jpg'>"; // logo
echo $logstatus; // pasek logowania otrzymany dzięki skryptom wyżej

echo "<div id='leftbar'>";
echo "<div class='leftlink'>";
echo "<h3>Nawigacja</h3>";

echo $links; // linki po lewej stronie 

echo "</div>";
echo "<br>";

echo "</div>";
echo "</div>";

echo "<div id='rightbar'>";
echo "<div id='rightlink'>";
echo "<h3>Ankieta</h3>";
echo "<h5>Co Ci sie nie podoba?</h5>";
echo "<br>";

echo $form; // wyswietl formularz z ankieta
echo $message; // komunikty z głosowania otrzymane ze skryptu wyżej

echo "</div>";
echo "</div>";

echo "<div id='content'>";
echo "$content";  // cały content strony, czyli to co po środku. również generowany ze skryptów wyżej

$gentime_end = microtime(); $czas = $gentime_end - $gentime_start; 

echo "<div id='bottom'>";
echo "Copyrights &copy; 2008, tdragon.ovh.org. All rights reserved.<br>";
echo "Webpage designed by <a href = 'index.php?section=contact' style = 'color: black;'>TDragon</a>.<br>";
echo "Czas generowania strony: " . round ($czas, 4) . "sek.<br>";

echo "</div>";
echo "</div>";
echo "</body>";
echo "</html>";


// poniżej jeszcze są statystyki w php, sprawdza na jakiej podstronie znajduje sie uzytkownik i zapisuje w bazie kazde odswiezenie strony, oraz zapisuje IP osob ktore wchodziły.

Przepraszam za ten kod, powiem tak. na razie na szybkiego chciałem przekształcić html do PHP dlatego to na razie wygląda nieprofesjonalnie. Mam zamiar zamienić te html-owskie wstawki na funkcje, czyli WyswietlLewyPasek() itd.

Jednak mi chodzi o sama idee. Czy powinienem zapisywać wynik ze skryptów do zmiennych, a wyświetlać je w htmlu na końcu, czy lepiej cała strone zacząć od htmla i w między czasie przeplatać go wynikami ze skryptów bezpośrednio z echo, a nie ze zmiennych?

Obecnie kod mam podzielony na kilka php-ów:
include.php - zawiera includy do innych plików php
global.php - zmienne globalne
usesfunc.php - funkcje z połączeniem do bazy, szyfrowaniem, zamiana bbcode do html i inne bzdety
poll.php - funkcje przetwarzanie ankiety
authorize.php - funkcje generowanie obrazka autoryzującego
login.php - funkcje logowanie, sprawdzanie czy ktos jest zalogowany, wylogowywane

W ogóle nie mieszaj HTML i PHP. Zastosuj jakiś system szablonów.

Po pierwsze nie mieszaj html z php, jak wspomniano
Nie musisz używać szablonów smarty na siłę, możesz zrobić tak:

//przypisz zmiennym wartości
$szablon['MAIN_PAGE'] = 'strona główna';

//wczytaj szablon
include('szablon.tpl');

w szablon.tpl daj

Tutaj może być część właściwa strony <? echo $szablon['MAIN_PAGE'] ?>Dalej coś innego

może nie jest to tak ładne jak smarty ale dla prostych stron się sprawdza, smarty i tak zamieni wszystko na <? echo ... ?> jak wyżej
generalnie dobrze jest sobie buforować dane - zobacz funkcję ob_start()

może ten sposób ci się spodoba

i zamiast

echo 'cośtam';
echo 'cośtam';
echo 'cośtam';

można:

echo '
tekst'.$zmienna.'
tekst
tekst
';

Nie lubie gotowych rozwiązań, szablonów itd.
Wole sam napisać jakiś system.

Co do echowania to wiem, że można łączyć ciągi to jest dla mnie oczywiste. Tylko dla celów czytelności dla mnie zrobiłem tak, a nie inaczej. Chciałem widocznie rozdzielić divy itd.

Z buforowania danych korzystałem zawsze jak mi wyświetlał sie error, że nagłówki zostały wysłane. W innym wypadku nie korzystam z tego.

Nie rozumiem idei Tworzenia pliku szablon.tpl, a dopiero w nim konkretnych zmiennych.

Czy wszystko sie sprowadza do jak najmniejszego zapierdzielu w index.php?

właśnie do jak największego zapierdzielu w index.php a jak najmniejszego w szablon.tpl
idea polega na tym żeby osoba nie znająca php a tylko html mogła dowolnie modyfikować wygląd strony a osoba nawet go znająca połapała się jak najszybciej w kodzie

ja jeżeli coś to i tak nigdy nie używam echo, co najwyżej
?>tekst
tekst
tekst <?php echo $zmienna ?>
tekst

co do minusowego czasu generowania - dodaj parametr true do funkcji microtime (microtime(true))

Nie lubie gotowych rozwiązań, szablonów itd.
Wole sam napisać jakiś system.

Pisząc aplikację pokroju CMSa musisz sensownie rozplanować swój czas, inaczej zbyt dużo nie napiszesz. Rozwijanie (a w szczególności testowanie i wyłapywanie głupich błędów) poszczególnych bibliotek zajmuje tego czasu sporo - szczególnie w przypadku tych większych - ja swój systemik szablonów rozwijam od ~7 miesięcy i dalej jest sporo do zrobienia - ty możesz skorzystać z pracy ludzi którym chce się takie rzeczy tworzyć i utrzymywać ;), a swój czas poświęcić na właściwą funkcjonalność CMS.

Nie rozumiem idei Tworzenia pliku szablon.tpl, a dopiero w nim konkretnych zmiennych.

Kod w którym nie ma setek linii dziwacznie pozagnieżdżanego HTMLa czyta i modyfikuje się dużo łatwiej i przyjemniej. I vice versa.

Adamo napisał(a)

można bardzo fajnie pisać:

<?= $zmienna ?>

Jedyne sensowne rozwiązanie to <?php ?>, wszystko inne może zawieść, o czym się przekonałem.

Odnośnie konstrukcji CMS'a to wydaje się że sprawdzają się moduły, każdy sam przetwarza swoje komunikaty, jedyne co to każdy musi mieć unikalną nazwę. Załatwia to problem rozpoznawania reakcji na działanie użytkownika.

Dodatkowo dla szybkości działania CMS'a ma sens podział na setki różnych mniejszych plików ładowanych na życzenie. Jedyne co to gubi się założenie klas, trzymania pewnych funkcji w jednym miejscu. Taka klasa mogłaby być bardzo długa, i ładować wiele różnych funkcji zupełnie niepotrzebnie, więc umiarkowanie jest wskazane.