WordPress on Aquasp's blog

7 things that you should do after installing WordPress

Tue, 09 Dec 2025 01:45:24 +0000

Introduction

Starting a fresh WordPress site in 2026? Whether it’s a blog, eCommerce store, or portfolio, these tweaks will supercharge speed, lock down security, and ensure buttery-smooth performance from day one.

No paid tools required — just free plugins and quick configs. Let’s dive in!

1. Auto-Resize & Compress Images on Upload

Images are the #1 bandwidth killer. Don’t upload a 10MB photo and hope for the best — automate compression to keep your site lean.

Recommended Plugin: Resize Image After Upload (Free, 90K+ active installs, 4.8/5 rating)

Install & activate it first thing.
Set max width/height (e.g., 1920px wide) and compression level (default 82% JPEG quality is solid).
It auto-resizes JPEG/PNG/GIF on upload, slashes file sizes by 50–80%, and boosts SEO with faster load times.

Pro tip: For bulk-optimizing existing images, pair it with Smush (free tier handles 50 images/month).

Result: Pages load 2–3x faster, less server strain, happier Google rankings.

2. Strip Out Unnecessary Bloat

WordPress ships with “extras” you might not need — like Gutenberg blocks, XML-RPC, or emoji scripts. Trim the fat for a lighter core.

Recommended Plugin: Unbloater (Free, 10K+ active installs, 5/5 rating)

Simple dashboard under Settings > Unbloater.
Recommended toggles:
- Backend: Disable auto-updates (if you handle them manually), limit post revisions to 3, hide update nags for non-admins, disable XML-RPC.
- Frontend: Remove RSD/WLW manifests, shortlinks, feed links, jQuery Migrate, emoji scripts.
- Block Editor: Fully disable Gutenberg (if using Classic Editor) or remove unused blocks.
- Extras: Block DNS prefetch to WordPress.org, remove generator meta tag.

Everything is reversible — toggle off if issues arise. This cuts database queries and JS/CSS bloat by 20–30%.

3. Tame the Heartbeat API

WordPress’ Heartbeat API pings your server every 15–60 seconds for autosave, user presence, etc. Great for collaboration, but it spikes CPU on shared hosting.

Recommended Plugin: Heartbeat Control (Free, 90K+ active installs, 4.1/5 rating)

Go to Settings > Heartbeat Control.
Set intervals: 60 seconds (frontend), 120 seconds (dashboard/editor).
Or disable entirely on frontend if you don’t need live previews.

Unbloater can handle this too. Expect 10–20% CPU savings on idle sessions.

4. Limit Post Revisions

By default, WordPress saves 25 revisions per post — bloating your database over time (e.g., a 1,000-post site = 25K+ entries).

Add to wp-config.php (before “That’s all, stop editing!”):

// Limit to 3 revisions (or false to disable)
define('WP_POST_REVISIONS', 3);

Unbloater has a toggle for this. Clean up old ones with WP-Optimize (free).

Result: Smaller DB = faster queries and backups.

5. Disable XML-RPC (Unless Needed)

XML-RPC enables remote posting/apps but is a brute-force magnet (most bots target it).

If using Jetpack/mobile apps: Keep it, but whitelist your IP.
Otherwise: Block via .htaccess (Apache/LiteSpeed):

<Files xmlrpc.php>
Order Deny,Allow
Deny from all
# Allow from YOUR.IP.ADDRESS (uncomment if needed)
</Files>

Unbloater or Loginizer (free, 1M+ installs) can disable it too.

6. Lock Down Logins with Rate Limiting

Bots hammer /wp-login.php 24/7. Limit attempts to stop brute-force attacks cold.

Top Pick: Limit Login Attempts Reloaded (Free, 2M+ installs, 4.9/5 rating)

Defaults: 3 failed attempts → 15-min lockout (escalates to 24h).
Covers wp-admin, XML-RPC, WooCommerce, custom logins.
Logs + notifications included.

Alternative: BruteGuard (Free, cloud-based botnet blocking via shared network).

Loginizer (1M+ installs) adds 2FA + reCAPTCHA for extra layers.

Test: Try wrong logins — you’ll see instant blocks.

7. Vet Plugins Before Installing

Not all plugins are equal — some bloat your site with 1MB+ RAM usage or JS errors. Always check:

WP Hive: Chrome extension + site for automated tests (memory, page speed impact, PHP/WordPress compatibility, DB footprint). E.g., Yoast SEO 20.1: +0.1s load time, 1MB RAM (heavier than average).
PluginTests.com: Basic compatibility/smoke tests for 98% of WP.org plugins (activation errors, obvious breaks).

Quick Example (2025 Benchmarks):

Yoast SEO: Solid but resource-heavy (+0.1s load, 1MB RAM). Great for readability.
Rank Math SEO: Lighter (no load impact, <250KB RAM), more free features. Often 4x faster in tests.

Aim for lightweight picks — only add “heavy” ones if essential.

Wrap-Up

Implement these today, and your site will launch 2–3x faster, more secure, and future-proof. Total time: ~30 minutes. No excuses!

Thanks for reading! 🚀

How to remove upload limits on All In One WP Migration

Tue, 09 Dec 2025 00:25:04 +0000

Introduction

Unfortunately, many hosting providers impose very low upload limits (sometimes as little as 2–50 MB), and the official Unlimited Extension costs $69.

If you’re in that situation and need a free way to upload huge backups (10 GB, 40 GB, or more), this simple trick will help.

The Solution: Use “Big File Uploads” Plugin

The free version of All-in-One WP Migration doesn’t artificially limit uploads — it simply respects whatever limit your hosting or server enforces. The paid Unlimited Extension works by splitting the .wpress file into smaller chunks during upload.

Good news: there’s a completely free plugin that does the exact same chunking trick!

Step-by-Step Guide

Install and activate the plugin called Big File Uploads → Direct link: https://wordpress.org/plugins/tuxedo-big-file-uploads/
After activation, go to: Settings → Big File Uploads (or find it under the Plugins page → “Settings” link under the plugin name)
You’ll see the current maximum upload size (it will match your host’s default limit at first).
Change it to whatever you want:

1 GB = 1024 MB
10 GB = 10240 MB
40 GB = 40960 MB (Just type the number in megabytes — no need to add “MB” or “GB”)

Click Save Changes

That’s it! The new limit takes effect immediately.

Now when you go back to All-in-One WP Migration → Import, the max file size will reflect your new value (even 40 GB or higher works perfectly).

Conclusion

This is not meant as an attack on ServMask — they’ve built an amazing plugin and absolutely deserve support. If you can afford it, please buy the official Unlimited Extension.

But if budget is tight and you just need to migrate or restore a huge site once or twice, the Big File Uploads plugin is a 100% free and reliable alternative that works perfectly with the free version of All-in-One WP Migration.

Thank you for reading! 🙂

How to setup WordPress on LEMP with Redis and WP CLI on Debian 11

Mon, 08 Dec 2025 23:47:36 +0000

Introduction

This is the fastest, most secure, and most resource-efficient way to self-host WordPress in 2025. We’ll use a proper LEMP stack (Linux + Nginx + MySQL/MariaDB + PHP-FPM) with per-site PHP isolation, Redis object caching, automatic SSL, and WP-CLI — everything tuned for speed and security.

Let’s go.

Step 0: Secure & Update Your VPS

(If you haven’t already, follow a VPS hardening guide first — SSH keys only, firewall, fail2ban, etc.)

apt update && apt upgrade -y
apt autoremove --purge
reboot

Step 1: Install the Core Stack

# Nginx
apt install nginx -y
systemctl enable nginx

# MariaDB (better than MySQL on Debian)
apt install mariadb-server -y
systemctl enable mariadb

# PHP 8.3 + all needed extensions (using ondrej/sury repo)
apt install ca-certificates apt-transport-https lsb-release -y
wget -qO- https://packages.sury.org/php/apt.gpg | gpg --dearmor > /usr/share/keyrings/sury-php.gpg
echo "deb [signed-by=/usr/share/keyrings/sury-php.gpg] https://packages.sury.org/php/ $(lsb_release -sc) main" > /etc/apt/sources.list.d/sury-php.list
apt update
apt install php8.3-fpm php8.3-mysql php8.3-curl php8.3-gd php8.3-mbstring php8.3-xml php8.3-zip php8.3-intl php8.3-imagick php8.3-redis -y
systemctl enable php8.3-fpm

# Redis
curl -fsSL https://packages.redis.io/gpg | gpg --dearmor -o /usr/share/keyrings/redis-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/redis-archive-keyring.gpg] https://packages.redis.io/deb $(lsb_release -cs) main" > /etc/apt/sources.list.d/redis.list
apt update && apt install redis-server -y
systemctl enable redis-server

# Certbot + WP-CLI
apt install python3-certbot-nginx -y
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod +x wp-cli.phar && mv wp-cli.phar /usr/local/bin/wp

Step 2: Secure MariaDB & Create Database

mysql_secure_installation

mysql -u root -p
CREATE DATABASE wp_yoursite;
CREATE USER 'wp_yoursite'@'localhost' IDENTIFIED BY 'strongpassword';
GRANT ALL ON wp_yoursite.* TO 'wp_yoursite'@'localhost';
FLUSH PRIVILEGES;
EXIT;

Step 3: Isolate PHP-FPM Per Site (Security + Stability)

cd /etc/php/8.3/fpm/pool.d/
cp www.conf yoursite.conf
nano yoursite.conf

Replace:

[www] → [yoursite]
user = www-data → user = yoursiteuser (we’ll create this user soon)
group = www-data → group = yoursiteuser
listen = /run/php/php8.3-fpm.sock → listen = /run/php/php8.3-fpm-yoursite.sock
Change process manager from dynamic → ondemand (saves RAM)

systemctl restart php8.3-fpm

(It will fail until the user exists — that’s fine.)

Step 4: Optimize PHP & Enable OPcache

sed -i "s/memory_limit = .*/memory_limit = 1024M/" /etc/php/8.3/fpm/php.ini
sed -i "s/upload_max_filesize = .*/upload_max_filesize = 10240M/" /etc/php/8.3/fpm/php.ini
sed -i "s/post_max_size = .*/post_max_size = 10240M/" /etc/php/8.3/fpm/php.ini
sed -i "s/max_execution_time = .*/max_execution_time = 600/" /etc/php/8.3/fpm/php.ini
sed -i "s/;opcache.enable=1/opcache.enable=1/" /etc/php/8.3/fpm/php.ini
sed -i "s/;opcache.memory_consumption=.*/opcache.memory_consumption=512/" /etc/php/8.3/fpm/php.ini
sed -i "s/;opcache.max_accelerated_files=.*/opcache.max_accelerated_files=20000/" /etc/php/8.3/fpm/php.ini
sed -i "s/;cgi.fix_pathinfo=1/cgi.fix_pathinfo=0/" /etc/php/8.3/fpm/php.ini

Step 5: Create System User & Site Directory

adduser yoursiteuser --shell /bin/bash
su yoursiteuser
mkdir ~/public_html && cd ~/public_html
echo "cd ~/public_html" >> ~/.bashrc
exit

Step 6: Nginx Config (Fast & Secure)

nano /etc/nginx/sites-available/yoursite.conf

upstream php-yoursite {
 server unix:/run/php/php8.3-fpm-yoursite.sock;
}

server {
 listen 80;
 listen [::]:80;
 server_name yourdomain.com www.yourdomain.com;
 root /home/yoursiteuser/public_html;
 index index.php index.html;

 client_max_body_size 10G;

 location / {
 try_files $uri $uri/ /index.php?$args;
 }

 location ~ \.php$ {
 include fastcgi_params;
 fastcgi_pass php-yoursite;
 fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
 }

 location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff2?|ttf|eot)$ {
 expires max;
 log_not_found off;
 }
}

ln -s /etc/nginx/sites-available/yoursite.conf /etc/nginx/sites-enabled/
nginx -t && systemctl reload nginx

Step 7: Install WordPress via WP-CLI (as the site user)

su yoursiteuser
cd ~/public_html

wp core download
wp config create --dbname=wp_yoursite --dbuser=wp_yoursite --dbpass='strongpassword' --locale=en_US
wp core install --url=https://yourdomain.com --title="Your Site" --admin_user=admin --admin_password='strongpass' --admin_email=you@domain.com

Step 8: SSL with Let’s Encrypt (Auto-renew)

certbot --nginx -d yourdomain.com -d www.yourdomain.com
# Choose redirect to HTTPS when asked

Add auto-renew cron:

crontab -e
# Add:
0 0 * * 0 certbot renew --quiet

Step 9: Enable Redis Object Cache

# As root
usermod -aG redis yoursiteuser
chmod 770 /var/run/redis/redis-server.sock

# Optimize Redis config
sed -i 's/port 6379/port 0/' /etc/redis/redis.conf
sed -i 's|# unixsocket /run/redis/redis-server.sock|unixsocket /var/run/redis/redis-server.sock|' /etc/redis/redis.conf
sed -i 's/# unixsocketperm 700/unixsocketperm 770/' /etc/redis/redis.conf
sed -i 's/# maxmemory .*/maxmemory 1024mb/' /etc/redis/redis.conf
systemctl restart redis-server

# As yoursiteuser
cd ~/public_html
wp plugin install redis-cache --activate
wp config set WP_REDIS_SCHEME unix
wp config set WP_REDIS_PATH '/var/run/redis/redis-server.sock'
wp redis enable

Done!

You now have:

Fully isolated PHP-FPM pool (1 user = 1 site = no cross-site damage)
Redis object caching over Unix socket
OPcache + huge upload limits
Automatic SSL renewal
Fastest possible Nginx routing
WP-CLI ready

Your wp-admin will feel instant, and the site will handle traffic like a champ — even on a $5/month VPS.

Next steps:

Install a page cache plugin (any free one is ok)
Set up Cloudflare (optional but recommended)
Regular backups

Enjoy your blazing-fast, private WordPress setup!

Thanks for reading! 😊

Page Cache, Object Cache and CDN cache - Understanding all types of caching

Mon, 08 Dec 2025 23:13:04 +0000

Understanding the Different Types of Caching (Especially for Scaling CMS Sites)

If you’ve ever wondered what people mean when they talk about “page cache,” “object cache,” or “CDN cache,” this post is for you. These are the three main caching layers that make a massive difference when scaling WordPress, WooCommerce, or any other CMS.

What is Page Caching?

Page caching (also called full-page caching or HTML caching) is exactly what it sounds like: the entire rendered HTML page is saved as a static file.

With a truly static site (plain HTML + CSS + JS), there’s no need for page caching because every file is already static. But with a CMS like WordPress, every request normally triggers PHP → theme → plugins → database queries → HTML output. That process eats CPU and takes time.

Full-page caching shortcuts all of that. The first visitor triggers the full PHP+MySQL process, the resulting HTML is saved, and every visitor after that gets served the pre-generated static HTML instantly — no PHP, no database queries, almost zero CPU.

Result: 10–100× lower server load and dramatically faster page loads.

What is Object Caching?

Object caching stores the results of expensive database queries (or any slow computation) in fast memory (usually Redis or Memcached).

Think of it as a super-fast middleman between your PHP code and the database.

Example with WordPress:

WordPress needs the list of published posts → it asks MySQL.
First request: MySQL does the work, returns the data, object cache saves it in RAM.
Next 10 000 requests: object cache instantly returns the same data from memory → MySQL sleeps peacefully.

Object cache is smart — it automatically invalidates itself when data changes (e.g., you publish a new post).

Why you still need it even with full-page caching:

Logged-in users (including the WordPress dashboard, WooCommerce account pages, etc.) can’t be fully cached for everyone.
Those pages still hit PHP and MySQL → object cache makes them tolerable instead of painfully slow.

Object cache + full-page cache together is the classic high-traffic combo.

What is CDN Caching?

A CDN (Content Delivery Network) copies your static assets (CSS, JS, images, fonts) — and optionally your full HTML pages — to “PoP” servers all over the world.

Without a CDN: a visitor in Japan downloads everything from your origin server in, say, Brazil → high latency.

With a CDN:

Static files are served from the closest PoP (often < 30 ms away).
If you also enable full-page caching on the CDN, the entire HTML page is served from that nearby PoP too → the origin server is never touched for cached pages.

This is why some sites load instantly from anywhere on the planet.

Real-World Example: WordPress Traffic Flow

No caching at all

Visitor → Web server → PHP → dozens of plugin files → MySQL queries → HTML → visitor → High CPU, slow TTFB, easily hits resource limits.

With full-page caching only

First visitor: same slow path as above (but the HTML is saved). Next 10 000 visitors: Web server instantly serves the pre-built HTML → almost zero CPU.

With object caching only

Every request still runs PHP + plugins, but database queries are answered from RAM instead of disk → faster than no cache, but still heavy.

With full-page cache + object cache

Anonymous visitors → static HTML (super fast, almost no load)
Logged-in users → PHP runs, but object cache makes DB queries instant → manageable load

Add CDN with full-page caching on top

Even the static HTML is now served from edge locations worldwide. Your origin server can basically take a nap until something actually needs PHP (e.g., form submissions, cache invalidation).

Conclusion

Here’s the hierarchy from most impactful to least (for most CMS sites):

Full-page caching on the CDN → fastest for visitors, scales to millions of hits with almost zero origin load.
Full-page caching on the origin → still massive win if you can’t cache on the CDN.
Object caching (Redis/Memcached) → mandatory for logged-in users, WooCommerce, dashboards, etc.
Everything else (OPcache, browser cache, etc.) → nice to have, usually enabled by default.

If you only do one thing: enable proper full-page caching (and push it to your CDN if possible). If you have logged-in traffic or a shop: add Redis/Memcached object caching.

That’s it — the three caching layers that power basically every high-traffic WordPress site on the planet.

Hope this cleared things up!

Thanks for reading! 😊