How to Register elgg_cron_periods in Elgg3.2?

I have cronjob running every afternoon for my custom plugins. Below block of code works in Elgg2.3* but not Elgg3.2*.

//in my plugin/start.php

$all_crons = elgg_get_config('elgg_cron_periods');

$all_crons[ ] = 'afternoon';

elgg_set_config('elgg_cron_periods', $all_crons);

elgg_register_plugin_hook_handler('cron', 'afternoon', 'afternoon_cron_handler');


//in /etc/cron.d/my_crontab

30 16 * * *  root  /usr/bin/GET  https://mysite/cron/afternoon/

I followed instructions on how to trigger cron in Elgg3.2* here: After running vendor/bin/elgg-cli cron -i afternoon in my wwwroot directory, I faced 'Cache path is not writable' issue similarly to this thread I have my data directory permission set to 750 as recommended.

Please advice on how to trigger custom intervals in crontab for Elgg3.2*.


  • I would suggest to set up the cronjobs in crontab as done before using either the lwp-request or the wget command to trigger execution of the cronjobs per interval by calling the corresponding cron page url of your site.

    The elgg-cli method might work in some cases but I really don't know for whom. It surely did not work for me. The problem I had was that the command line command had to be executed as root user (!!!) as the webserver user who owns the data directory is not allowed to execute it and my normal user can't access the data directory. But with the root user executing elgg-cli any files and folders created by the command are owned by root and the webserver can't read/write any of them. Very confusing.

    I would suggest the following:

    1. remove any cronjobs in crontab that use the elgg-cli command.
    2. look into your data directory and make sure that the subfolders <data directory>/1 and <data directory>/1/1 are owned by the webserver account and have suitable permissions for the webserver to read, write and go into these folders.
    3. in the folder <data directory>/1/1 you probably find some log files created on execution of the cronjobs and these logs are probably owned by root. I would suggest to delete them.
    4. now you can add the cronjobs again to the crontab in the "old" way with using the wget or lwp-request command (what you have used before on Elgg 2.3).

    Hopefully, the cronjobs now work again. I never tried adding a custom cron interval so I can't say for sure if the approach you used on Elgg 2.3 still works on Elgg 3. But the first step is definitely getting the default cronjob intervals to work. Only then you can try a new one to see if it either works without issues or a different approach might be necessary on Elgg 3 to register the interval.

  • Thanks iionly! 

    Just wanted to clarify my post a little bit. Default core cronjobs such as fiveminute, halfhour, etc. are working fine on my Elgg3.2 site, only custom cronjobs that are not. With that being said, I'm going to start with removing/recreating crontab as well as removing all cron logs in <data directory>/1/1 as you suggested. 

  • I noticed that function run ( ) in <wwwroot>/vendor/elgg/elgg/engine/classes/Elgg/Cron.php allows only predefined intervals to run.

    if (!array_key_exists($interval, self::$intervals)) {

       throw new \CronException('.....');


    So if I understand it correctly, my custom interval will not run. 

  • I just found out the same thing.

    How about registering your cron handler function for the hourly interval and then checking in the function the time and only proceed with execution of your code when the hour matches a specfic number?

  • Something like

    $current_hour = date('G', time());
    if ($current_hour != '16') {

    If you want 16:30 you might need to use the halfhour interval instead. More format options to be found at Maybe comparing with a fixed number is not reliable (for hours it might work but for minutes it might be risky if there are ever other jobs registered in the same interval). So, you could compare against a min and max time instead.

  • This will solve my afternoon cron for sure. But the real challenge is that I have about 6-7 custom cronjobs and they are used in several plugins :).

    Really appreciate your help! 

  • As you already found out only the predefined cron intervals are supported.

    All hooks get 'time' in the $params, which is the timestamp the cron was started. So you can use that to determine if it's your hour/min

  • We found out it's a regression bug. We're going to fix it.

    However, you'll need to configure a bit more when registering the custom cron interval. Keep an eye out on the docs

Beginning Developers

Beginning Developers

This space is for newcomers, who wish to build a new plugin or to customize an existing one to their liking