Check application compatibility first
Identify the PHP versions supported by the application core, theme and every required extension. Upgrade the application before removing a PHP version it still needs. Take matching file and database backups, then test the version change on a non-public hostname or during a maintenance window.
Select the PHP environment
Choose a supported PHP version, the current stable 64-bit environment and PHP execution engine unless the application documents a different requirement. Use production mode for a public site. Development mode can display paths, SQL details and configuration values to visitors and should be enabled only for a short diagnostic test.
Understand configuration scope
The main PHP configuration applies to the hosting root unless a more specific directory-level runtime configuration exists lower in the tree. That local configuration can affect its folder and descendants. Keep one deliberate configuration per scope, record why a site differs from the default and avoid copying an old runtime file into a new document root without reviewing its PHP version and environment.
Test after a runtime change
Open a static file, a minimal PHP page, the application homepage and its administration area. Then exercise one database-backed action and inspect the error log. A blank page after a version change usually indicates a fatal PHP compatibility error; restore the previous runtime first, then update or replace the incompatible code.
Use environment variables for application settings
Supported application runtimes can receive configuration through environment variables so deployment files do not need to contain database passwords or API keys. Mark secrets as passwords, grant them only to the required runtime and rotate any value that has appeared in logs or source control. Environment variables are configuration, not a substitute for a secrets backup in an approved password manager.
Create a scheduled task
Place the script inside the hosting storage and verify that it runs successfully once before scheduling it. Define the exact script command, compatible runtime, schedule and notification address. Use absolute or hosting-relative paths supported by the service rather than assuming an interactive shell working directory.
Prevent overlapping jobs
A scheduled task must tolerate a previous run still being active. Use an application lock, idempotent processing or a queue so two executions cannot send the same message, import the same record or rewrite the same file. Keep execution time comfortably below the interval and log a concise success or failure result without secrets.
Diagnose a cron failure
Run the same script manually with the selected runtime, confirm its file permissions and paths, and check the notification destination and application log. A script that works in a browser can still fail in cron because it relies on HTTP headers, session state or a different working directory. Do not solve this by making sensitive scripts publicly accessible.
