Bitrix pull
Covers Pull module — sending realtime events to users/channels from PHP, JS subscription overview, watch tags, when to use Pull vs Messenger vs agents, link to BitrixVue. Applied for live UI updates, notifications, collaborative screens. Key terms — pull, Bitrix\Pull\Event, CPullWatch, CPullChannel, BX.PULL.subscribe, extendWatch, queue server, push.From its SKILL.md
npx -y skills add bxmaximum/bitrix-framework-skills --skill bitrix-pullAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 19 stars19 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
4.9 KB, ~1.2k tokens by cl100k_base, as published. Nobody here has run it
Realtime Pull (pull)
pull delivers short realtime commands to browsers/mobile via a queue server (WebSocket / long polling / JSON-RPC). Baseline: main 23.0+. Requires the Pull/queue server to be enabled (CPullOptions::GetQueueServerStatus()); otherwise events are dropped after buffering logic.
\Bitrix\Main\Loader::includeModule('pull');
Pull vs Messenger vs Agents
| Mechanism | Use for |
|---|---|
| Pull | Instant UI sync (“row updated”, counters, presence-like hints) |
Messenger (bitrix-background-jobs) | Reliable async work with retries/queues (Since 25.100.300, alpha) |
| Agents / cron | Periodic batch jobs, cleanup, polling external systems |
Do not use Pull as a job queue. Do not use Messenger to push browser paint updates — emit Pull from the worker when the UI must refresh.
Send to User(s) from PHP
Primary API: Bitrix\Pull\Event::add($recipient, array $parameters, $channelType = \CPullChannel::TYPE_PRIVATE).
Required in $parameters: module_id, and either command (+ optional params) or push payload fields.
<?php declare(strict_types=1);
use Bitrix\Main\Loader;
use Bitrix\Pull\Event;
Loader::includeModule('pull');
Event::add($userId, [
'module_id' => 'vendor.module',
'command' => 'item.updated',
'params' => [
'id' => $itemId,
'title' => $title,
],
// 'expiry' => 86400, // optional; default applied in Event::prepareParameters
]);
// Multiple users:
Event::add([1, 2, 3], [
'module_id' => 'vendor.module',
'command' => 'list.refresh',
'params' => [],
]);
- Recipients: user IDs, channel IDs (32-char strings), or
Bitrix\Pull\Model\Channelinstances. - Channel types:
\CPullChannel::TYPE_PRIVATE(default),TYPE_SHARED, etc. - Sending is deferred via
Application::addBackgroundJob/Event::sendon epilog — usually you only calladd(). - Legacy wrappers:
CPullStack,Bitrix\Pull\Push::add(push notifications path).
On failure, inspect Event::getLastError().
Shared Tags (CPullWatch)
Subscribe users to a tag, then broadcast to everyone watching that tag:
<?php declare(strict_types=1);
use Bitrix\Main\Loader;
Loader::includeModule('pull');
\CPullWatch::Add($userId, 'VENDOR_ITEM_' . $itemId);
\CPullWatch::AddToStack('VENDOR_ITEM_' . $itemId, [
'module_id' => 'vendor.module',
'command' => 'item.updated',
'params' => ['id' => $itemId],
]);
CPullWatch::Extend($userId, $tags)— refresh subscriptions (also used from pull controllers/JS).- Tag messages still go through
Event::addunder the hood.
JS Subscription Overview
Client global: BX.PULL (PullClient, extension pull.client / product core load). Subscribe:
const unsubscribe = BX.PULL.subscribe({
moduleId: 'vendor.module',
command: 'item.updated', // optional; omit to get all module commands
callback: (params, extra, command) => {
// update UI
},
});
// Watch tag (pairs with CPullWatch):
BX.PULL.extendWatch('VENDOR_ITEM_' + itemId);
subscribe returns an unsubscribe function. Alternative: attachCommandHandler with an object exposing getModuleId() and command methods.
In BitrixVue apps (bitrix-vue), subscribe in mounted / setup and unsubscribe on unmount; keep moduleId/command identical to PHP Event::add.
Queue helper extension: pull.queuemanager wraps BX.PULL.subscribe + extendWatch for list/grid sync patterns.
Push (Mobile)
Optional push / pushParamsCallback keys on Event::add enqueue mobile push via CPushManager when push is enabled (CPullOptions::GetPushStatus()). Treat as a separate channel from browser Pull commands.
Operational Notes
- Parameters must be UTF-8; invalid encoding is rejected.
- Keep payloads small (IDs + flags); fetch heavy data via AJAX/REST after the event.
- Shared channel / guest modes depend on Pull options — verify before designing guest UX.
- Module may expose REST helpers (
Bitrix\Pull\Rest, controllerconfigfor watch extend) whenrestIntegrationis enabled in pull.settings.php.
Checklist
-
pullmodule loaded; queue server enabled in environment. - Events use stable
module_id+commandnames shared with JS. - Recipients are user IDs or valid channels; tags use
CPullWatchconsistently. - UI handlers unsubscribe / avoid leaks in SPA/Vue.
- Pull not used as a durable job queue (use Messenger/agents).
- Large data loaded on demand after the signal.
Related skills
bitrix-background-jobs, bitrix-vue, bitrix-extensions, bitrix-controllers, bitrix-rest.
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.