Newsletter plugin Background Tasks

Hi Jax, 

You can see the last run time here: admin.php?menu=admin&action=general#background-tasks

It will still work if the cron only runs every 30 minutes, it will just take a lot longer to send out mail outs.  Really you need your host to run the cron once a minute, or to use a host that supports that.  Most do.

Hope that helps!

Hi Dave

Thank you for your reply.

The last newsletter sending in 2 days ago.  It seems not working.

Screenshot:

https://nimbus.everhelper.me/client/notes/share/273569/q1XB9khhk5N5BHTC20fxZrdzDfqTy5T1/

I have to click "run now >>" to finish the newsletter sending work.

----------------------------------------------------------------

Our hosting company is Hostgator.

They provide cron job feature.   I asked them the newsletter issue.

Our hosting company (Hostgator) said that is not their issues.  They want me ask the script company for solving the problem.

----------------------------------------------------------------

Is there any way for testing?

Hi Jax, 

Yea, just ask the host how to run the script located here (/home/quanmax/public_html/cmsAdmin/cron.php) every minute.

Let them know what you tried and that it's not working.  They may have a different way to call it or special instructions.

Once it is working, that "last run" value will be updated once a minute.

Let me know how it goes.

Hi Dave

HostGator limits cron jobs on Shared servers to run in 15 minute intervals, since excessive cron jobs can cause high loads on the server.

As I know.  Most hosting Shared server plan limit the Intervals.  Not in every minute.

is it the problem for the issue?

There is a clue.

our customer use their own mail server.

only web/database using hostgator Server.

Do you think It might be the problem?

Thanks!!

Hi Jax, 

The reason we want cron.php called every minute is because it's a cron "dispatcher".  It dispatches jobs as needed and only "if needed".  It saves us the work of setting up many many cron jobs every time we need one.

Most hosts we've seen (and we see a lot of hosts) allow cron jobs to run once a minute.  If you're doesn't, I'd make a special request that they allow it for a cron "dispatcher" script or consider moving to another host (or ask if they have plans that allow once a minute crons).

If you have to run with a cron only every 15 minutes, that's not recommended, but I'd increase this number by x15, eg: 7500:

// max messages to send in each batch, eg: If a cronjob runs the script every minute
// ... and this is set to 60, you'll send approx 1800 emails an hour
$GLOBALS['BACKGROUND_SEND_MAX'] = 500; 

Hope that helps!

Hi Dave

The issue has been solved.

There is an error email I got before: 

Cannot load the ionCube PHP Loader - it was built with configuration 2.2.0, whereas running engine is API220100525,NTS Zend Optimizer requires Zend Engine API version 220060519.
The Zend Engine API version 220100525 which is installed, is newer.
Contact Zend Technologies at http://www.zend.com/ for a later version of Zend Optimizer.

Warning: PHP Startup: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone. in Unknown on line 0

Fatal error: Directive 'allow_call_time_pass_reference' is no longer available in PHP in Unknown on line 0

The Hosting support replied:

It had two separate inis specific in the .htaccess file, and one had the wrong version of php in it.

It looked like it wasn't using php 5.3, so once it got switched to that in the htaccess file, then it started working again.

you had two ini files specified in one file, which are the configuration files for php and this one /home/quanmax/php.ini was using config code for a version other than the version being called (5.3) .

xxxxxx@xxxxxxx.com [~]# find -maxdepth 2 -name '.htaccess' -print -exec grep -i configpath {} \;
./.htaccess


./.htaccess
suPHP_ConfigPath /opt/php54/lib
suPHP_ConfigPath /home/quanmax/php.ini
./public_html/.htaccess

The "xxxxxx" is our site domain.

It had nothing to do with the mail servers.

It seems to be working fine now.

Hope the feedback helps.

Jax.

Hi Jax, 

Glad to hear it's working now, thanks for letting us know!

All the best,