Principiul de funcționare al unui simplu CMS (sistem de management al conținutului)

Motivul pentru scrierea acestui articol se bazează pe o conversație cu un om bun, care pe deplin dezvoltat, știe totul este un pic, dar mai profund să plece, să zicem, în același PHP nu poate - având în vedere, de fapt, lipsa de informații corecte și lecții explicative privind scrierea sistemele de gestionare a conținutului. O temă, cu toate acestea, suficient de actualitate, pentru că nu mulți specialiști care doresc să împărtășească experiența lor (în special cu publicul larg).

Deci, înainte de a începe, să sunt de acord că suntem interesați de „om-friendly URL-uri (CNC) și lucrările vor fi codificate numai cu UTF-8 (despre Windows-1251 uita o dată pentru totdeauna - aceasta vă va da o mulțime de hemoroizi, dacă doriți să pună în aplicare elementele site interactiv folosind Javacsript).

fișier .htaccess (înființat un server pentru a lucra cu CNC):

Deci, aici ne vom concentra pe un simplu modular CMS, care este ușor de întreținut, dezvolta și de a folosi pentru a naviga așa-numitul router.

Această metodă nu este perfectă, și eu l-am abandonat mult timp. În principal, datorită faptului că fiecare modul dezvoltat într-un program separat, și a fost destul de dificil să însoțească proiectele, chiar dacă nu mare. În general, efectele negative la această abordare, mult mai mult decât profesioniști.

În înțelegerea mea, punctul de intrare (adesea este fișierul nostru de index.php) într-un CMS normală trebuie să se conecteze cel puțin un fișier de sistem de bază dintr-un singur fișier (în această clasă core.class.php caz):

La fel ca multe cărți, voi insista, de asemenea, că percep ambele clase (în exemplul de mai sus) ca cutiile negre, care este ceva ce pot face în cazul în care încă transmit ceva. Sunt de acord, deoarece programatorul nu are nevoie să știe modul în care funcția de ecou (); - suficient să se știe că, dacă îi dai opțiunea, PHP va asigura pentru a aduce această opțiune pentru browser. O mulțime de atenție trebuie acordată fișierul config.php router

acestea vor fi tratate în mod corespunzător la starea și conectați fișierele de bază ale blocurilor și modulele respective:

• Module / items.php
• Blocuri / head.php
• Blocuri / header.php
• Blocuri / left.php
• Blocuri / footer.php

Eu cred că cheia pentru înțelegerea modului de a construi acest CMS este în șablonul de pagină de fișier! Deci, să ne uităm la un simplu șablon pentru acest CMS:

Aici variabilele %% HEAD %%. %% HEADER %%, etc sunt identificatori pentru blocurile de înlocuire. să fie înlocuit tot ceea ce a dedus (prin ecou «»;) fișiere „cap“ => „blocuri / head.php“, „header“ => „bloc / header.php“ și așa mai departe. pe de ieșire. Cu alte cuvinte, în cazul în care blocurile / fișierul head.php avem acest lucru:

%% HEAD %% modelul ia forma (rândul 4-9):

Așa se întâmplă cu toate datele de identificare de înlocuire. Titlu identificator cheie este definit de regula (de exemplu, %% CONTENT %% - „conținut“ => „module / index.php“ (nota - litere mari Obligatoriu - asa conceput :)

Și eu totul aduce la faptul că fiecare fișier poate satisface acum sarcina îngustă specifice stricte și nu se implice în problema rămasă. arată ciudat, ca unii experți a scrie site-uri verzi care forma și conținutul, și capul și subsol într-un singur fișier ... Chiar dacă credeți că site-ul nu va fi însoțit în continuare, oricum, ar trebui să încercați să scrie corect (citiți „modulare“).

Între timp, tehnicile de sistem așa-numitele tutorial:

Clasa constructor. Ia o matrice $ config (a se vedea. Fișierul config.php)