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

sâmbătă, 28 ian. 2012, 11:52

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 A scrie un articol P iar B scrie un articol P' care face referință la chestii din P, atunci putem stabili existența unei legături concrete P \rightarrow P', legătură concretizată printr-un sumar al lui P' în cadrul comentariilor lui P. 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.

Comments

  • Sa-mi fie iertata apostazia, da’ un mod relativ simplu de-a face debug pentru php (mai ales cind e scris de idioti, si crede-ma c-am vazut la Polimedia cod scris de idioti mult, mult mai dusi decit Automattic) e sa introduci hapt in mijlocul trebilor un

    mail („email@domeniul.tau”, „Debug la X timpenie”, $context);

    In felul asta macar iti poti da seama cum cind si unde se executa, ceea ce poate sa ajute.

    Uneori in practica chiar ajuta. Da, stiu ca nu se face asa. Da, stiu ca-i ridicol.

  • spyked spune:

    Ca om care face debug cu printf-uri zilnic nu pot să zic că mi se pare o idee așa de proastă. Eu am folosit WP_DEBUG_LOG și echo-uri acolo unde s-a putut. Practic am băgat niște apeluri în do_all_pings și mi-am dat seama că nu ajunge acolo, da’ ajunge să facă schedule la ea.

    După cum ziceam și în articolul inițial, există o șansă ca problema să fie de la mine, având în vedere că server-ul e undeva la limită cu load-ul pe memorie din cauza Apache-ului, care duce lejer memory usage-ul peste 90%. Da’ când m-oi apuca să configurez server-ul nou am de gând să încerc treaba cu MPM-Worker și FastCGI și poate atunci o să îmi dau seama dacă asta-i sursa.

    • N-are cum fi asta dat fiind ca din ce-mi amintesc wp nu masoara memory load nicaieri in cod, si php-ul nu stie el distinge intre scripturi.

      • spyked spune:

        Există totuși posibilitatea ca din cauza limitării de memorie să nu se poată executa anumite script-uri. Bine, asta-i pură speculație, dar o fac pentru că pe site-urile de suport lumea susține că instanțele (cod + bază de date) de wordpress noi n-au probleme cu pingback-ul, iar eu am încercat și asta și tot nu a vrut.

        A, dar partea interesantă e că pot primi pingback-uri fără probleme, chit că nu merge să trimit.

      • Auzi nu cumva e o problema de akismet ?

  • spyked spune:

    Nu mi-a trecut prin cap, dar e foarte posibil să fie. Momentan am de migrat toată configurația curentă pe o mașină nouă, deci nu prea îmi vine să testez chestii, dar după aia o să mai verific toată povestea inclusiv cu toate plugin-urile dezactivate să văd ce se întâmplă.

  • […] Mircea Popescu Cetateanul Mogosanu articuleaza in articolul intitulat “ce am învățat despre sistemul de pingback-uri din wordpress” o problema destul de serioasa : uneori astea pur si simplu nu […]

  • […] a găsi parametrii cei mai potriviți ai server-ului web și ai WordPress-ului, care apropo, tot o mizerie scrisă cu piciorul stâng rămâne. Dar ăsta e, cu el defilăm, nu-i ca și cum o să mă apuc eu să scriu un CMS mai bun […]

  • Ca bonus : fain trimite fara probleme pingback catre Trilema si catre orice blog pe domeniu propriu. Trimite exact la fel si catre bloguirle de pe wordpress.com, da’ nu apare nimic. Pur si simplu, nu apar in spam, nu apar deloc. Am incercat /articol/trackback, /articol/trackback/, blog.wordpress.com/xmlrpc.php.

    Mizerie scrisa cu piciorul sting, pe bune.

  • spyked spune:

    Asta-i cu atât mai rău cu cât n-ai cum să-ți dai seama ce versiune de WordPress e folosită pe .com (presupunând că ei merg pe același branch de dezvoltare cu varianta open source), deci e practic imposibil să încerci să replici problema pe o instanță hostată privat având aceeași versiune.

    Pe mine mă miră cum un protocol relativ simplu cum e pingback-ul dă atâtea bătăi de cap. Și chiar e simplu, adică specificația lui are undeva sub 2500 de cuvinte, nu-i ca și cum ar putea pune probleme majore, de unde deduc că problema e a diverselor componente din WordPress, nu a protocolului în sine.

  • […] exemplu de care m-am lovit recent este cel al pingback-ului peste WordPress, care poate fi stricat relativ ușor de un router având configurarea NAT-ului […]

  • […] legături HTML atât în sens direct, prin link-uri propriu-zise, cât și în sens invers prin pingback-uri. O altă structurare poate fi obținută prin etichete, însă despre acestea vom discuta poate cu […]

  • Comentariile sunt dezactivate.