Этот файл служит в качестве точки входа в рассматриваемое здесь приложение. Его имя указывается как команда для выполнения из командной строки. Ниже приведена первая часть исходного кода из этого файла.

// объявить, что это достоверная точка входа в Joomla!, если еще не объявлено
if ( defined ('_JEXEC') )
{
define ('_JEXEC'); }

// задать константу для базового пути к файлам приложения, если она еще не задана
if (!defined('JPATH_BASE')) {
define('JPATH_BASE', dirname( FILE ));
}

// импортировать платформу Joomla!
require dirname(dirname( FILE )) . '/libraries/import.php';

// импортировать библиотечные зависимости
jimport('joomla.log.log');
require JPATH_BASE . '/subscriptionmonitor.php';

В этой части исходного кода из контрольного файла проверяется, определены ли константы JEXEC и JPATHBASE. Следует иметь в виду, что в данном примере файл начальной загрузки bootstrap.php не используется, а вместо него включается файл импорта.

Кроме того, команда require настраивается на поиск файла import.php относительно местоположения текущего файла (т.е. контрольного файла monitor.php). Как только файл import.php будет загружен, из библиотеки могут быть импортированы все классы, необходимые для нормальной работы данного приложения. Для этой цели требуется только класс JLog. Затем включается программный файл subscriptionmonitor.php. Ниже приведена следующая часть исходного кода из контрольного файла.

// загрузить конфигурационный файл configuration.php
$config = JFactory::getConfig(JPATH_BASE.'/configuration.php');

//  создать журнал регистрации и получить  дату, чтобы просматривать журналы регистрации в  определенном временном интервале
$date = JFactory::getDate()->format(* Y-m-d *);

//  добавить регистратор
JLog::addLogger(

//  передать массив параметров конфигурации. Примечание: по умолчанию в файл журнала регистрации записывается  отформатированный текст
array(

// задать имя файла для журнала регистрации
'text_file' => 'monitor-.'.$date.'.php',

// задать путь к файлам с журналами регистрации
text_file_path' => DIR .'/logs/'
)
);

В этой части исходного кода устанавливается конфигурация с помощью созданного ранее файла configuration. php. Следует заметить, что для этой цели вместо объекта в переменной $conf ig при выполнении метода getConf ig () создается объект типа JConfig (JFactory: : $config), который используется сначала в методе JFactory: :getDate (), а затем и в методе JFactory: :getMailer (). Благодаря этому в самом начале данного приложения задается нужный конфигурационный файл configuration.php. Если же, например, вызвать метод JFactory: : getDate () до создания объекта типа JConfig, то загружен будет файл configuration.php из места, задаваемого по умолчанию с помощью константы JPATHPLATFORM, а это совсем не то, что нам требуется.

Далее файл журнала регистрации создается средствами класса JLog. В его имя включается текущая дата, и благодаря этому каждый день получается новый файл. Этот файл размещается в созданной ранее папке logs.

Ниже приведена следующая часть исходного кода из контрольного файла.

//  заключить  выполнение  кода в  блок операторов  try/catch, чтобы перехватить любые исключения,   генерируемые в  сценарии
try
{

// получить экземпляр объекта и выполнить приложение
JCli::getlnstance('SubscriptionMonitor')->execute(); } catch (Exception $e)

//  исключение перехвачено, добавить сообщение в журнал регистрации 
JLog: :add($e->getMessage () , JLog: .-ERROR) ; exit($e->getCode());

В этой части исходного кода создается блок операторов try/catch, в котором сначала получается экземпляр объекта типа JCli, а затем выполняется метод execute () из класса SubscriptionMonitor. Как будет показано далее, в этом классе имеется целый ряд методов, генерирующих исключения, поэтому если метод execute () вызывается внутри блока оператора try, то этим гарантируется перехват и обработка любых исключений, генерируемых в каком угодно месте этого метода. А в блоке оператора catch сообщение о возникшей исключительной ситуации записывается в журнал регистрации. Следует иметь в виду, что данное приложение предназначено для автоматического выполнения на сервере, поэтому возникающие в нем ошибки лучше записывать в журнал регистрации, чем выводить на консоль.

Весь код текущего контроля подписок можно было бы поместить в одном этом контрольном файле, чтобы не создавать еще один. Принятый в данном случае подход имеет следующее важное преимущество: он позволяет очень легко вводить дополнительные функции текущего контроля. Допустим, требуется также контролировать дату окончания публикации статей. Для этого достаточно создать новый класс текущего контроля статей и добавить строку кода для его выполнения в блок оператора try из файла monitor. php. В одном этом файле можно было бы организовать функции текущего контроля всего вебсайта, назначив его выполнение на сервере в виде одного простого задания по команде сгоn.