AgilePress

Category: Security

Security is infrastructure, not plugins. We reject heavy bloatware and rely on server-level WAFs and the 3-2-1 Backup Protocol. Protect your business assets without killing performance.

  • The Multisite Trap: Why Centralizing Your WordPress Sites is Usually a Corporate Disaster

    In the WordPress ecosystem, there is a concept that sounds like an absolute dream to CTOs and agency owners: WordPress Multisite.

    The pitch is seductive: “Why manage 20 different WordPress installations when you can have one single dashboard, update plugins once, and rule them all from a central command center?”

    The reality is usually an architectural nightmare. Activating Multisite creates a massive Single Point of Failure (SPOF). Because all sub-sites share the same database and the same plugin files, if a malicious script takes down Site A, Sites B, C, and D die instantly. If the database gets corrupted, you lose the entire network. Furthermore, extracting a single site later to move it to its own server requires expensive premium tools and hours of database surgery.

    At AgilePress, we believe convenience should never compromise infrastructure isolation. Here is our strict protocol on when to flee from Multisite, and the specific scenarios where it is actually the smartest choice you can make.

    Phase 1: The Blacklist (When to NEVER use Multisite)

    If you are using Multisite for any of the following reasons, you are accumulating massive technical debt and legal liability:

    • Hosting Different Clients: This is professional negligence. If Client A demands database access or a server migration, you cannot give it to them without exposing Client B’s data. It is a GDPR violation waiting to happen.
    • Mixing Different Business Models: If Site A is a high-traffic WooCommerce store and Site B is a simple corporate blog, putting them on a Multisite forces the blog to share a database with heavy transactional tables it doesn’t even use.

    The AgilePress Solution for Agencies: Standalone + MainWP. Every client gets their own isolated WordPress installation (Standalone). If one gets DDOS’d, the others stay up. To get the “one dashboard” convenience, you install MainWP on a hidden, separate server. MainWP connects to all your standalone sites via API, allowing you to update plugins and run backups globally without entangling their databases.

    Phase 2: The Greenlight (When Multisite is Brilliant)

    Multisite is not inherently evil; it is just wildly misunderstood. It was designed for a very specific purpose: Deploying the exact same codebase, for the exact same entity, with separated data.

    Here are the four AgilePress-approved use cases where Multisite is the superior architectural choice:

    1. The AgilePress Showroom (Rapid Provisioning)

    We use Multisite internally at AgilePress as a sandbox. When a client needs a prototype, we don’t spin up a new server. We click a button on our internal Multisite (demo.agilepress.net), and within three seconds, a fresh sub-site is born with our Block Theme (Frost) and premium plugins already activated.

    • Why it works: It is not in production. If an update breaks the network, no real business loses money. Once the client approves the demo, we clone it, migrate it to an isolated Standalone server, and delete the Multisite instance to keep our showroom clean.

    2. The Corporate Intranet (Departmental Isolation)

    A large company needs an internal portal, but HR, IT, and Sales all need their own spaces to publish news and documents without stepping on each other’s toes.

    • Why it works: You create an Intranet Multisite. Every department gets a sub-site (hr.company.com, it.company.com). They all share the exact same corporate branding (Theme) and the exact same security plugins, but their content and user roles are perfectly separated.

    3. The Branch Office Network (Standardized Engines)

    Imagine a company with 15 physiotherapy clinics across the country. They all need a booking system.

    • The Agile Architecture: You build a Multisite using a heavy engine like Bookly or FluentBooking. Each clinic gets its own sub-site (toulouse.clinic.com, lyon.clinic.com).
    • Why it works: They share the same look and feel, and the IT team only maintains one codebase. However, because they are on separate sub-sites, Madrid’s receptionists cannot accidentally delete Barcelona’s appointments. You achieve global standardization with local data isolation.

    4. Enterprise Multilingual Architecture

    Standard translation plugins (like WPML) destroy your database by duplicating posts and hacking the wp_options table.

    • Why it works: For high-performance enterprise sites, you use Multisite combined with MultilingualPress. You create one sub-site per language (en.company.com, es.company.com). The databases remain clean, queries are lightning-fast, and translators can easily link the English version of a post to the Spanish one without causing server bloat.

    Conclusion: The AgilePress Decision Tree

    Look at your project scope and choose your infrastructure:

    • Are they different clients paying different bills? -> Standalone + MainWP.
    • Are you mixing an E-commerce site with a portfolio? -> Standalone + MainWP.
    • Are you building a standardized Intranet for one company? -> Multisite.
    • Are you giving 10 local franchises the exact same booking tool? -> Multisite.
    • Do you need to spin up disposable client demos in 3 seconds? -> Multisite.

    Stop using Multisite to save $10 a month on hosting, and start using it for what it was built for: unified infrastructure at scale.

  • The “Install & Delete” Rule: The AgilePress Guide to Disposable Plugins

    WordPress users suffer from digital hoarding.

    You look at a typical dashboard today, and you will see 45 active plugins. Among them is a tool used to migrate the site three years ago, a thumbnail regenerator used during a theme redesign in 2024, and a database cleaner that runs a heavy cron job every day for no reason.

    At AgilePress, we treat plugins like scaffolding on a building. You put the scaffolding up to fix the roof or paint the walls. When the job is done, you take the scaffolding down. You do not leave it attached to the building forever.

    Leaving utility plugins installed introduces three massive risks:

    1. Security: An inactive or forgotten plugin is the #1 vector for malware injections.
    2. Database Bloat: Many plugins inject their menus and settings into the wp_options table even when deactivated.
    3. Overhead: Background tasks (cron jobs) from forgotten utility plugins consume server CPU.

    Here is the definitive AgilePress list of Disposable Plugins: tools you should install, use for their specific mission, and immediately delete.

    Mission 1: Database Surgery & URL Routing

    These are heavy-duty tools that rewrite your core data. They are incredibly powerful, but leaving them installed is a major security vulnerability.

    • Better Search Replace: The industry standard for migrating from HTTP to HTTPS or changing a domain name. Run your search, replace the strings, and delete it immediately.
    • AAA Option Optimizer: As discussed in our database guide, this is the best visual tool to find heavy, autoloaded rows in your wp_options table. Identify the culprits, toggle them off, and delete the plugin.
    • Advanced Database Cleaner: Use the PRO version to scan for orphaned tables and cron jobs left by old plugins. Purge the garbage, then remove the cleaner.
    • WP Bulk Delete: If you inherit a site with 50,000 spam comments or thousands of useless Custom Post Types, doing it via the standard WordPress UI will crash your browser. Use this to drop them in bulk, then delete.
    • WP-DBManager: An old-school but highly effective tool if you need to optimize, repair, or drop specific SQL tables directly from the dashboard. Once the surgery is successful, scrub up and delete it.

    Mission 2: Diagnostics & Performance (The Inspectors)

    These tools are built to tell you what is wrong with your site. Because they log every single process, they inherently slow down your site while active.

    • Query Monitor: The holy grail for developers. It tells you exactly which plugin or SQL query is slowing down your page. Warning: It will slow down your admin area drastically while active. Turn it on, take your notes, and delete it.
    • Code Profiler: Measures performance at the PHP level. If your site is slow but Query Monitor doesn’t show slow database queries, Code Profiler will tell you which specific PHP script is eating your CPU. Run the report, then delete it.
    • WP Crontrol: Essential for finding stuck scheduled tasks (cron jobs). If a backup plugin failed to run, the cron might be stuck in a loop. Delete the orphaned cron events, then delete WP Crontrol.
    • WS Action Scheduler Cleaner: WooCommerce relies on the “Action Scheduler” to process webhooks and subscriptions. Sometimes, this table bloats to millions of rows of “failed” or “complete” actions. Install this, flush the logs, and remove it.
    • Fatal Error Notify: We prefer server-level debug.log files, but if you are doing a major WooCommerce upgrade and want instant email alerts if a fatal PHP error occurs during the transition, install this. Once the site is stable for 48 hours, remove it.

    Mission 3: Media & Content Logistics

    Content migration plugins usually feature heavy UIs and background processors. They have no place on a live, functioning production environment.

    • Regenerate Thumbnails: You changed your theme, and now all your grid images look skewed. Install this, let it resize your entire media library to the new CSS dimensions, and delete it. It serves zero purpose once the images are cut.
    • Export Media Library: Sometimes you just need to extract a clean .zip of all your images without touching the database. Export them, then delete the plugin.
    • WP All Import / WP All Export (or any CSV importer): You used this to import 500 WooCommerce products from a supplier. The import is done. Do not leave this massive plugin sitting in your dashboard.
    • Convert to Blocks: If you are migrating a 10-year-old blog from the Classic Editor to the Block Editor (Gutenberg), this plugin will bulk-convert your old HTML posts into native blocks. Once the conversion is complete, the plugin is useless. Delete it.

    Mission 4: Development & FSE Transitions

    These tools are used to bridge the gap between staging and production, or to configure modern Block Themes.

    • Create Block Theme: The official WordPress tool for configuring Full Site Editing (FSE) themes. As outlined in our FSE guide, use this to clone your theme, embed your local fonts, and save the .zip. Once your theme is generated and active, delete the plugin.
    • Theme Switcha: Allows administrators to preview and build a new theme behind the scenes while front-end visitors still see the old theme. Once you hit “Publish” on the new design, this plugin’s lifecycle is over.
    • WP Reset: Used strictly in development/staging environments. If you are testing 5 different membership plugins and want to wipe the database clean between tests, this is your tool. Never install this on a production site.

    Mission 5: Security Scanners

    At AgilePress, we believe security should happen at the server level (Nginx firewalls, Cloudflare, fail2ban), not via PHP.

    • NinjaScanner: A fantastic, lightweight malware and virus scanner. If you suspect a client’s site has been compromised, install this, run a deep file comparison against the WordPress repository, clean the injected PHP files, and then delete the scanner.
    • Wordfence Security (Scanner Only): Wordfence is a great tool, but leaving its Web Application Firewall (WAF) running via PHP adds overhead to every single visitor request. If you must use it, install it, run a deep scan to find vulnerabilities, fix them, and then delete it. Rely on your hosting provider for daily firewall protection.

    Conclusion: The AgilePress Protocol

    Look at your WordPress dashboard right now. Ask yourself this question for every single active plugin:

    “Does this plugin actively serve my front-end visitors or assist in my daily publishing routine?”

    If the answer is no, it is scaffolding. If it’s a tool you only need once a month, delete it and reinstall it next month. The 30 seconds it takes to reinstall a plugin is a small price to pay for a faster, safer, and cleaner database.

    Next Step: Log into your WordPress admin, go to your Plugins page, and delete at least three plugins you haven’t used in the last 30 days. Your server will thank you.

  • Stop Using SSL Plugins: Why “Really Simple SSL” is Making Your Site Slow

    In 2026, HTTPS is not a “feature”; it is the baseline. Yet, millions of WordPress sites still rely on plugins like Really Simple SSL (now rebranded as Simple and Performant Security) to handle their encryption.

    This is a mistake. While these plugins are marketed as “one-click solutions,” they are actually performance taxes disguised as convenience. They solve a database problem by using PHP to rewrite your site’s code on every single page load.

    At AgilePress, we believe in fixing the root cause, not patching the symptoms. Here is why you should delete your SSL plugin today and how to configure HTTPS the right way.

    1. The Myth of the “One Click SSL”

    Why do people install these plugins? Because they see the dreaded “Broken Padlock” (Mixed Content Warning) in their browser. Instead of fixing the broken links, they install a plugin that promises to “fix it automatically.”

    But there is a catch. The plugin doesn’t actually fix your content in the database. It acts as a middleman.

    2. The Villain: Output Buffering

    The core problem with SSL plugins is how they achieve their “magic.” They use a technique called Output Buffering.

    • How it works: When a user visits your site, WordPress generates the page. Before sending it to the user’s browser, the plugin interrupts the process. It scans the entire HTML code held in memory, searches for every http:// instance, and replaces it with https:// dynamically.
    • The Cost: This happens on every single page view (unless aggressively cached). You are forcing your server to perform a “Search & Replace” text operation millions of times a day, increasing your Time to First Byte (TTFB).

    Furthermore, these plugins often handle redirects via PHP (wp_redirect). This means a visitor requesting http://example.com has to wait for WordPress to boot up just to be told to go to https://. A server-level redirect (Nginx/Apache) would handle this in milliseconds, before WordPress even wakes up.

    Finally, the “Feature Creep.” Really Simple SSL is no longer just an SSL plugin; it has morphed into a full security suite with firewalls and login protection. If you already have a security plugin, you are now running redundant code.

    3. The AgilePress Solution (The “Hard” Way is the Fast Way)

    We don’t use plugins for SSL. We configure the server. Here is the protocol to migrate away from SSL plugins without breaking your site.

    Step 1: The Certificate (Hosting Level)

    Ensure your hosting provider (SiteGround, Cloudways, Kinsta) has issued a Let’s Encrypt certificate. This is standard in 2026. Do not try to generate certificates via PHP plugins; let the server handle the renewal via certbot or cPanel.

    Step 2: The Database Cleanup (The Real Fix)

    Instead of filtering http:// on the fly, we will permanently change the links in the database.

    1. Backup your database.
    2. Install Better Search Replace (or use WP-CLI if you are a pro).
    3. Search for: http://yourdomain.com
    4. Replace with: https://yourdomain.com
    5. Run: This fixes 99% of mixed content errors permanently. The plugin is no longer needed to “filter” output because the output is already correct.

    Step 3: Server-Level Redirects (301)

    We want to force HTTPS before WordPress loads.

    If you use Apache/OpenLiteSpeed (.htaccess): Add this to the very top of your .htaccess file:

    <IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>

    If you use Nginx: Add this to your server block configuration:

    server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

    Step 4: HSTS (The “Pro” Header)

    Many plugins charge for “Premium” to enable HSTS (HTTP Strict Transport Security). This is literally one line of code that tells browsers: “Never try to load this site over HTTP again, not even to check.”

    Apache (.htaccess):

    <IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
</IfModule>

    Nginx:

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

    Conclusion: Less is More

    By following this protocol, you have achieved three things:

    1. Removed a plugin (and its future update risks).
    2. Eliminated Output Buffering, lowering your CPU usage.
    3. Secured the site at the server level, which is faster and more robust.

    If your hosting provider does not offer a simple “Force HTTPS” button in 2026, the solution is not to install a plugin—it is to change your hosting provider.

  • The Parachute Protocol: Why Your Hosting Backup Is Not Enough

    In March 2021, the OVH datacenter in Strasbourg caught fire. In a matter of hours, thousands of websites were physically destroyed. When panic-stricken clients contacted support asking for their backups, many received a chilling response: “Your website was on Server 1. Your backup was on Server 2. Both servers were in the same room. They are both ash.”

    This tragedy taught us a brutal lesson: If your backup lives in the same building as your website, you do not have a backup.

    At AgilePress, we follow a strict protocol to ensure that if the entire internet breaks, our clients’ businesses survive.

    The Golden Rule: 3-2-1

    In cybersecurity, there is a universal standard. We apply it to every WordPress site we manage:

    • 3 copies of your data (Production, Backup A, Backup B).
    • Stored on 2 different types of media (Server disk and Cloud storage).
    • 1 copy must be Off-Site (physically in a different location).

    Most website owners fail at the “Off-Site” part.

    Level 1: Hosting Backups (Convenience, Not Safety)

    SiteGround, Cloudways, Kinsta, and most premium hosts offer “Daily Backups.”

    • The Good: They are incredibly fast to restore. If you accidentally delete a page, you can bring it back in 1 click.
    • The Bad: They violate the 3-2-1 rule. If your hosting account is suspended (billing error), hacked, or the datacenter burns down, you lose the website and the backups simultaneously.
    • Verdict: Essential for daily mistakes, but insufficient for disaster recovery.

    The Tool Selection: UpdraftPlus vs. Duplicator

    This is a common debate. Both are giants in the WordPress ecosystem. Duplicator is arguably the most powerful migration tool on the market, and its Pro version offers excellent encrypted backups. However, for the AgilePress Standard Stack (where we seek maximum efficiency with zero recurring costs), we choose UpdraftPlus.

    Here is why:

    The “Free Tier” Difference

    • Duplicator (Lite): Fantastic for manually cloning a site or moving it to a new domain. However, features like Automated Schedules and direct Cloud Storage (Google Drive/Dropbox) are typically locked behind the Pro paywall.
    • UpdraftPlus (Free): It allows us to schedule automatic backups AND send them to remote cloud storage (Google Drive, S3, Dropbox) for free.

    The “Atomic” Restore

    • Duplicator typically restores the “Whole Package” (Site + DB). It’s a “Nuke and Pave” approach, great for total disaster recovery.
    • UpdraftPlus splits the backup into separate entities: Database, Plugins, Themes, and Uploads. If a plugin update breaks your site, you can restore just the plugins in 2 minutes without rolling back the database (and losing orders/comments).

    Verdict: If you already pay for Duplicator Pro, keep it; it’s excellent. But for a universal, cost-effective safety net, UpdraftPlus Free is the winner.

    Level 2: The “Local Storage” Bloat

    Some users install a backup plugin and leave the default settings. The plugin creates a .zip file every day and saves it inside your /wp-content/uploads folder.

    This is a critical error.

    1. Bloat: If your site is 1GB, after 10 days of backups, your server usage is 11GB. You will run out of disk space and crash the server.
    2. Security: Hackers scan specifically for these zip files. If they find them, they can download your entire customer database without logging in.
    3. Redundancy: If the server crashes, you cannot access the WordPress dashboard to download the backup file. It is locked inside the burning house.

    Level 3: The AgilePress Solution (Automated Off-Site)

    We need a tool that:

    1. Runs automatically.
    2. Sends the file to a remote cloud.
    3. Deletes the local file from the server after sending it (to save space).

    The Setup (UpdraftPlus Free):

    • Service: Connect it to a generic Google Drive account (or Amazon S3 for pros).
    • Schedule: Weekly (for brochures) or Daily (for active blogs).
    • Retention: Keep the last 4 backups.

    The Alternative (WPVivid): If UpdraftPlus fails or conflicts with your server, WPVivid is our backup choice. It has a modern interface and also supports free cloud transfers, making it a worthy rival.

    Level 4: The Enterprise Solution (Incremental SaaS)

    If you have a massive WooCommerce store (20GB+), running a standard plugin might crash your server because creating such a huge zip file consumes 100% of the CPU.

    The Tool: BlogVault (or ManageWP)

    • How it works: It is a SaaS. The backup logic happens on their servers, not yours.
    • Incremental: It only copies the files that changed since yesterday. It doesn’t copy the whole 20GB every night.
    • Real-Time: For high-volume stores, it can back up every time an order is placed.

    Schrödinger’s Backup

    A backup file does not exist until you have tested it. We have seen clients with gigabytes of .zip files that were corrupted and empty (0kb) when they tried to unzip them.

    The Protocol: Once a quarter, try to restore your backup to a Local environment (LocalWP). If it opens, you have a backup. If it doesn’t, you have nothing.

    Conclusion: Sleep Well

    The cost of losing your digital business is infinite. The cost of configuring UpdraftPlus to Google Drive is zero.

    Don’t trust your hosting provider blindly. Automate the parachute.

  • The Security Illusion: Why We Banned Wordfence and AIOS

    When a site owner fears getting hacked, their knee-jerk reaction is usually to install the “biggest” security plugin they can find.

    Names like Wordfence, All In One Security (AIOS), or Solid Security dominate the market. They are the “Norton Antivirus” of WordPress.

    At AgilePress, we do not use them.

    In fact, we often remove them to instantly improve a client’s server response time.

    Security is not measured by how many settings your plugin has. It is measured by where you stop the attack. Here is why we shift the weight to the server and use minimalist tools inside WordPress.

    The Problem with “The Giants” (Wordfence, AIOS, Sucuri)

    These popular plugins operate on a flawed premise: Application-Level Security.

    They run inside WordPress. This means that for the plugin to block a malicious bot, WordPress has to load first. The PHP engine has to spin up, connect to the database, and execute the plugin’s code.

    The “PHP Trap”: Imagine 1,000 bots attack your login page simultaneously.

    • With Wordfence: Your server has to execute WordPress 1,000 times just to say “Access Denied.” This consumes CPU and RAM, often crashing the server (a self-inflicted DDoS) even if the hackers don’t get in.
    • Database Bloat: These plugins log every failed attempt in your database. We have seen wp_options tables bloated by gigabytes of security logs, slowing down the entire site.

    The AgilePress Strategy: Defense in Depth

    We believe that malicious traffic should be stopped as far away from your WordPress installation as possible.

    Layer 1: The Edge (CDN & Cloudflare)

    The best request is the one that never hits your server. We use Cloudflare (or your hosting’s edge firewall) to block geographical threats and known botnets.

    • Cost to your server: Zero.
    • Speed impact: Positive.

    Layer 2: The Server (Hardening & Imunify)

    This is where most people undervalue their hosting. If you use a quality provider with cPanel or Plesk, you already have enterprise-grade tools that operate at the root level, far more efficiently than any plugin.

    • Native Hardening: We configure the server to apply strict rules (like disabling PHP execution in upload folders) directly from the control panel.
    • Imunify360 / ImunifyAV: Many modern servers come with Imunify built-in. This tool scans files and blocks malware at the Linux OS level. It runs in the background without slowing down your WordPress and without writing junk logs to your database.
    • The Reality: If your server has Imunify, installing Wordfence is redundant and harmful to performance.

    Layer 3: The Application (The AgilePress Stack)

    Once traffic passes the Edge and the Server, it reaches WordPress. Here, we need a lightweight goalkeeper, not an army.

    1. The Firewall: NinjaFirewall (The “True” WAF)

    Unlike Wordfence, NinjaFirewall is a stand-alone Web Application Firewall.

    Why we choose it: It hooks into PHP (via php.ini or .user.ini) before WordPress loads.

    • It filters requests before the WordPress database connection is established.
    • If a request is malicious, it is killed instantly. WordPress never wakes up.
    • It saves massive amounts of CPU compared to standard plugins.

    2. The Identity Guard: WP 2FA (by Melapress)

    A firewall protects the perimeter; 2FA protects the user. We use WP 2FA because it adheres to the Unix philosophy: “Do one thing and do it well.” It doesn’t scan files, it doesn’t check IPs. It just provides a rock-solid, lightweight Two-Factor Authentication.

    3. The Anti-Bot Shield: Cloudflare Turnstile (Goodbye reCAPTCHA)

    Spam and brute-force attacks are usually automated. Traditionally, developers stopped this with Google reCAPTCHA, which forces users to “click on traffic lights” and loads heavy scripts that spy on your visitors.

    At AgilePress, we use Cloudflare Turnstile.

    • Invisible: It verifies if the visitor is human without forcing them to solve puzzles (Zero Friction).
    • Lightweight: It is far more privacy-respecting and lighter than Google’s solution.
    • Effective: It stops bots at your login and contact forms without punishing your real customers.

    Conclusion: Engineering vs. Fear

    The “Big Security Plugins” sell peace of mind through complexity. They want you to see a dashboard with 50 checkboxes and a map of blocked attacks so you feel like the plugin is “working.”

    In reality, that dashboard is slowing you down.

    At AgilePress, we build secure sites by design. We block at the Edge, harden the Server with Imunify, filter with NinjaFirewall, and verify with Turnstile.

    Maximum Security. Minimal Footprint.