1C-Битрикс разработчиците - изпълняват агент на всеки удар
Честно казано, доскоро бях убеден, не само на безполезността на личния ми корпоративен блог, но и безсмислието на корпоративни блогове като цяло. Но еволюцията не стои на едно място, Pithecanthropus заменя неандерталците, и стигнах до извода, че част от информацията не е по-добро място от един блог на интернет страницата на дружеството.
Тук бих искал да споделя с специалистите, извършващи интеграцията на нашата система, някои методи, които да ни помагат в ежедневната си работа, за да се идентифицира грешка в нашата система и потребителски скриптове. Последното, за щастие, много повече.
Нека започнем с агентите - най-добрият начин за диагностициране на проблема, ако това се случи в кода, който работи през равни интервали, на агента. т.е. грешката не се вижда на всяко посещение.
Най-добрият пример - грешка в модела (или свързан компонент от нея) се генерира автоматично разпределение. Обикновено такава грешка в синтаксиса, спрете съобщението за генериране на автоматично разпределение, а с него - и на агента на страницата, на която представителят е имал нещастието да бъде изпълнена.
Какво е това средство?
това
която е създадена с изпълнението на интервал от 60 секунди, в присъствието на най-малко един активен автоматично изпращане.
Да предположим, че сме направили грешка в изписването линия 66 се абонирате / subscr_news_my.php компонент
плъг-ин поколение модел автоматично изпращане:
Това, което имаме в крайна сметка?
На първото стартиране на агента (това е вероятно, че не ни хит, ако сайтът - работа) потребителят ще види две думи за добре дошли:
И, всъщност, всичко.
След актуализиране на съдържанието на страницата се показва перфектно, но следващия път, когато извършвате агент, въпреки усилията ни, не се движи напред; ние виждаме, че в действителност на агента не работи.
Какво да правим, как да стигнем до причината за проблема?
Да видим какво ще се случи след неуспешен старт на агента.
Ние намираме в нашия списък с агенти
и да разберете своята самоличност. Да - 122.
Извършване на SQL-заявка
и ние виждаме, че се оказва, че има и друг поле за въвеждане - DATE_CHECK (дата / час), а стойността му, от странно съвпадение, точно 10 минути по-късно от времето на последния неуспешен изпълнение агент.
Забележка: ценности и LAST_EXEC NEXT_EXEC не се променят, те "ще се движат", само след един успешен агент.
Така че, ясно е, че DATE_CHECK означава, следващия път агент се опитва да тече, но да чакат всеки път, на 10 минути - меко казано, странно.
Намираме съответния ред в ядрото на продукта
където
Моля, имайте предвид, че реалният ПР може да бъде заключена в $ _SERVER [ "HTTP_X_FORWARDED_FOR"], а не на $ _SERVER, в случай на конфигурация двустепенна [ "REMOTE_ADDR"].
Също така, за да деактивирате механизъм за кеширане успя когато се работи с агенти на използването на таблицата:
Сега агентът ще работи на всеки удар (ако, разбира се, не прави повече от един хит в секунда).
Но грешката, уви, все още не се вижда, че сега на всеки му хит, ние виждаме бял страница, която казва "Здравей".
Какво по дяволите е той, добре.
Всички вина - куче. Не е този, който с ушите и опашката, както и това, което се блокира изхода грешка.
Нашите разработчици със сигурност знаят по-добре (честно казано, ние вярваме, техническа поддръжка е вярно!), Но кръвта на нашите кучета пиеше много.
Все пак, за:
в CPostingTemplate :: Execute () (\ Битрикс \ модули \ абонирате \ класове \ общ \ template.php):
в CPostingTemplate :: AddPosting () (пак там):