Configure Bitrix Newsletter IBLOCK News for Scheduled Emails

To get Bitrix newsletter sending working reliably with IBLOCK news in scheduled emails, focus on proper Bitrix agents configuration via cron jobs and ensuring the subscribe module loads in your bitrix:subscribe.news template. Common pitfalls include missing cron_events.php scripts that call CPosting::AutoSend(), unset agent options like agents_use_crontab=“N”, or PHP timeouts blocking news fetches during automated runs. Test by verifying IBLOCK items are active and templates reference correct SITE_ID, then monitor agent logs for failures.

Contents

• Common Issues with Bitrix Newsletter and bitrix:subscribe.news in Scheduled Emails
• Proper Configuration of Bitrix Agents for Automated Newsletter Sending
• Setting Up Cron for Bitrix Cron and CPosting::AutoSend()
• Fixing bitrix:subscribe.news Template: IBLOCK Parameters and Module Inclusion
• Step-by-Step Guide to Configure Bitrix Newsletter with Agents on Cron
• Troubleshooting Bitrix Newsletter Automatic Failures
• Optimizing PHP Limits and Mail Queues for Bitrix Email Newsletters
• Testing and Monitoring Bitrix Agents on Cron
• Sources
• Conclusion

Common Issues with Bitrix Newsletter and bitrix:subscribe.news in Scheduled Emails

Ever set up a Bitrix newsletter that shines in manual tests but ghosts you at 5 AM? You’re not alone. The bitrix:subscribe.news component pulls IBLOCK news like a champ during “Send Test” from the Issues page, but scheduled emails often arrive empty— just that lonely “Store News” header, no articles. Why?

Manual sends hit the system directly, bypassing the full agent queue. Automated ones rely on Bitrix agents and cron, which might not trigger CPosting::AutoSend() properly. Your template code looks solid at first glance: it sets globals like $SUBSCRIBE_TEMPLATE_RUBRIC, includes the component with IBLOCK_TYPE=“news”, SORT_BY=“ACTIVE_FROM”, and returns SUBJECT/BODY if $SUBSCRIBE_TEMPLATE_RESULT is truthy. But here’s the rub—in cron mode, the subscribe module might not load, or IBLOCK queries fail silently due to permissions, inactive items, or missing SITE_ID context.

Other culprits? PHP memory limits choking on bulk fetches, or agents stuck because “agents_use_crontab” isn’t disabled for on-hit execution. Check your admin logs first: go to Settings > Agents, and see if posting agents are firing. No activity? Cron’s your missing link.

Proper Configuration of Bitrix Agents for Automated Newsletter Sending

Bitrix agents are the heartbeat of scheduled tasks like newsletters. By default, they run on every page hit (inefficient for production), but for reliable Bitrix newsletter automation, switch to full cron control.

Head to Settings > Settings > Modules > Main module settings. Set these options:

• agents_use_crontab: “N” (disables crontab mode initially, forces on-hit for testing)
• check_agents: “N” (prevents double-execution)

No, wait—flip that for production. Actually, Bitrix24 training materials recommend setting both to “N” when using a dedicated cron script. This stops web-triggered agents from interfering.

Agents like “CPosting::AutoSend()” get auto-created when you schedule a newsletter issue. But if they’re not running, manually add one: in Agents list, create new with code CPosting::AutoSend(); on a 300-second interval. Still flaky? Time for cron.

Think of agents as reminders—cron’s the alarm clock that actually wakes them up.

Setting Up Cron for Bitrix Cron and CPosting::AutoSend()

Cron is non-negotiable for Bitrix cron handling high-volume newsletters. Without it, your 5 AM sends sleep through the night.

Create /bitrix/php_interface/cron_events.php (or in /local/php_interface/ for safety):

<?php
define("NO_KEEP_STATISTIC", true);
define("NOT_CHECK_PERMISSIONS", true);
define("NO_AGENT_CHECK", true);
define("DisableEventsCheck", true);
define("BX_CRONTAB_SUPPORT", true); // Key for Bitrix cron mode

@set_time_limit(0);
@ignore_user_abort(true);

require($_SERVER["DOCUMENT_ROOT"]."/bitrix/modules/main/include/prolog_before.php");

COption::SetOptionString("main", "agents_use_crontab", "Y");
COption::SetOptionString("main", "~check_agents", "N");

CAgent::CheckAgents();
CEvent::CheckEvents();

if (CModule::IncludeModule('subscribe')) {
 $cPosting = new CPosting;
 $cPosting->AutoSend();
}

require($_SERVER["DOCUMENT_ROOT"]."/bitrix/modules/main/include/epilog_after.php");
?>

This script, pulled from Bitrix documentation patterns, calls CPosting::AutoSend($ID=false, $limit=false) to process all due issues. The $ID=false flag hits everything scheduled.

Add to crontab (via crontab -e):

*/5 * * * * /usr/bin/php -f /path/to/site/bitrix/php_interface/cron_events.php >/dev/null 2>&1

Every 5 minutes ensures no backlog. For daily newsletters, loosen to hourly, but monitor.

Adjust mail_event_bulk in php.ini or Bitrix settings to 20+ for queue handling.

Fixing bitrix:subscribe.news Template: IBLOCK Parameters and Module Inclusion

Your template’s close, but missing one killer line: CModule::IncludeModule('subscribe'); before the component call. Without it, bitrix:subscribe.news blanks out in cron contexts—no module, no news.

Updated template snippet:

<?
if(!defined("B_PROLOG_INCLUDED") || B_PROLOG_INCLUDED!==true) die();
global $SUBSCRIBE_TEMPLATE_RUBRIC;
$SUBSCRIBE_TEMPLATE_RUBRIC = $arRubric;
global $APPLICATION;

CModule::IncludeModule('subscribe'); // CRITICAL: Load subscribe module
CModule::IncludeModule('iblock'); // For IBLOCK news access
?>
<!-- Your CSS here -->
<P>Store News</P>
<P><?$SUBSCRIBE_TEMPLATE_RESULT = $APPLICATION->IncludeComponent(
 "bitrix:subscribe.news",
 "",
 Array(
 "SITE_ID" => SITE_ID, // Use dynamic SITE_ID, not hardcoded "s1"
 "IBLOCK_TYPE" => "news",
 "ID" => "", // Empty for all active; test with specific ID like "5"
 "SORT_BY" => "ACTIVE_FROM",
 "SORT_ORDER" => "DESC",
 "ACTIVE_DATE_FORMAT" => "d.m.Y",
 "CACHE_TYPE" => "N", // Disable cache for dynamic scheduled pulls
 ),
 null,
 array("HIDE_ICONS" => "Y")
);?></P>

<?if($SUBSCRIBE_TEMPLATE_RESULT) {
 return array(
 "SUBJECT" => $SUBSCRIBE_TEMPLATE_RUBRIC["NAME"],
 "BODY_TYPE" => "html",
 "CHARSET" => "UTF-8",
 "DIRECT_SEND" => "Y",
 "FROM_FIELD" => $SUBSCRIBE_TEMPLATE_RUBRIC["FROM_FIELD"],
 );
} else {
 return false;
}?>

As noted in the official subscribe docs, verify IBLOCK_TYPE=“news” has active elements with future ACTIVE_FROM dates matching your schedule. Hardcode ID=“5” for testing one article. SITE_ID must match the rubrics’s site.

Step-by-Step Guide to Configure Bitrix Newsletter with Agents on Cron

Ready to wire this up? Here’s the no-BS walkthrough.

1. Prep Agents: Settings > Agents. Delete stalled CPosting agents. Set agents_use_crontab=“N”, check_agents=“N”.

2. Fix Template: Add module includes as above. Save, assign to rubric.

3. Create Issue: Newsletters > Issues > Add. Pick rubric, set daily 5 AM schedule, paste template. Mark active.

4. Build Cron Script: Drop cron_events.php in php_interface. Test manually: php -f /path/cron_events.php

5. Crontab It: */5 * * * * php -f /path/cron_events.php

6. Tune PHP: In script, @ini_set('memory_limit', '512M'); @set_time_limit(600); Bump mail_event_bulk=50.

7. Site Config: In .settings.php, ensure ‘exception_handling’ => array(‘value’ => array(‘debug’ => false, …))

Re-test: Manual send should now populate news. Wait for cron cycle.

Troubleshooting Bitrix Newsletter Automatic Failures

Still no dice? Dig deeper.

• Logs: /bitrix/modules/main/admin/agent_list.php?lang=en—check last_exec. Errors? Tail /bitrix/.logs/*

• IBLOCK Check: Admin > Content > IBLOCKs > news. Active items? Moderated=Y? Dates valid?

• Rubric Match: Newsletters > Rubrics. FROM_FIELD set? Matches template?

• Permissions: Run cron as web user (www-data). chown -R www-data:www-data bitrix/php_interface/

• No News? Add debug: echo "IBLOCK count: ".CIBlockElement::GetList([], ['IBLOCK_TYPE'=>'news', 'ACTIVE'=>'Y'], false, false, ['ID']); before component.

From community cron guides, stale sessions kill it—NO_KEEP_STATISTIC fixes that.

Agents not starting? bx agents_start CLI tool.

Optimizing PHP Limits and Mail Queues for Bitrix Email Newsletters

Bulk Bitrix email newsletters chew resources. PHP timeouts during news pulls? Your culprit.

In cron_events.php:

@ini_set('max_execution_time', 0);
@ini_set('memory_limit', '1G');
@set_time_limit(0);

Mail queue: Settings > Modules > Mail > Events > Bulk size to 100. Use DIRECT_SEND=“Y” sparingly—switch to “N” for high volume, let queue handle.

SMTP? Configure in Settings > Modules > Mail. Test with php -m | grep mail for extensions.

Scale with supervisord for multiple cron workers if newsletters grow.

Testing and Monitoring Bitrix Agents on Cron

Proof it works: php -f cron_events.php—watch Issues status flip to “Sent”.

Monitor: Add to script file_put_contents('/tmp/cron.log', date('Y-m-d H:i:s')." - AutoSend run\n", FILE_APPEND);

Tools: Prometheus exporter for Bitrix metrics, or simple agent count queries.

Dark pattern? Cron ran, but no emails—check spam, unsubscribe rates in stats.

Patience: First run clears backlog.

Sources

1. Subscribe Module Documentation — Official guide to bitrix:subscribe.news component and template usage: https://dev.1c-bitrix.ru/api_help/subscribe/index.php
2. Bitrix24 Cron Training — Step-by-step cron_events.php setup for agents and CPosting::AutoSend(): https://training.bitrix24.com/support/training/course/?COURSE_ID=113&LESSON_ID=9659
3. CPosting::AutoSend API — Details on automated newsletter sending via cron scripts: https://training.bitrix24.com/api_help/subscribe/classes/cpostinggeneral/cpostingautosend.php
4. Bitrix Cron Recipes — Practical cron configuration with prolog/epilog includes: https://bitrix-notes.readthedocs.io/en/latest/cron.html

Conclusion

Nailing Bitrix newsletter sends with IBLOCK news boils down to cron-powered agents, module-loaded templates, and tuned limits—manual tests pass, but automation demands this full stack. Start with the cron_events.php script and template tweaks; you’ll see news populate in scheduled emails within cycles. Monitor agents religiously, and scale PHP as volume grows. If issues persist, IBLOCK activity or perms are next suspects. Solid setup means reliable daily blasts—no more empty headers.