Foaie de parcurs potentiala pentru relatiile meta si post taxonomie

In zilele dinaintea Summitului comunitar WordPress din octombrie, un numar de dezvoltatori care au contribuit s-au strans impreuna pentru a discuta o serie de idei de arhitectura pe termen lung. Printre acestea s-au numarat taxonomia O taxonomie este o modalitate de a grupa lucrurile impreuna. In WordPress, unele taxonomii obisnuite sunt categoria, linkul, eticheta sau formatul de postare. https://codex.wordpress.org/Taxonomies#Default_Taxonomies. meta Meta este un termen care se refera la functionarea interioara a unui grup. Pentru noi, aceasta este echipa care lucreaza pe site-uri interne WordPress precum WordCamp Central si Make WordPress. si post relatii. (Ah, vad ca acum iti am atentia!) Aceasta postare este mai mult sau mai putin o foaie de parcurs propusa. Este un plan ambitios, care este conceput sa aiba loc peste cinci sau mai multe lansari.

(In timpul WordCamp WordCamps sunt conferinte casual, organizate la nivel local, care acopera tot ceea ce are legatura cu WordPress. Sunt unul dintre locurile in care comunitatea WordPress se reuneste pentru a-si invata reciproc ceea ce au invatat de-a lungul anului si a impartasi bucuria. Aflati mai multe. Keynote din San Francisco, @matt a vorbit putin despre un nou obiectiv de a construi echipe de colaboratori si recenzori in jurul nucleului individual Core este setul de software necesar pentru a rula WordPress. Echipa de dezvoltare Core construieste componente WordPress. Va fi mult mai mult pe asta in zilele si saptamanile urmatoare. Deocamdata, iata o postare care acopera doua componente, tipuri de postari si taxonomie.)

Discutia a inclus toti comiterii de baza din acel moment – @ryan, @markjaquith, @westi, @azaozz, @nacin, @ dd32, @koopersmith si @duck_ – si un numar de dezvoltatori care au contribuit, inclusiv @aaroncampbell, @ dh-shredder , @helen si @scribu.

In prezent, termenii sunt reprezentati in WordPress folosind doua ID-uri diferite: un ID de termen si un ID de taxonomie. Un termen ID (si nume si slug) poate aparea de fapt in mai multe taxonomii, deci pentru a identifica un anumit termen, trebuie sa aveti fie termenul ID si taxonomia corespunzatoare, fie doar termenul ID taxonomie. Acest lucru dateaza de la schema de taxonomie originala din WordPress 2.3. La acea vreme, conceptul de „termeni comuni” parea ca ar putea fi o abstractie importanta. Retrospectiva este 20/20, iar termenii comuni sunt pustia taxonomiilor din WordPress.

Deci, cand vorbim despre termenul meta , vorbim de fapt despre termenul meta-meta taxonomie asociat cu un termen ID taxonomie, nu un termen ID. Problema este, ID-ul public utilizat in API. O API sau o interfata de programare a aplicatiei este un intermediar software care permite programelor sa interactioneze intre ele si sa partajeze date in moduri limitate, clar definite. si in alta parte este termenul ID (si, prin necesitate, este trecuta si o taxonomie). Aceasta confuzie – si nevoia de a exista un singur identificator de obiect in API-ul nostru de metadate (termen ID taxonomie, nu doi, ca in termen ID si taxonomie) – ne-a fortat de mult sa prezentam discutia despre termenul metadate.

(Exista probleme conceptuale separate aici – in ce moment un termen cu metadate devine pur si simplu un obiect asemanator postului care se poate lega de alte postari? Si date relatii de postare, ar putea termenii si postarile sa converga de fapt in schema lor de baza? Nu sunt de fapt, voi raspunde la aceste intrebari in aceasta postare. Schema si arhitectura pur vorbitoare in acest moment.)

La WordCamp San Francisco anul trecut, patru dintre noi – eu, Gary Pendergast (@pento), @scribu si @koopersmith – am venit cu o modalitate destul de nebuna de a face schimbari majore in schema noastra de tabel, fiind totusi compatibili cu versiunile anterioare. De fapt, am venit cu doua moduri de a face acest lucru. Acesta a fost planul pe care toata lumea l-a auzit si discutat la summit.

Era clar ca termenii comuni trebuiau sa mearga. Primul pas este eliminarea unui index UNIQUE pe campul slug din tabelul wp_terms. (Acest lucru depinde de # 17689.) Apoi, nu mai cream noi termeni comuni. Pasul trei, intr-o rutina de actualizare, cautam in mod activ orice termeni partajati existenti si ii impartim.

Acesti trei pasi initiali trebuie sa aiba loc intre doua sau trei versiuni majore, deoarece vorbim despre o eroare O eroare este o eroare sau un rezultat neasteptat. Imbunatatirile de performanta, optimizarea codului si sunt considerate imbunatatiri, nu defecte. Dupa inghetarea caracteristicilor, sunt tratate numai erorile, regresiunile (modificarile adverse fata de versiunea anterioara) fiind cea mai mare prioritate. corectie, o modificare a schemei, o modificare a API-ului si o rutina de actualizare – in aceasta ordine.

Apoi vine partea amuzanta, intr-o alta versiune majora O versiune A, identificata prin primele doua numere (3.6), care este punctul central al unui ciclu complet de lansare si a dezvoltarii caracteristicilor. WordPress foloseste numarul zecimal pentru versiunile majore de lansare, astfel incat 2.8, 2.9, 3.0 si 3.1 sunt secventiale si sunt comparabile ca domeniu de aplicare. Cu termenii partajati impartiti, ID-ul termenului si ID-ul taxonomiei termenului vor fi identice la fiecare instalare. Daca am muta campurile slug si nume de la wp_terms in wp_term_taxonomy, am putea  renunta la wp_terms.

Cum putem elimina un intreg tabel, dar totusi sa fim compatibili inapoi? Am venit cu doua solutii:

1. Deoarece toate campurile din wp_terms vor exista in wp_term_taxonomy, wp_terms poate fi recreat ca MySQL MySQL este un sistem de gestionare a bazelor de date relationale. O baza de date este o colectie structurata de date in care sunt stocate continut, configuratie si alte optiuni. https://www.mysql.com/. vizualizarea este o oglinda de numai citire a datelor pe termen, fiind astfel compatibila cu toate interogarile existente.
2. Deoarece toate campurile din wp_terms vor exista in wp_term_taxonomy si pentru ca aliasurile tabelelor precum `t` si` tt` sunt intotdeauna utilizate la alaturarea acestor doua tabele, $ wpdb-> termenii pot fi pur si simplu setati la $ wpdb-> term_taxonomy O interogare care a alaturat anterior wp_terms cu wp_term_taxonomy s-ar alatura singur.

In total: folosind a doua abordare (da, functioneaza), a fost nevoie de aproximativ 20 de linii de cod Linii de cod. Aceasta este uneori utilizata ca o valoare slaba pentru productivitatea dezvoltatorilor, dar poate avea si alte utilizari. pentru a face ca WordPress sa ruleze fara o masa wp_terms. Uau, nu?

Deci, pana la acest punct, am avea in cele din urma o schema de taxonomie sanatoasa. Mai putine imbinari, un API mai curat (probabil ajutat de un nou obiect WP_Term pentru a modela WP_Post si WP_User), nu mai exista dureri de cap de termeni comuni si un singur ID sanatos pentru termenul unei singure taxonomii.

Odata ce totul este terminat, putem avea in sfarsit meta term. Poate. (Glumesc. (Un fel de.))

Unde intra relatiile post? Plugin-ul existent Posts 2 Posts Un plugin este un software care contine un grup de functii care pot fi adaugate pe un site web WordPress. Ele pot extinde functionalitatea sau pot adauga noi functii pe site-urile dvs. WordPress. Pluginurile WordPress sunt scrise in limbajul de programare PHP si se integreaza perfect cu WordPress. Acestea pot fi gratuite in directorul de pluginuri WordPress.org https://wordpress.org/plugins/ sau pot fi pluginuri bazate pe costuri de la o terta parte de catre @scribu. Este fantastic si serveste bine nisei. Dar nu ne simtim foarte confortabili sa facem modificari de arhitectura sau API in aceasta directie, in timp ce schema noastra de taxonomie este inca departe de a fi starea ideala.

Pluginul pentru relatiile de postare accepta postari catre postari si postari catre utilizatori. Relatiile de taxonomie de baza accepta postarile la termeni, dar poate fi, de asemenea, aranjat pentru a lega utilizatorii de termeni. (De asemenea, a acceptat legaturi catre termeni, inca un alt tip de obiect.) Nu am rezolvat complet aceasta idee inca, dar o idee este de a converti tabela curenta wp_term_relationships intr-o tabela de relatii obiect mai generica, care poate sprijini postarile in postari, postari catre utilizatori, termeni catre utilizatori si, desigur, postari catre termeni (si, intr-adevar, orice relatie arbitrara).

O declinare de responsabilitate: Aceasta postare nu promite nimic. Nu va bazati pe continutul acestei postari pentru proiecte viitoare. Ne va lua ceva timp sa stabilim bazele adecvate si sa ne asiguram ca vom obtine acest lucru corect. Nu va asteptati ca acest lucru sa se intample in WordPress 3.7 sau chiar 3.8. (De fapt, nu va asteptati ca acest lucru sa se intample deloc.)

Acestea fiind spuse, ma bucur foarte mult sa primesc aceste informatii si sunt incantat sa aud orice feedback pe care il aveti. Ne gandim mereu spre viitor, iar multi dezvoltatori care au contribuit au harti de parcurs in cap – au trecut mult timp pentru a le lua pe hartie.

# post-types, #roadmaps, #taxonomy