DEV Community: ShoHost

WP-Cron Is Not a Cron: Moving WordPress to a Real Scheduler on cPanel

ShoHost — Mon, 26 Oct 2026 05:09:09 +0000

WordPress has a scheduler called WP-Cron, and it handles more than most people realise: scheduled posts, WooCommerce order cleanups, backup plugins, security scans, update checks. The catch is in how it runs. WP-Cron isn't a real cron job. It only fires when someone visits your site.

That one design choice causes two opposite problems:

Quiet sites miss jobs. If nobody visits at 3 AM, the 3 AM backup doesn't start until the first visitor arrives. Scheduled posts show "Missed schedule".
Busy sites run it too often. On every page load, WordPress checks whether anything is due and may spawn a loopback request to wp-cron.php. Under traffic, that adds up to a lot of pointless PHP work.

The fix is the same on almost any cPanel account: switch off the visit-triggered version and call WP-Cron from the server's own scheduler instead.

1. Turn off the page-load trigger

Open wp-config.php and add this line above /* That's all, stop editing! */:

define( 'DISABLE_WP_CRON', true );

This doesn't remove WP-Cron. Scheduled events still exist; they just stop firing on page loads. Don't save this change without doing step 2, or nothing scheduled will run at all.

2. Add a real cron job in cPanel

In cPanel, open Advanced > Cron Jobs, pick a schedule, and add a command. Every 5 minutes is a sensible default for most sites; every 15 is fine for a small blog.

The most reliable command runs WordPress through PHP directly, so it doesn't depend on DNS, SSL or a firewall letting a request back in:

cd /home/USERNAME/public_html && /usr/local/bin/php wp-cron.php > /dev/null 2>&1

Replace USERNAME and the path with your own. If WP-CLI is available on your account, this is even cleaner, because it only runs events that are actually due:

cd /home/USERNAME/public_html && wp cron event run --due-now > /dev/null 2>&1

Check which PHP binary matches your site's PHP version. On many cPanel servers the default php in cron is a different version from the one your site uses, which is a classic "works in the browser, fails in cron" cause. Your host's docs or which php over SSH will tell you the right path.

3. Check it's actually running

Install a cron viewer plugin such as WP Crontrol for a few days, or run:

wp cron event list

Look at the "next run" column. If events keep sliding into the past and never run, the cron command is failing. Remove > /dev/null 2>&1 temporarily and set a cron email address in cPanel so you can see the error.

4. A few things to watch

Multisite: each site has its own queue. With WP-CLI, loop over wp site list --field=url and pass --url= to each run.
Heavy jobs: if a backup plugin runs for 20 minutes, a 5-minute cron can start overlapping runs. Most backup plugins lock themselves, but check.
Staging copies: clone a site and you clone DISABLE_WP_CRON. Add the cron job on staging too, or turn the constant off there.

This takes ten minutes and makes scheduled tasks predictable, which is usually what people actually wanted when they scheduled them. If you'd rather start on hosting that already gives you cPanel cron, SSH and a choice of PHP versions out of the box, take a look at ShoHost's cPanel WordPress hosting.

First 30 Minutes on a New Windows RDP Server: A Hardening Checklist

ShoHost — Sun, 25 Oct 2026 05:09:23 +0000

A Windows server with Remote Desktop open to the internet starts getting password guesses within hours of going online. Bots scan the whole IPv4 range for port 3389 and try Administrator with every leaked password they have. None of this is targeted at you, which is exactly why the basics stop most of it.

Here's the checklist I run on any fresh Windows RDP box before installing a single app. It takes about half an hour and needs nothing beyond what ships with Windows.

1. Patch before anything else

Open Windows Update, install everything, reboot, and check again. Fresh images are often a few months behind, and RDP-related vulnerabilities have been some of the most exploited Windows bugs of the last few years. Don't put this off until "after setup".

2. Stop using the built-in Administrator account

Every brute-force tool tries Administrator first. Create your own admin account with a long passphrase (16+ characters, never reused anywhere):

$pw = Read-Host -AsSecureString "Password"
New-LocalUser -Name "opsadmin" -Password $pw -PasswordNeverExpires
Add-LocalGroupMember -Group "Administrators" -Member "opsadmin"

Sign out, connect again as the new account, and only once that works, disable the built-in one:

Disable-LocalUser -Name "Administrator"

Use a name that isn't obvious. admin, user and your company name are all on the guess lists.

3. Turn on account lockout

By default, Windows lets an attacker keep guessing. A lockout policy slows them down to a crawl:

net accounts /lockoutthreshold:5 /lockoutwindow:30 /lockoutduration:30

That locks an account for 30 minutes after 5 bad passwords within 30 minutes. You can set the same thing in secpol.msc under Account Policies > Account Lockout Policy. Run net accounts afterwards to confirm the values stuck.

4. Make sure Network Level Authentication is on

With NLA, the client has to authenticate before Windows builds a full login session, which cuts the load from bots and blocks some pre-login attacks. It's on by default on current Windows, but images and old guides sometimes switch it off. Check it in System Properties > Remote ("Allow connections only from computers running Remote Desktop with Network Level Authentication"), or from PowerShell:

Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name UserAuthentication

A value of 1 means NLA is required. If it's 0, set it back:

Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name UserAuthentication -Value 1

5. Limit who can reach the port (only if your IP is static)

If you always connect from an office with a fixed IP, tell Windows Firewall to accept RDP from that address only:

Set-NetFirewallRule -DisplayGroup "Remote Desktop" -RemoteAddress 203.0.113.10

Replace the example address with yours. Be careful here: if your home or office IP changes, this rule locks you out too. If your connection uses a dynamic IP, skip this step and rely on the lockout policy and a strong passphrase.

About changing the RDP port: it cuts log noise but it isn't real security, and some hosted plans only open the standard RDP port upstream. Check with your provider before you touch it.

6. Look at who's knocking

Failed logons are logged as event ID 4625 in the Security log. A quick look tells you whether the bots have found you yet:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 20 |
  Select-Object TimeCreated, @{n='Account';e={$_.Properties[5].Value}}, @{n='Source';e={$_.Properties[19].Value}}

If you see hundreds of attempts against names like admin or test, the lockout policy and the renamed admin account are doing their job. If you see attempts against your real admin name, that name has leaked somewhere, so change it along with the password.

7. Treat it as a server, not a laptop

Keep Microsoft Defender on and check it with Get-MpComputerStatus (look for RealTimeProtectionEnabled : True).
Don't browse random sites or open email attachments on the server. Most "my RDP got hacked" stories start with a download, not a brute-forced password.
Give each person their own login instead of sharing one admin password over chat, and remove accounts the day someone stops needing them.
Keep copies of important files somewhere other than the server itself.

8. Write down what you changed

A short note with the admin account name, the lockout settings and any firewall rules saves a lot of guesswork six months later, especially when someone else has to log in.

Where to run it

All of this works on any Windows machine you can reach over RDP. If you want a remote Windows desktop without buying hardware, ShoHost's Private Admin RDP plans let you install any Windows OS with admin access. Plans start at 2 vCore, 2 GB RAM and 50 GB SSD and go up to 8 vCore with 16 GB RAM, all on a 200 Mbps port with unlimited bandwidth. Only the RDP port is open, which suits a remote desktop but not a public web server. The entry plan comes to ₹410.97 a month, all fees included. Questions before you order? Write to support@shohost.com or WhatsApp +91 94880 91432, 9 AM to 12 midnight IST.

Your WHMCS Cron Stopped. Nobody Noticed for a Week.

ShoHost — Sun, 25 Oct 2026 05:09:06 +0000

A dead WHMCS cron doesn't throw an error page. Invoices simply stop going out, overdue services stay active, and the first alarm is usually a client asking why they never got a bill.

When it happens, the first job is to work out which kind of failure you have, because the fixes are different:

Never called vs. called and crashing. The Cron Status report behind the Automation Status badge tells you. If Cron Setup and Invocation Frequency fail, cron never reaches WHMCS. If only Daily Cron Completing fails, it starts and dies partway.
Run it by hand, loudly. Running cron.php all -F -vvv from SSH as the account that owns WHMCS prints the real [ERROR] line instead of a coloured badge. Do it once, not on a schedule.
The usual suspect is PHP. The bare php in a crontab is whatever comes first in cron's PATH, which often isn't the version your site uses, and it may not have the ionCube Loader.
Check the clock too. If CLI PHP and web PHP disagree on timezone, the daily run can keep missing your Time of Day hour.

"Works in SSH, fails in cron" almost always comes down to that different environment.

The guide covers ten causes in the order we'd check them on a real server, with the commands, sample output, a post-fix checklist and prevention tips. Read the full WHMCS cron troubleshooting walkthrough on the ShoHost blog.

Self-Hosting n8n with Docker Compose: Five Settings to Get Right on Day One

ShoHost — Wed, 21 Oct 2026 05:12:54 +0000

Getting n8n running in Docker takes five minutes. Keeping it running for a year without losing credentials, webhooks or disk space takes a few extra settings that the quick-start skips. Here's a Compose setup with the five I'd set on day one.

The Compose file

services:
  postgres:
    image: postgres:16
    restart: unless-stopped
    environment:
      POSTGRES_USER: n8n
      POSTGRES_PASSWORD: ${PG_PASSWORD}
      POSTGRES_DB: n8n
    volumes:
      - pg_data:/var/lib/postgresql/data

  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: unless-stopped
    ports:
      - "127.0.0.1:5678:5678"
    environment:
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: postgres
      DB_POSTGRESDB_DATABASE: n8n
      DB_POSTGRESDB_USER: n8n
      DB_POSTGRESDB_PASSWORD: ${PG_PASSWORD}
      N8N_ENCRYPTION_KEY: ${N8N_ENCRYPTION_KEY}
      N8N_HOST: n8n.example.com
      N8N_PROTOCOL: https
      WEBHOOK_URL: https://n8n.example.com/
      GENERIC_TIMEZONE: Asia/Kolkata
      EXECUTIONS_DATA_PRUNE: "true"
      EXECUTIONS_DATA_MAX_AGE: 168
    volumes:
      - n8n_data:/home/node/.n8n
    depends_on:
      - postgres

volumes:
  pg_data:
  n8n_data:

Put PG_PASSWORD and N8N_ENCRYPTION_KEY in a .env file next to it (openssl rand -hex 32 makes a good key), then docker compose up -d.

1. Pin your own encryption key

n8n encrypts every saved credential with N8N_ENCRYPTION_KEY. If you don't set one, it generates a key inside the data volume. Rebuild the container without that volume and every credential becomes unreadable. Set it yourself and back it up somewhere other than the server.

2. Use Postgres, not the default SQLite

SQLite is fine for a test. Once you have busy webhooks and thousands of executions, Postgres handles concurrent writes better and is far easier to back up with pg_dump.

3. Tell n8n its public URL

Behind a reverse proxy, n8n doesn't know its own address, so webhook nodes show localhost:5678 URLs that nothing outside can reach. WEBHOOK_URL fixes that. Bind the port to 127.0.0.1 as above and let Caddy or Nginx handle HTTPS in front.

4. Prune old executions

Every run is stored with its input and output data. Without pruning, the database grows until the disk fills. EXECUTIONS_DATA_MAX_AGE: 168 keeps one week of history; raise it if you need longer audits.

5. Set the timezone

Schedule Trigger nodes use GENERIC_TIMEZONE. Leave it unset and your "9 AM" workflow runs at 9 AM UTC, which is 2:30 PM in India.

Backups and updates

A nightly pg_dump of the n8n database plus a copy of your .env is enough to rebuild the whole instance. To update, run docker compose pull && docker compose up -d, but read the n8n release notes first, because major versions sometimes change node behaviour.

If you'd rather skip the server work

All of the above is yours to maintain: OS patches, Docker updates, backups and HTTPS renewals. If you want a private n8n instance without looking after the box, ShoHost's managed n8n hosting runs each instance in isolated Docker on its own KVM plan, with no per-step execution limits. Support is on WhatsApp (+91 94880 91432) and email (support@shohost.com), 9 AM to 12 midnight IST.

Five People, Five Full Admins: Fixing WHMCS Staff Access

ShoHost — Wed, 21 Oct 2026 05:12:31 +0000

Most WHMCS installs start with one staff account: the owner's, with every permission switched on. Then a support hire gets the same login "just for now", a freelancer keeps the account they used to fix a module, and a billing assistant leaves without anyone switching them off. A year later five people can do anything, and the Admin Log can't tell you who did what.

The good news is that WHMCS already has the tools to fix this:

Administrator roles. WHMCS ships with Full, Sales and Support Only, and you can add custom roles such as Billing or Module debug. Keep Full to one or two people.
Read the permission types. List and View are low risk. Delete and Configure are the dangerous ones, and some Create permissions quietly need Manage too.
Invite, don't hand out passwords. Send Invite Link lets new staff pick their own credentials, so no password travels through chat.
Offboard properly. Disable old accounts and move API credentials off personal admins before someone leaves.

Roles still can't stop someone who has a valid password, which is where a second login factor comes in.

The full guide has a sample role plan for a small hosting team, the permissions worth singling out and an offboarding checklist. Read our guide to WHMCS admin roles, least privilege and offboarding on the ShoHost blog.

Encrypted Nightly Server Backups to an S3 Storage Box with rclone

ShoHost — Tue, 20 Oct 2026 05:08:31 +0000

Most server backup plans fail in one of two ways: the backups live on the same machine they're meant to protect, or nobody has ever tried a restore. This walkthrough fixes both with rclone, an S3-compatible storage box and one cron job. Everything here works with any S3 endpoint; I'll use ShoHost SDrive, an S3-compatible storage box as the example target because it also speaks SFTP, WebDAV and SMB and keeps its own snapshots.

1. Install rclone

curl https://rclone.org/install.sh | sudo bash
rclone version

2. Add the storage box as a remote

Grab the S3 endpoint, access key and secret key from your storage provider's dashboard, then:

rclone config create sdrive s3 provider=Other \
  access_key_id=YOUR_ACCESS_KEY \
  secret_access_key=YOUR_SECRET_KEY \
  endpoint=https://YOUR_S3_ENDPOINT

rclone mkdir sdrive:server-backups
rclone lsd sdrive:

If you'd rather not use S3, the same box over SFTP works too: rclone config create sdrive sftp host=YOUR_HOST user=YOUR_USER key_file=~/.ssh/id_ed25519.

3. Encrypt before anything leaves the server

An rclone crypt remote wraps the bucket so file contents and names are encrypted on your side:

rclone config create sdrive-crypt crypt \
  remote=sdrive:server-backups \
  password='LONG_RANDOM_PASSPHRASE' --obscure

Store that passphrase somewhere other than the server. Lose it and the backups are unreadable, which is the point.

4. The backup script

#!/usr/bin/env bash
# /usr/local/bin/offsite-backup.sh
set -euo pipefail
STAMP=$(date +%F)
mkdir -p /var/backups/db

# Consistent MySQL/MariaDB dump without locking InnoDB tables
mysqldump --single-transaction --all-databases | gzip > /var/backups/db/all-$STAMP.sql.gz

# Databases: copy new dumps, keep 30 days remote
rclone copy /var/backups/db sdrive-crypt:db --log-file /var/log/rclone-backup.log
rclone delete sdrive-crypt:db --min-age 30d

# Site files: mirror, but move changed/deleted files into a dated folder instead of losing them
rclone sync /var/www sdrive-crypt:www \
  --backup-dir sdrive-crypt:www-archive/$STAMP \
  --transfers 4 --log-file /var/log/rclone-backup.log

# Local dumps older than 7 days
find /var/backups/db -name '*.sql.gz' -mtime +7 -delete

--backup-dir is the part people skip. Plain sync deletes remote files that were deleted locally, so a bad deploy or ransomware on the server would be mirrored straight into your backup. With --backup-dir, anything overwritten or removed is kept under a dated folder.

5. Schedule it

sudo chmod 700 /usr/local/bin/offsite-backup.sh
sudo crontab -e
# 02:30 every night
30 2 * * * /usr/local/bin/offsite-backup.sh

6. Prove the restore works

A backup you haven't restored is a guess. Once a month:

mkdir -p /tmp/restore-test
rclone copy sdrive-crypt:db /tmp/restore-test --max-age 2d
gunzip -t /tmp/restore-test/*.sql.gz && echo "dump OK"
rclone check /var/www sdrive-crypt:www --one-way

rclone check compares sizes and hashes between the server and the remote, so you find a silent failure now rather than on the day you need the files.

Where the storage box helps

rclone handles encryption and retention, but a second safety net on the storage side is worth having. Snapshots on the box let you roll back even if a compromised server pushes bad data during a sync. That's the main reason I like pointing this setup at a storage box rather than a plain bucket. SDrive includes snapshots and versioning on its plans, and there's a small free tier if you want to test the script before committing.

That's the whole setup: one remote, one encrypted wrapper, one script, one cron line and a monthly restore test.

Passkey, Authenticator App or Email Code: Picking 2FA for WHMCS Staff

ShoHost — Tue, 20 Oct 2026 05:07:40 +0000

Every WHMCS staff login should ask for something after the password. The harder question is what that something should be, because the three common options don't protect you equally.

Email codes are the easiest to roll out and the weakest for admins. Whoever gets into the staff mailbox can usually reset the WHMCS password and read the login code too, and NIST SP 800-63B says email shall not be used for out-of-band authentication.

Authenticator apps (TOTP) are what WHMCS ships with as Time-Based Tokens, and they're a big step up from a password alone. Their weak spot is phishing: a look-alike login page can collect the 6-digit code and replay it to your real login before it expires.

Passkeys close that gap. The browser only offers a passkey on the domain it was created for, so a fake page gets nothing to relay. WHMCS doesn't include passkey sign-in in its built-in two-factor list, which is why this needs an add-on.

The full guide covers how each method behaves at a WHMCS login, where email codes still make sense (clients and backup), what to do about lost phones and clock drift, and a simple policy you can copy for your team. Read our full passkeys vs TOTP vs email codes comparison for WHMCS staff on the ShoHost blog.

Why Your WHMCS Admin Login Needs More Than a Password

ShoHost — Mon, 19 Oct 2026 08:40:33 +0000

If you run a hosting business on WHMCS, your admin area is the most valuable login you own. It controls client data, invoices, payment gateways and every service you sell. That is exactly why bots hammer WHMCS admin login pages with brute-force and credential-stuffing attempts every day.

A single reused or leaked admin password can lead to:

Fraudulent orders and refunds
Leaked client details
Changed payment settings and chargebacks
Lost trust that is hard to win back

Basic steps like a strong password and limiting failed logins help, but a password on its own is still a single point of failure.

We wrote a full breakdown of the main risks and the practical steps to lock down your WHMCS admin area on our blog: How to harden your WHMCS admin area.

If you want stronger login protection without the hassle, ShoSecure Auth for WHMCS is our in-house module that adds an extra security layer to WHMCS logins, so a stolen password is not enough to get in. It costs $12.10 a year, all fees included, and comes with a 15-day free trial and a 7-day money-back guarantee.

WhatsApp Notifications for WHMCS

ShoHost — Thu, 15 Oct 2026 18:39:59 +0000

Want your WHMCS clients to get WhatsApp messages the moment an invoice is created, a payment lands or a ticket gets a reply? Email alone gets missed. WhatsApp gets read.

Building this yourself means Meta Business approval, message templates, PHP hooks, error handling and ongoing maintenance every time WHMCS or the WhatsApp API changes.

The ShoHost WHMCS WhatsApp Module does it out of the box:

Automatic WhatsApp alerts for invoices, payments, orders and support tickets
OTP and verification messages
Bulk campaigns to your client list
Delivery tracking
Works with the latest WHMCS versions

It costs $2/month, with a 15-day free trial and a 7-day refund.

See all features, requirements and setup details on the ShoHost WHMCS WhatsApp Module page.