Dezvoltatorii 1C-Bitrix - să efectueze un agent pe fiecare hit
Sincer, până de curând am fost convins nu numai inutilitatea blog-ul meu personal corporative, dar, de asemenea, inutilitatea de bloguri corporative, în general. Dar evoluția nu se opune în continuare, Pithecanthropus înlocuiește neandertalienii, și am ajuns la concluzia că unele dintre informațiile este un loc mai bun decât un blog pe site-ul companiei.
Aici aș dori să vă împărtășesc cu specialiștii care efectuează integrarea sistemului nostru, unele metode pentru a ne ajuta în munca noastră de zi cu zi pentru a identifica o eroare în sistemul nostru și scripturi personalizate. Acesta din urmă, din fericire, mult mai mult.
Să începem cu agenții - cel mai bun mod de a diagnostica problema, în cazul în care apare în codul care se execută la intervale regulate pe agentul. și anume eroarea nu este vizibil pe fiecare lovit.
Cel mai bun exemplu - o eroare în modelul (sau o componentă conectată a acestuia) generează automat de distribuție. Simplu o astfel de eroare de sintaxă, opriți eliberarea generație de distribuție automată, și cu ea - agentul și pagina pe care agentul a avut ghinionul să fie executat.
Ce este acest agent?
acest
care este creat cu implementarea unui interval de 60 de secunde, în prezența a cel puțin unei discuții automat activ.
Să presupunem că am făcut o eroare de sintaxă în linia 66 se aboneze componentă / subscr_news_my.php
plug-in generarea de model trimiterea automată:
Ceea ce avem în cele din urmă?
La prima lansare a agentului (este probabil ca nu pe lovit nostru dacă site-ul - lucru) utilizatorul va vedea două cuvinte de bun venit:
Și, de fapt, totul.
După actualizarea conținutului paginii este afișat perfect, dar data viitoare când efectuați un agent, în ciuda eforturilor noastre, nu merge mai departe; vedem că, de fapt, agentul nu funcționează.
Ce să fac, cum putem ajunge la cauza problemei?
Să vedem ce sa întâmplat după lansarea fără succes a agentului.
Ne găsim în lista noastră de agenți
și de a afla ID-ul său. Să - 122.
Efectuarea SQL-interogare
și vedem că, se pare că există un alt câmp de intrare - DATE_CHECK (data / ora), iar valoarea sa, printr-o coincidență stranie, exact 10 minute mai târziu decât timpul ultimului agent de execuție fără succes.
Notă: valorile și LAST_EXEC NEXT_EXEC nu se schimba, ei „se va muta“ numai după ce un agent de succes.
Deci, este clar că DATE_CHECK înseamnă data viitoare agentul încearcă să ruleze, dar să aștepte de fiecare dată de 10 minute - să-l puneți blând, ciudat.
Ne găsiți rândul corespunzător în nucleul produsului
unde
Vă rugăm să rețineți că IP reală poate fi blocat în $ _SERVER [ „HTTP_X_FORWARDED_FOR“], mai degrabă decât _SERVER $, în cazul unei configurații cu două niveluri [ „REMOTE_ADDR“].
De asemenea, pentru a dezactiva mecanismul de caching a reușit atunci când se lucrează cu agenți de utilizare tabel:
Acum, agentul va rula pe fiecare lovit (dacă sunteți, desigur, nu fac mai mult de un hit pe secundă).
Dar greșeala, din păcate, încă nu sunt vizibile, deși acum pe hitul fiecare, vom vedea o pagină albă pe care scrie „Hello“.
Ce dracu 'e, bun.
Toate vina - un câine. Nu este cel care, cu urechile și coada, și că producția de eroare care blochează.
Dezvoltatorii noștri știu cu siguranță mai bine (sincer, noi credem suport tehnic este adevărat!), Dar sângele câinele nostru a băut o multime.
Cu toate acestea, în ordine:
în CPostingTemplate :: Executare () (\ bitrix \ module de \ abona \ \ clase generale \ template.php):
în CPostingTemplate :: AddPosting () (ibid):