Hi,

I have created cron job that runs a php file once a day. Its working exactly as I want it I am just enquiring where I should save it in my site? Its a wordpress website and while testing it I have it saved in my public_html file. Im new to this so not sure its proper procedure to save it here or not?

Any advice would be really appreciated.

Donna :)

Dani AI

Generated

A short recap and practical next steps based on the thread: ’s cron is currently invoking a PHP file over HTTP from cPanel (lynx), so a “CLI-only” guard in the script will return 403 — HTTP requests run under a web SAPI, not the PHP CLI. The safest pattern is to avoid exposing DB-update code to the web and run it as a server-side CLI task or as a WordPress-aware scheduled task.

Recommended options (in order of security and reliability)

  • Run the job from the server CLI (preferred). If WordPress functions are needed, use WP‑CLI so the job executes in a WP context without web exposure. Example crontab line (replace paths/usernames to match the account):
0 3 * * * /usr/bin/wp --path=/home/username/public_html eval-file /home/username/scripts/update-courses.php >/dev/null 2>&1
  • Make it a scheduled WP event (wp_schedule_event) inside a tiny plugin or mu-plugin so WordPress handles the bootstrap and permissions. This avoids a separate script file altogether.

If a web-accessible script is unavoidable

  • Put the script in public_html only as a last resort and protect it by server rules (deny all except localhost and the host IP) and require HTTPS. Example .htaccess patterns:
# Apache 2.4
<IfModule mod_authz_core.c>
  Require ip 127.0.0.1
  Require ip ::1
</IfModule>

# Apache 2.2 fallback
Order deny,allow
Deny from all
Allow from 127.0.0.1

Also add a short-lived secret (HMAC+timestamp) or HTTP basic auth and keep secrets outside the webroot.

Operational tips and testing

  • Use absolute paths in cron and redirect output to a logfile for diagnostics.
  • Run the script manually over SSH with the PHP binary (or via WP‑CLI) to confirm CLI behavior and permissions.
  • Ensure the script and any secret files are owned by the account user and set to restrictive permissions (owner-only read/execute).
  • If SSH or WP‑CLI is unavailable on the host, request the provider’s recommended cron execution method.

This complements ’s points while offering WordPress-specific alternatives (WP‑CLI or scheduled hooks) that avoid exposing update logic to the web.

Recommended Answers

All 7 Replies

Hi!

If you can, place it outside the public_html directory, so it cannot be executed by requesting the file through the web.

Otherwise write this in top of the script:

<?php

    if(php_sapi_name() != 'cli')
    {
        header("HTTP/1.1 403 Forbidden");
        die('Error: 403 Forbidden.');
    }

Thanks Cereal, I added the above code and ran the cron job but it returned the Error: 403 Forbidden message rather than running it?

Uh, so how is this job executed?

Usually a cron job is listed into a crontab file and executed by the cron daemon running in the server, so it's an internal task. As explained here:

If you're using an external service to run the jobs or your hosting is practicing another method then just remove my code suggestion and leave the script in public_html, unless your hosting configuration does not suggest something different, if still in doubt ask to the support.

Ive set this to run daily via my host cpanel cron tab.

lynx -dump

testCronJobLIVE.php contains functions I want to run to update my sites database. It does exactly what I need I'm just not confident its secure enough where it is.

Would setting the folder and file permission to 711 suffice?

Would setting the folder and file permission to 711 suffice?

Hmm, no this doesn't solve, because the request will be executed through the TCP/IP stack, so the owner of the process will be the web server or the PHP server (in case of PHP-FPM) and any client through a web request could start the backup procedure.

Usually a cron job should be set like this:

/usr/bin/php /var/www/path/to/testCronJobLIVE.php

Or by setting the shebang in the script to define the executable:

#!/usr/bin/env php

echo 'Hello';

And then simply pointing the script in the crontab interface:

/var/www/path/to/testCronJobLIVE.php

That way you can set the script outside the public_html directory. But if you still want to stick with TCP solution, then you could set an extra header with a string value to match, something like:

<?php

if( ! array_key_exists('HTTP_AUTHORIZATION', $_SERVER) || $_SERVER['HTTP_AUTHORIZATION'] != 'Donna')
{
    header("HTTP/1.1 403 Forbidden");
    die('Error: 403 Forbidden.');
}

# execute your code
print 'hello';
print PHP_EOL;

And at cron job level:

curl --header "Authorization: Donna" 

I'm not sure lynx can set custom headers as it is a browser. You could use curl as in my example or httpie:

http GET  "Authorization: Donna"

Is this secure? Not really, if the request is intercepted then the header could be read, unless you can send through https.

Thanks, I am going to park it for now and get back to it. Think I need to learn a whole lot more before going any further with it.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.