AgilePress

Tag: Staging

  • 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.

  • Cowboys Code in Production: The Staging Protocol

    It is Friday at 4:30 PM.

    You want to make a “small tweak” to your checkout page CSS. You edit the file directly in the WordPress dashboard or via FTP.

    You hit “Save.”

    Suddenly, the screen goes white. Critical Error.

    Your online store stops processing orders. You scramble to undo the change, but you don’t remember exactly what line you deleted.

    This is called “Cowboy Coding.” It is shooting from the hip in a live environment. It is unprofessional, dangerous, and strictly forbidden in the AgilePress philosophy.

    Errors should happen in private, not in public. That is why you need a Staging Environment.

    What is Staging?

    A Staging Site is an exact clone of your live website. It lives in a private URL (e.g., staging.yoursite.com).

    • It has the same plugins.
    • It has the same content.
    • It has the same server configuration.

    But it is disconnected from the public. You can update plugins, switch themes, or break the code entirely. If it breaks, nobody sees it. You fix it, test it, and then copy it to the live site.

    Here are the four levels of Staging, ranked from “AgilePress Standard” to “Avoid.”

    Level 1: The Gold Standard (Server-Level Staging)

    This is the best option because it happens at the server infrastructure level.

    Providers: Cloudways, Kinsta, WPEngine, SiteGround.

    • How it works: You log into your hosting panel and click “Create Staging.” The server duplicates the entire application in minutes.
    • The Deploy: When you are happy with the changes, you click “Push to Live.”
    • Why it wins: It guarantees the server environment (PHP version, Caching rules) is identical. If it works on Staging, it will work on Live.

    Level 2: The Developer’s Lab (LocalWP)

    This is where code is born.

    Tool: LocalWP (Free).

    • How it works: You run the website on your own computer (offline).
    • Use Case: Ideal for building a new site from scratch or doing heavy custom coding (creating a custom plugin).
    • The Limitation: It is hard for clients to approve changes since the site is on your laptop. You usually need to push it to a Staging server for final approval.

    Level 3: The “Guerrilla” Solution (Staging Plugins)

    What if you are stuck on a cheap shared hosting plan (cPanel) that doesn’t offer Staging? You use a plugin.

    Tool: WP Staging (Pro recommended).

    • How it works: It creates a clone of your site inside a subfolder (e.g., yoursite.com/staging) and disconnects it from the main database.
    • The AgilePress Warning:
      • Bloat: It duplicates your database tables (using prefixes like wpstg_) and doubles your file usage.
      • Performance: It uses the same server resources as your live site. Heavy testing on staging might slow down the live site.
      • Verdict: Use this only if you cannot upgrade to better hosting.

    Level 4: The “Old School” (Manual Subdomains)

    Method: Creating a subdomain dev.site.com, creating a new FTP folder, copying files, exporting the database, finding and replacing URLs…

    Verdict: AVOID.

    Why? Because friction kills discipline. If creating a staging site takes 1 hour, you won’t do it for a small plugin update. You will take the risk. Automation is the key to safety.

    The Danger Zone: The “Time Travel” Problem

    This is the most critical part of this article. Read this carefully if you run a WooCommerce store or a Membership site.

    The Scenario:

    1. Monday: You create a Staging copy.
    2. Tuesday: You are working on the design in Staging. Meanwhile, 5 customers buy products on the Live site.
    3. Wednesday: You finish the design and click “Push to Live” (overwriting the database).

    The Result:

    You just deleted the 5 orders from Tuesday. You overwrote the Live database with the Staging database (which is from Monday). Those orders are gone forever.

    The AgilePress Rule for Dynamic Sites:

    • Code (Files, Plugins, Themes) flows UP: Staging -> Production.
    • Data (Orders, Users, Posts) flows DOWN: Production -> Staging.

    How to handle it:

    If you are on a server-level staging (Level 1), most hosts allow you to “Push Files Only” and skip the database.

    If you need to push database changes (e.g., you created a new page), you must put the Live site in Maintenance Mode while you work, so no new orders come in.

    Conclusion: Professional Peace of Mind

    An “Update Failed” message on a Tuesday morning can ruin your week.

    A white screen during a Black Friday sale can ruin your business.

    Staging is not a luxury tool for big agencies. It is the seatbelt for your website.

    1. Check if your host offers Staging (Level 1).
    2. If not, use WP Staging (Level 3).
    3. Never edit code on a live site.

    Amateurs hack the live site. Professionals deploy from Staging.