spyked bricks in the wall

ce am învățat despre sistemul de pingback-uri din wordpress

Acum ceva vreme speculam pe Trilemă despre pingback-uri și cam cum e posibil să funcționeze ele. Scriu aceste rânduri pentru că sper că le va citi cândva un dezvoltator al WordPress-ului și se va încumeta să rezolve odată pentru totdeauna problema pe care o voi descrie mai jos, la fel cum voi descrie și de ce eu unul mi-am băgat definitiv picioarele și alte membre într-însa.

Am considerat mereu pingback-ul/trackback-ul ca fiind o unealtă extrem de utilă blogger-ului, dat fiind faptul că autorii de blog-uri mai discută între ei și preferă o alternativă la lăsatul de comentarii kilometrice (deși eu mai fac asta). Alternativa se dovedește a fi acel sistem prin care dacă individul scrie un articol iar scrie un articol care face referință la chestii din , atunci putem stabili existența unei legături concrete , legătură concretizată printr-un sumar al lui în cadrul comentariilor lui . Acel comentariu se va numi pingback etc.

Sistemul e decent specificat, însă are lacune la nivelul implementării în WordPress, care-i o monstruozitate cu șaptișpe picioare și patrujdouă de capete, plus câteva falusuri imense care încearcă să ne violeze anal pe noi, utilizatorii de rând, indiferent de gen. Dar cum eu sunt un utilizator de rând mai rezilient, m-am apucat să iau codul la puricat și să văd ce se întâmplă acolo.

În primul rând că descrierea sistemului de Trackback/Pingback din WordPress susține că, citez:

Trackbacks are a way to notify legacy blog systems that you’ve linked to them. If you link other WordPress sites they’ll be notified automatically using pingbacks, no other action necessary.

și probabil că face asta, însă eu recunosc că nu mi-am dat seama cum. Dar dacă îl forțăm să trimită trackback-uri introducând link-ul în câmpul „Send trackbacks to”, ceea ce face el e să actualizeze câmpul to_ping asociat articolului în baza de date cu o listă de URL-uri separate prin spații. Apoi la publicarea articolului (care poate fi acum, peste o oră sau peste un an, după voia utilizatorului) se planifică o rutină, pe numele ei do_all_pings, care ia ping-urile din baza de date, le execută, după care actualizează alt câmp, care-i de fapt o listă cu URL-urile la care s-a făcut deja ping.

Acum ajungem la partea interesantă, anume cea în care vorbim despre wp-cron. Toată planificarea în WordPress (fie că vorbim de întârzierea publicării unui articol sau despre acea rutină de execuție a ping-urilor) se face printr-un modul numit cron, după cron, dar nu-i cron, că dacă ar fi nu ne-am lamenta aici ca proștii care suntem.

Ei, cron-ul ăsta e, la fel ca tot WordPress-ul de altfel, o chestie inutil de complicată care planifică și execută job-uri. Modulul de bază se află în wp-includes/cron.php și are doar vreo patru sute de linii, ceea ce-i ok, adică poezie, nu alta. Cu toate astea, toată drăcia se bazează pe un sistem de hook-uri, adică funcții introduse dinamic și aparent arbitrar în toată povestea asta. Repet, dinamic, ceea ce înseamnă că ăla care se uită pe cod n-are de unde să știe în prostia lui unde se va executa vinovatul, că asta înseamnă dinamic.

De-aici încolo eu n-am mai înțeles nimic și nici nu mă chinui, iar dacă vreți să aveți vreo speranță de a duce o viață relativ normală în continuare și de a rămâne sănătoși la cap, vă sfătuiesc să nu vă chinuiți nici dumneavoastră. Doar dacă nu cumva sunteți unul din dezvoltatorii chestiei în cauză, caz în care eu oricum vă declar bolnav la cap și vă trimit să rezolvați naibii problema. Eu unul până nu văd mare pe pagina principală WordPress solved pingback bugs nici nu vreau să mai aud de ele.

Cam atât.

Notă: La cerere pot oferi și detalii concrete (linii de cod, nume de funcții, explicații suplimentare), dar nu prea văd care le-ar fi utilitatea. Dacă găseam ceva concret care să reprezinte un punct de plecare pentru o rezolvare, primul lucru pe care îl făceam era să deschid un raport pe bug tracker-ul autorilor.