Cum funcționează rutarea în WordPress?

Question

Cum funcționează rutarea în WordPress?

12 apr. 2014, 10:46:59

Vizualizări: 55.2K

Voturi: 24

Cum funcționează rutarea de bază în WordPress? Am dificultăți în a înțelege... În MVC, URL-ul tău arată ca mycontroller/myaction care se mapează la MyController->myaction()

În Drupal, este index.php?q=mycustomerpath/hello care poate fi mapată la orice funcție dorești și care returnează un conținut care este "tematizat" în layoutul temei tale.

Dar în WordPress, nu am nici o idee cum sunt făcute lucrurile... este ?p=1 apoi ?product=1 ... Am căutat documentație despre fluxul de rutare dar nu pot găsi nimic (Google returnează doar articole despre rute personalizate).. vreau să înțeleg mai întâi fundamentele rutării de bază..

yeahman

744

url uri rutare

Comentarii

analizând codul, observ că la fiecare solicitare apelează query_posts? de ce naiba are nevoie să interogheze postări de fiecare dată? nu există cazuri în care de fapt nu vrei să afișezi postări??

yeahman

12 apr. 2014 10:49:17

Conținuturile sunt salvate ca postări în WP. Deci, când trebuie să afișezi conținuturi, trebuie să le interoghezi

Sisir

12 apr. 2014 11:36:55

Pot să sugerez să citești despre "the loop" care este conceptul pe care trebuie să-l înțelegi pentru a ști cum funcționează WordPress. În esență, "the loop" afișează o matrice de postări care este rezultatul query_posts. Pentru solicitările URL non-admin, WP este conceput să afișeze doar postări și este nevoie de programare personalizată pentru a afișa altceva în afară de o postare. Solicitările URL admin sunt diferite și acestea nu folosesc "the loop" și afișează lucruri care nu sunt postări.

User

12 apr. 2014 11:52:01

ok, dar această abordare este un pic ciudată și nu foarte flexibilă, să fiu sincer

yeahman

12 apr. 2014 13:07:12

de exemplu, dacă vreau să afișez un formular de contact... trebuie să pun codul HTML într-un tip de conținut de pagină? Încă încerc să înțeleg unde să pun logica pentru trimiterea formularului... (în page.php din temă? abordare foarte urâtă)

yeahman

12 apr. 2014 13:08:50

Arată celelalte 2 comentarii

Toate răspunsurile la întrebare

Comentarii

Înțeleg că totul ar trebui reprezentat într-un post (prin tipuri de postări personalizate etc.), foarte similar cu tipurile personalizate din Drupal 6... dar afectează performanța faptul că avem un singur tabel de postări pentru a stoca fiecare conținut al site-ului? Drupal 7 a rezolvat această problemă prin introducerea tipurilor de entități, astfel încât nu mai trebuie să creezi un tip personalizat și să stochezi totul în tabelul de noduri, ci în propriul tabel de entități care poate beneficia totuși de cadrul Drupal. Sper ca WordPress să introducă o astfel de abordare în viitor. Mulțumesc pentru explicațiile detaliate.

yeahman

12 apr. 2014 13:14:07

Presupun că dacă vreau să mapez un URL la o funcție/țemă proprie, WP Router ar putea ajuta?

yeahman

12 apr. 2014 13:15:08

Adăugarea unui sistem complet de rutare nu este de obicei necesară. Există metode mai simple. Baza WordPress este afișarea conținutului generat de utilizatori, care este stocat în întregime în tabelul de postări. Dacă dorești să afișezi conținut care nu este generat de utilizatori, atunci de obicei o faci în țemă sau într-un plugin. Există sute (mii) de hook-uri de acțiune, filtre și alte modalități prin care codul poate înlocui diverse părți ale procesului pe măsură ce pagina este generată. Și cu lucruri precum shortcode-urile, inserarea de HTML personalizat în conținut este relativ ușoară.

Otto

12 apr. 2014 13:19:21

cum pot adăuga html/php personalizat într-un tip de postare pe care l-am creat? fără a fi nevoit să modific single.php din temă sau să creez un single-mycustompost.php (nu este o abordare foarte portabilă)

yeahman

12 apr. 2014 13:24:26

Shortcodes. http://codex.wordpress.org/Shortcode_API

Otto

12 apr. 2014 13:54:11

Arată celelalte 14 comentarii

Otto 32.8K · Answer 1 · 2014-04-12T13:08:56Z

În WordPress, URL-urile nu sunt mapate la rute. Ele sunt mapate la interogări în baza de date.

Când utilizați WordPress în modul "default" de permalink-uri, aveți un set de variabile în interogarea URL-ului principal, cum ar fi ?p=1 sau ?page=234 și așa mai departe. Există și ?s=căutare și multe altele.

Dacă utilizați permalink-urile "pretty", atunci este creat un set mare de reguli numite "reguli de rescriere" care mapează direct diferite modele de URL-uri pe același set de parametri URL. Deci, un URL precum /2014/04/12/exemplu ar fi mapat la ?year=2014&month=04&day=12&postname=exemplu sau similar. Astfel, următoarele se aplică și acestora, după ce această mapare este făcută.

Aceste variabile controlează în esență instanța principală a clasei WP_Query. Clasa WP_Query deține toate informațiile care construiesc interogarea în baza de date pentru a obține "postările" din baza de date. Diferiții parametri transmiși în ea controlează ce fel de interogare construiește și ce date obține.

Vedeți, tot ce poate fi afișat de WordPress este în esență o "postare". Un blog este o serie de postări în ordine invers cronologică. O "pagină" este o postare statică cu un nume definit. Un "tip de postare personalizat" este exact ceea ce sună, o "postare" cu un tip personalizat pe care îl definiți. Toate interogările principale pentru a afișa orice în WordPress obțin un subset de postări din tabelul wp_posts.

WP_Query este ceea ce face asta. Și parametrii din URL sunt trimisi direct în acea interogare principală și utilizați acolo.

Tema determină apoi ce șablon să folosească în funcție de ceea ce returnează interogarea. Dacă ați solicitat /categorie/exemplu, atunci acesta devine ?category_name=exemplu, ceea ce înseamnă că array-ul principal $wp_query->query_vars va primi acea informație, iar WP_Query va extrage ultimele X postări pentru categoria "exemplu" și va seta steagul is_category pe true.

Template-loader va rula după aceasta, va vedea că is_category() returnează true și va decide să aleagă șablonul de categorie, astfel că va căuta category-exemplu.php și va reveni la category.php și așa mai departe, conform Ierarhiei de Șabloane.

Deci, întrebarea dacă doriți să schimbați modul în care funcționează URL-urile este simplă: Doriți să schimbați URL-urile sau la ce sunt mapate? Deoarece URL-urile nu sunt mapate la funcții, ele sunt mapate la parametri care controlează interogarea. Dacă doriți ca URL-ul să ajusteze acea interogare principală, atunci este un proces ușor diferit față de cazul în care doriți ca un URL special să execute un cod special total diferit.

Și pentru a răspunde la întrebarea dvs. specifică din comentarii: "nu există cazuri în care nu doriți de fapt să afișați postări?" Nu, nu există. Totul este o postare. Tot conținutul este stocat în postări. Dacă doriți să stocați conținutul în altă parte și să fie diferit, atunci puteți face asta, dar este mai dificil pentru că, sincer, de obicei nu este necesar. Dacă aveți conținut special, creați un tip de postare personalizat, stocați conținutul ca o postare cu acel tip, mapați un model de URL la el. Simplu.