Crearea de site-uri pe umi cms

Prin urmare, pentru a vă sfătui, trebuie să fiți gata să garantați 100%. Și putem recomanda cu încredere UMI ca un sistem de management al site-ului și, chiar parțial, ca cadru. Recomanda fără excepții și rezervări, ca și pentru site-uri mici, cărți de vizită și pentru megaportale și magazine online.







Conștient de numărul mare de alte CMS, putem explica la ce se bazează opinia noastră.

Ce licență ar trebui să aleg?

Universalitatea structurii datelor

În mod obișnuit, dezvoltatorii sunt obișnuiți să vadă articole dintr-un site în baza de date într-un tabel, în mod liniar: id-ul unui anumit articol - titlul - anunțul - textul.

În baza de date UMI.CMS, datele sunt stocate într-o structură diferită: id al elementului abstract - câmpul de text - câmpul numeric. Este ceva mai greu să găsești un titlu și un text, dar cu API - câteva linii de cod - și vei primi ceva. Ei bine, dacă este "incomod" - din păcate, programarea este o zonă în care cel mai bun premiu vine doar pentru stres mental suplimentar. Dacă există încă dorința de a ajunge la un nivel superior al structurii datelor, atunci există noi posibilități interesante.

De exemplu, există un magazin online de articole din ceramică din porțelan, unde produsul tipic este "Gresie de argint, 1 mp metru. " Totul este bine, dar acest tigla are cinci dimensiuni diferite. Și fiecare dimensiune este lucioasă, este mată și există și un anti-alunecare (pentru stradă), iar pentru fiecare poate fi atașat acele sau alte decoruri (marginile etc.). Decorurile sunt în valoare de bani în plus, dar nu se vând separat, dar merg în plus față de un metru de plăci corespunzătoare, și numai la ea.

Un exemplu poate părea rar, dar, în realitate, astfel de bunuri lot: automobile (prețul depinde de configurația), asamblate de la calculatoare componente, formulare de cerere pentru viză (da, din punct de vedere software, este de asemenea bun), aer conditionat (sistem split) etc. . d.

În modulul "Date Templates" se adaugă tipul "Produs" cu câmpuri suplimentare:

Dimensiunea 1, tip1, șir, vizibil;
Mărimea 2, tip2, șir, vizibil;

și așa mai departe până la 15 (cinci dimensiuni posibile ale plăcilor, înmulțite cu trei tipuri de suprafețe, randament 15 dimensiuni posibile).

În mod similar, vom crea câmpuri numerice pentru prețuri:

Prețul pe metru pătrat. contorul 1 dimensiune, pr1, numărul, vizibil;
Prețul pe metru pătrat. contor 2 dimensiuni, pr2, număr, vizibil;
și așa mai departe până la 15 ani.

Rămâne să modificăm coșul astfel încât acesta să ia un alt parametru - dimensiunea. Pentru a picta acest lucru nu are sens, pentru că în versiunea modernă a YUMI, bunurile opționale sunt acolo. Acum doar ilustrăm principiul în sine.

Deci, dacă am fi făcut acest lucru pe un motor de stocare liniar de date cum ar fi Joomla, Netcat, Bitrix, etc, ar trebui să adăugăm coloane în tabelele bazei de date. Și dacă nu avem un astfel de tip complex de obiecte, ar trebui să creăm o tabelă separată separată pentru aceste proprietăți suplimentare și să construim ceva global pe întregul motor.

Aici avem doar noi rânduri în tabelul existent. Structura mesei este păstrată. Asta este, dacă mai devreme de interogare pe ID-ul de bunuri ne-a returnat numele, prețul și imaginea, acum se întoarce la noi, de asemenea, dimensiunile acestui produs și prețurile pentru ele. În același timp, alte elemente, cum ar fi articolele, păstrează încă titlul și conținutul - proprietățile noi sunt returnate numai pentru elementul pe care îl au.

Este evident că pe un sit simplu în care există un singur tip de date - articole - un tabel cu stocare liniară de date va da conținut mai rapid. În același timp, dacă avem multe obiecte atrăgătoare cu proprietăți diferite - metoda de stocare a datelor implementată în YUMI este optimă, dacă nu strălucitoare. Plata pentru universalitate în unele cazuri poate fi rapidă, dar această problemă creatorii UMI au decis perfect. Dar despre acest lucru mai târziu, și acum întrebarea principală: și cum să obțineți aceste date pentru a fi afișate pe pagina site-ului?

Solicitările directe către baza de date nu sunt necesare, deoarece acest lucru pentru noi va face ca API și templating.

Viața este schimbabilă și imprevizibilă. Și nici o singură colecție de rețete gata nu va oferi răspunsuri la toate situațiile. API nu trebuie să pretindă că controlează universul, ci ar trebui să simplifice lucrurile de rutină tipice. Și doar cele care trebuie într-adevăr să fie simplificate. Doar lucruri foarte complicate, nu totul.







Templator două, xslt și vechi, tpl. Mai bine, desigur, să începeți cu xslt, să treceți direct prin pas, dar acum, pentru claritate, să luăm un exemplu cu un template tpl.

Este suficient să faceți acest lucru:

În mod similar, puteți transmite orice câmp de date al oricărui obiect cu o macrocomandă, fără a cunoaște php deloc. Și acesta este cu adevărat un pas serios spre viitorul luminos, atunci când o persoană sănătoasă fără abilități de programare va putea să se angajeze într-un site corporativ serios.

Macroanele sunt universale și nu există multe dintre acestea. Ele pot fi inserate atât în ​​șabloane cât și în textul articolului. Deci, cu UMI, managerul de conținut poate gestiona site-ul complet independent, în timp ce în alte CMS-uri ar fi nevoie de implicarea programatorului pentru a îndeplini o astfel de sarcină.

Pur și simplu editarea șabloanelor și inserarea macrocomenzilor pot deja să construiască foarte mult. Dacă aveți o versiune mai veche cu o mulțime de module instalate, atunci chiar și un magazin online avansat poate face un webmaster fără să știe php.

Când funcționalitatea macro nu este suficientă, API ajunge la salvare. Pentru cei care vin de la alte motoare, uneori nu este evident cum să le folosiți în YUMI. De exemplu, înțeleg perfect esența apelului API pentru a obține conținutul câmpului "telefon" dintr-un articol cu ​​un id egal cu 5:

Dar ceea ce începe în continuare, le transformă viața într-un coșmar și trimit blesteme YUMI. Pentru că ei merg în codul motorului, în căutarea în cazul în care funcția pe care afișează conținutul paginii, și cu ajutorul diferitelor hacks încearcă să șurub acest lucru, puternic captată și codul sub forma punerii sale în aplicare a codului de mai sus orientat-obiect. Ei spun: este corect, pentru că folosesc API-ul. Dar nu. Alunecarea motorului are sens doar dacă este o modificare epocală, dacă aveți nevoie de ceva fundamental de schimbat. În dezvoltarea lui YUMI, intervenția în codul motorului în sine este extrem de rară.

Este suficient doar să adăugați o nouă funcție în /classes/modules/custom.php:

Dezvoltatorii, obișnuiți cu cadre puternice, cum ar fi CodeIgniter, încearcă să găsească în API o funcție care ar da datele sub forma unui comprimat frumos. De exemplu, bunurile din magazinul online. Acesta nu este cazul, API-ul din UMI este puntea dintre date și motorul șablonului. Adică, tabelul va trebui să deseneze șablonul după schema dată de tpl (folderul / tpls /) sau șablonul xslt (/ xsltTpls /). Uneori poate fi ajutat. Să presupunem că trebuie să scoatem mărfurile într-un tabel în trei coloane. Blocul de blocuri este un lucru minunat, dar când vine vorba de coloane, masa este adesea cea mai bună opțiune. Și nu numai xslt, dar și șablonul tpl poate construi și el:

- Vom afișa produsele cu o macrocomandă # 037; catalogul getObjectsList ('3_col_template') # 037; - copiați șablonul / tpls / catalog / default la / tpls / catalog / 3_col_template și editați noul nostru șablon introducând etichete de tabel acolo. - Adăugați la noul șablon, la sfârșitul macro-ului objects_block_line .. # 037; splitter la comandă (207 # 037; ID-ul parametru de transmisie este necesar pentru a obține în jurul valorii de cache macro - adăugați la /modules/classes/custom.php funcție:

Această funcție produce un separator de rânduri de tabel pentru fiecare apel treia (sau alt tip de $ cols), iar elementele sunt trimise în trei coloane.

Când are sens să modifice chiar motorul

Aceasta nu este caching-ul prin nginx, care este disponibil în WordPress și alte motoare - când paginile fierbinți sunt plasate într-o memorie cache mică în memorie și sunt emise de acolo. Mult mai bine. Nu numai fierbinte, dar, în general, toate paginile site-ului sunt convertite în statică și sunt emise de nginx. Fără a rula php, fără mysql. Accelerare absolută. Nu pentru nimic este traducerea site-ului în statică sub nginx este cel mai bun instrument de la DDOS.

Instrucțiunile nu spun cum să faceți o excepție de la cache pentru unele pagini, dar este ușor.

De asemenea, UMS CMS poate bate toate înregistrările și fără caching, pe date dinamice, dacă numărul paginilor de pe site este mic. Includeți memcached, dacă este necesar, creșteți tamponul pe server, iar milioane de vizitatori pe zi sunt accesibili pentru noi, chiar și pe un fier slab.

siguranță

În antivirus-alarm.ru (proiect antivirus Kraftwork) aplicați în mod constant pentru site-uri de curățare. Și pentru câțiva ani de existență a proiectului, statisticile s-au adunat. Deci, nu există site-uri pe YUMI. Primul loc din Yukoz - este de înțeles, acolo elevii înșiși s-au pus pe site-ul "miracle-javascript". Al doilea este pentru DLE. Și UMS CMS, în general, în această listă gălăgie nu este prezent. Nici unul dintre proprietarii de site-uri de pe UMI pentru curățare nu se aplică.

UMI vă permite chiar să reinițializați automat paginile site-ului pe etichetele atribuite acestor pagini. In timp ce aderenții altor motoare arunca în sus mâinile lor și refuză să facă acest lucru, pe dezvoltatorii Umi adăugat pur și simplu pentru a custom.php funcție care filtrează ieșirea de pe pagina de conținut, adăugând relegarea.

deficiențe

Este posibil să pictezi demnitatea UMI CMS de foarte mult timp, deoarece UmiSoft a lucrat mult timp și a făcut multe lucruri bune în acest timp. Dar, în corectitudine, este necesar să găsim și să tragem.

O întrebare dificilă, deoarece nu este posibil să se identifice deficiențele sistemice grave ale UMS CMS. Unii dezvoltatori se plâng că UMI nu le informa cu privire la erorile lor de sintaxă admise, ci pur și simplu se blochează un ecran alb atunci când setul nu există o virgulă (pentru securitate este bun, care nu arată eroarea, și este nevoie de depanare - face error_reporting (55)). Sau se plâng de lipsa de API. Acest lucru nu este grav: CMS nu este un control de la distanță al universului, are alte funcții.

Un alt foarte rar, dar încă un caz real - atunci când site-ul de client folosit pentru a obține interesați de datele sale direct de la MySQL, exportul în Excel și înapoi prin phpMyAdmin. Aici, schema de stocare a informațiilor utilizată în YUMI cu un grad ridicat de abstractizare este un obstacol. Dacă acest site are un buget redus - atunci UMI nu este în mod evident cea mai bună opțiune. Dar dacă proiectul este serios - nu există nici o diferență între modul în care sunt stocate datele. Noi facem pentru masa de client într-un format convenabil să-l și exporta periodic date din UMI în acest tabel „experimental“. În același timp, vom scăpa de problema cererilor „grele“, care sunt inevitabile la încărcarea și descărcarea în Excel mari baze de date - pentru că acum clientul nu este chinuit de un tabel de site-ul viu puternic MySQL, și „dublu“ lor. Salvarea reteta, în cazul în care clientul îi place să interogări precum și o masă de mai multe gigabytes.

Versiunile vechi ale UMS CMS







Articole similare

Pagina anterioară

Pagina următoare

Trimiteți-le prietenilor: