DEV Community: Muazzam

Escaping Managed Hosting: What Happened When We Migrated a WooCommerce Site to a VPS (And Got Attacked)

Muazzam — Sat, 25 Apr 2026 03:02:47 +0000

Escaping Managed Hosting: What Happened When We Migrated a WooCommerce Site to a VPS (And Got Attacked)

Managed WordPress hosting sounds like a great deal — until it isn't. This is the story of migrating a WooCommerce + WPML site off a major managed host, the chaos that followed immediately after, and the hard lessons learned about what managed hosting was silently doing for us that we didn't fully appreciate until it was gone.

Why We Left Managed Hosting

The decision wasn't dramatic. It came down to three compounding frustrations:

Cost vs. control. Managed WordPress hosting at the enterprise tier isn't cheap. As traffic and complexity grew, so did the invoice. But the control stayed locked down — no custom server config, limited cache tuning, no ability to see what was actually hitting the server at a low level.

Performance ceiling. A WooCommerce store with WPML (multilingual) generates a lot of unique URLs — filtered shop pages, language variants, paginated archives. The managed host's caching layer was a black box. When performance degraded, the answer was always "upgrade your plan." There was no way to diagnose what was actually happening underneath.

Visibility. When something went wrong, we couldn't see access logs in real time, couldn't inspect PHP worker counts, couldn't adjust server-level settings. Everything was abstracted. The host was the gatekeeper between us and the actual machine.

The move to a self-managed VPS with RunCloud and OpenLiteSpeed (OLS) promised full visibility and control. It delivered on that promise — but it also immediately exposed us to everything the managed host had been silently absorbing on our behalf.

The Migration: What We Were Walking Into

The stack:

WordPress + WooCommerce with WPML (multilingual, two languages)
Elementor as the page builder
LSCache for caching, Redis for object caching
Migrating from managed hosting to a VPS via RunCloud with OpenLiteSpeed

The migration itself was technically straightforward: export, import, update DNS. What wasn't straightforward was what we discovered in the database afterward.

Problem 1: Serialized Data URL Contamination

During migration, the site temporarily lived on a staging domain (something like mysite.staging.temphost.link). The standard search-replace after migration should catch all references to the old domain and replace them with the new one.

It didn't catch everything.

Several plugins store data in WordPress's wp_options table as serialized PHP arrays. A normal string search-replace on serialized data corrupts it — because serialized strings encode their own length, and changing the URL changes the string length without updating the length prefix.

The plugins that caused contamination:

A media carousel plugin — stored 400KB+ of serialized image data in wp_options, all with the temp domain baked in for image paths
Elementor — had generated CSS files on disk at wp-content/uploads/elementor/google-fonts/css/ with http:// URLs hardcoded, not regenerated after migration
An image optimization plugin — had a WebP cache directory full of references to the old domain

The fix required using WP-CLI's search-replace with the --precise flag, which handles serialized data correctly:

wp search-replace 'mysite.staging.temphost.link' 'mysite.com' --precise --all-tables

For the Elementor font CSS files on disk, a direct find + sed was needed since WP-CLI doesn't touch files:

find /var/www/mysite/wp-content/uploads/elementor/google-fonts/css/ -name "*.css" \
  -exec sed -i 's|http://mysite.staging.temphost.link|https://mysite.com|g' {} \;

Problem 2: Missing SSL Config in wp-config.php

Despite the site running on HTTPS, Elementor kept generating http:// asset URLs. The reason was that wp-config.php was missing two lines that tell WordPress it's behind HTTPS:

$_SERVER['HTTPS'] = 'on';
define('FORCE_SSL_ADMIN', true);

Without these, WordPress doesn't know the request came in over SSL (especially behind a proxy or load balancer), so dynamic URLs default to http://. A subtle issue that caused a surprisingly large number of mixed content problems.

Problem 3: A Security Plugin Blocking Its Own Admin

One of the installed security plugins had added a .htaccess rule that was blocking all PHP file access:

RewriteRule ^.*\.php$ - [F,L,NC]

This rule was intended to block direct PHP file execution in upload directories. But it was placed at the wrong level — it blocked wp-admin, wp-login.php, and every other PHP file on the site. The admin panel was completely inaccessible. The fix was removing that rule from .htaccess manually via SSH before anything else could be done.

The Attack: Day One on the VPS

The migration was complete. The site was live. And then within hours, the server was at 700%+ CPU — that's 7 full cores pinned on a machine that should have been comfortably handling the traffic.

On managed hosting, this had never happened. Not because the traffic wasn't there — but because the managed host was absorbing it silently. Now it was hitting our VPS directly.

Attacker 1: Malicious Bots

Access log analysis revealed two suspicious IPs hammering the site:

grep "111.88.x.x" /var/log/ols/mysite.com_access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -30

Both IPs were sending dozens of requests per minute to wp-admin/admin-ajax.php, WooCommerce AJAX endpoints, and Contact Form 7 REST endpoints — the fingerprint of bots probing for vulnerabilities and scraping data.

Fix: blocked in .htaccess at the top of the file, before any WordPress rules:

# Block malicious IPs
<RequireAll>
    Require all granted
    Require not ip 111.88.x.x
    Require not ip 45.77.x.x
</RequireAll>

Attacker 2: The Meta Crawler (The Real Problem)

Blocking the malicious IPs brought load down — but not to safe levels. Something else was still hammering the server. Back to the access logs:

grep "meta-externalagent" /var/log/ols/mysite.com_access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -30

Facebook's Meta crawler (meta-externalagent/1.1) was systematically crawling every combination of the WooCommerce shop's filter URLs:

/shop/?filter_color=red&filter_size=small
/shop/?filter_color=red&filter_size=medium
/shop/?filter_color=blue&filter_size=small
... hundreds of unique combinations

Here's why this is catastrophic for a WooCommerce + WPML site:

Every unique URL is a cache miss. LSCache serves cached pages instantly with zero PHP. But a cached page is keyed by URL. Each filter combination is a different URL — so each one bypasses the cache entirely, boots WordPress, boots WooCommerce, boots WPML, runs a database query, and renders a response. The crawler was generating thousands of cache misses per hour.

The fix — immediate:

# Block Meta crawler
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} meta-externalagent [NC]
RewriteRule ^ - [F,L]

After adding this rule and restarting OLS:

load average: 0.94 — 4 lsphp processes

From 700%+ CPU to essentially idle. The Meta crawler was the primary load driver the entire time.

The longer-term fix: add the shop's filter URL pattern to robots.txt so crawlers stop attempting them:

User-agent: meta-externalagent
Disallow: /

User-agent: *
Disallow: /shop/?*

What Managed Hosting Was Silently Doing

This is the part that changed how we think about managed hosting.

The managed host had several layers we never thought about:

Bot filtering at the edge — known bad actors and aggressive crawlers were blocked before they reached WordPress at all
DDoS mitigation — volumetric attacks were absorbed by the host's network layer
Rate limiting — aggressive crawlers were throttled automatically

None of this was documented prominently. It was just... happening. Moving to a raw VPS removed all of it at once. The site went from being behind a shield to being fully exposed to the internet with only .htaccess and OLS between it and every bot on the planet.

The visibility was exactly what we wanted — we could finally see everything. But we also now had to handle everything ourselves.

The Permanent Solution: Cloudflare

Fixing bots with .htaccess rules is whack-a-mole. Block one IP, another appears. Block one user agent, it rotates. The real fix is a layer in front of the server that handles this at scale before it ever reaches OLS.

Cloudflare's free plan provides:

Bot Fight Mode — automatically identifies and blocks known bot fingerprints
Rate limiting — caps any single IP's request rate before it can cause load spikes
Edge caching — WooCommerce shop pages can be cached at Cloudflare's edge, so even cache misses on the origin become cache hits at the CDN level
Real-time traffic analytics — finally, full visibility into what's hitting the site and from where

The architecture after adding Cloudflare:

Internet → Cloudflare edge (bot filtering, rate limiting, CDN cache)
         → VPS / OpenLiteSpeed (LSCache, Redis)
         → WordPress / WooCommerce / WPML

Bad traffic is rejected at Cloudflare before it touches the server. The PHP worker pool stays available for real users.

This is what managed hosting was providing implicitly. Cloudflare makes it explicit, configurable, and visible — and the free tier handles the vast majority of what a typical WooCommerce store needs.

Additional Server Hardening After Stabilization

With the immediate crisis resolved, we locked down the remaining attack surface:

Security headers via OLS:

X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Strict-Transport-Security: max-age=31536000; includeSubDomains

PHP worker limits — OLS was configured with a hard cap on concurrent PHP workers:

maxConns 8
PHP_LSAPI_CHILDREN=8

Without this cap, a flood of requests spawns unlimited PHP workers and exhausts RAM. With the cap, excess requests queue rather than spawning new processes.

Snapshot immediately after stabilization — once the server was clean and stable, we took a VPS snapshot as a known-good baseline. If anything goes wrong in future, rollback is one click.

Lessons Learned

1. Managed hosting hides its value until it's gone.
The bot filtering, DDoS mitigation, and crawler management that managed hosts provide are rarely documented but deeply valuable. Budget for replacing that capability explicitly when moving to a VPS.

2. Always use --precise for search-replace on migrated WordPress sites.
Standard search-replace corrupts serialized data. The --precise flag in WP-CLI handles it correctly. Make it a default step in every migration checklist.

3. Cloudflare is not optional for a self-managed WooCommerce store.
Put it in front on day one. Not after you've been attacked. The free plan covers the essentials, and the visibility alone is worth it.

4. WooCommerce filter URLs are a crawler trap.
Any WooCommerce store with faceted filtering generates effectively infinite unique URLs. Configure LSCache to ignore query strings on shop pages, and disallow filter URL patterns in robots.txt before crawlers index them.

5. Access logs are your best friend on a VPS.
The moment something goes wrong, SSH in and read the access log. The answer is almost always there — which IPs, which user agents, which URLs, how many requests per minute. On managed hosting, you often can't do this. On a VPS, it's the first thing you reach for.

The Outcome

The site runs more reliably now on the VPS than it ever did on managed hosting — and at significantly lower cost. Load averages stay under 1.0 under normal traffic. The Cloudflare layer handles bot traffic before it reaches the server. LSCache and Redis handle the WordPress-level caching. And when something goes wrong, we can actually see it.

The migration pain was real. But it was a one-time cost that permanently increased visibility, control, and resilience. The managed host was comfortable — but comfort was masking problems we couldn't see or fix.

How to Filter and Sort Posts by Custom Field Value Using JetSmartFilters + Bricks Builder

Muazzam — Sat, 25 Apr 2026 02:45:19 +0000

How to Filter and Sort Posts by Custom Field Value Using JetSmartFilters + Bricks Builder

If you've ever tried to let users filter and sort a post listing by a numeric custom field — say, a product spec, a rating, or a measurement — you've probably hit the wall where JetSmartFilters (JSF) and Bricks Builder don't quite connect out of the box.

This post documents exactly how to wire them together: a radio filter that, when clicked, filters out posts missing that field and sorts the remaining results by that field's numeric value in descending order.

The Goal

A sidebar radio list of custom field names (e.g. "Weight", "Length", "Rating"). When a user selects one:

Only posts that have a value for that field are shown
Results are sorted highest to lowest by that field's numeric value
All other active filters (taxonomy, search, etc.) continue to stack correctly

The Stack

Bricks Builder — query loop with a custom Query ID
JetEngine — CPT with custom meta fields (all numeric)
JetSmartFilters — Radio filter + existing taxonomy filters on the same page

Why This Isn't Straightforward

JSF has a Sort widget and a Radio filter widget, but they operate independently. Clicking a radio does not trigger a sort. You can't natively say "when this radio value is selected, sort by that meta key."

The solution is to use JSF's radio filter to pass a plain query variable, then intercept Bricks' query via the bricks/posts/query_vars filter hook to inject the correct meta_query, orderby, and meta_key — all server-side, no JavaScript needed.

Step 1 — Set Up the Radio Filter in JSF

In JetSmartFilters, create a new Radio filter with the following settings:

Data Source: Manual Input
Options List: One entry per custom field. Label = display name, Value = the meta key

Label: Weight       Value: weight
Label: Length       Value: length
Label: Rating       Value: rating

This filter for: Bricks query loop
Query ID: your-listing-id (must match the Query ID set on your Bricks loop element)
Apply on: Value change
Query Variable: _plain_query::sort_by_field

The _plain_query:: prefix is important. It tells JSF to pass the value as a plain query variable rather than attempting its own meta query processing. JSF will internally convert this to _plain_query_sort_by_field in the POST payload.

Step 2 — Note Your Bricks Loop Query ID

In Bricks Builder, select your query loop element and set a Query ID under the JSF settings panel (the field labelled "Query ID" added by JSF when the element is marked as filterable).

Example: my-listing

All JSF filter widgets on the page must have the same Query ID set in their "This filter for" setting.

Step 3 — The PHP Hook

Add this to your theme's functions.php or a site-specific plugin.

add_filter('bricks/posts/query_vars', function($query_vars, $settings, $element_id, $element_name) {

    // Target only your specific Bricks loop by its JSF Query ID
    // Note: Bricks stores this under 'jsfb_query_id', not 'query_id'
    $query_id = $settings['jsfb_query_id'] ?? '';
    if ($query_id !== 'my-listing') return $query_vars;

    // JSF sends filter data via POST during AJAX requests
    // The _plain_query:: prefix becomes _plain_query_ in the POST key
    $query_data = $_POST['query'] ?? [];
    $sort_field = sanitize_key($query_data['_plain_query_sort_by_field'] ?? '');

    if (empty($sort_field)) return $query_vars;

    // Whitelist allowed field keys — never trust user input directly
    $allowed_fields = ['weight', 'length', 'rating']; // add all your fields
    if (!in_array($sort_field, $allowed_fields, true)) return $query_vars;

    // Filter: only show posts that have a non-empty value for this field
    $query_vars['meta_query'] = [
        'relation' => 'AND',
        [
            'key'     => $sort_field,
            'compare' => 'EXISTS',
        ],
        [
            'key'     => $sort_field,
            'value'   => '',
            'compare' => '!=',
        ],
    ];

    // Sort: numeric descending by the selected field
    $query_vars['orderby']  = 'meta_value_num';
    $query_vars['order']    = 'DESC';
    $query_vars['meta_key'] = $sort_field;

    return $query_vars;

}, 99, 4); // Priority 99 is critical — see note below


// Register the query var so WordPress doesn't strip it
add_filter('query_vars', function($vars) {
    $vars[] = 'sort_by_field';
    return $vars;
});

Critical Lessons Learned

1. The settings key is `jsfb_query_id`, not `query_id`

When you check $settings inside the hook, Bricks stores the JSF Query ID under jsfb_query_id. Using query_id will always return empty and your hook will silently skip every request.

To discover the correct key for your setup, temporarily dump the full settings array:

add_filter('bricks/posts/query_vars', function($query_vars, $settings, $element_id, $element_name) {
    error_log(print_r($settings, true));
    return $query_vars;
}, 10, 4);

2. JSF uses POST, not GET, for AJAX filter requests

When a user clicks a filter, JSF fires an AJAX request. The filter values are in $_POST['query'], not $_GET. Reading $_GET will always be empty on filter interactions.

3. The `_plain_query::` prefix transforms the POST key

Setting the Query Variable in JSF to _plain_query::sort_by_field results in the POST key being _plain_query_sort_by_field (the :: becomes _). Read it accordingly:

$query_data = $_POST['query'] ?? [];
$sort_field = sanitize_key($query_data['_plain_query_sort_by_field'] ?? '');

4. Hook priority must be higher than JSF's own hooks

This is the most painful one. If you register the hook at the default priority of 10, JSF will run its own bricks/posts/query_vars hook afterward and overwrite your orderby back to date (the default).

Always use priority 99 or higher when your hook needs to be the final word on query arguments:

}, 99, 4); // Not 10. Not 20. Use 99.

5. The hook signature takes 4 parameters

The Bricks documentation shows 4 arguments: $query_vars, $settings, $element_id, $element_name. The last argument ($element_name) was added in Bricks 1.11.1. Always declare all 4 and pass 4 as the last argument to add_filter:

add_filter('bricks/posts/query_vars', function($query_vars, $settings, $element_id, $element_name) {
    // ...
}, 99, 4);

How the Full Flow Works

User clicks radio → "Weight"
        ↓
JSF fires AJAX: POST query[_plain_query_sort_by_field] = weight
        ↓
bricks/posts/query_vars hook fires (priority 99)
        ↓
Hook reads _plain_query_sort_by_field from $_POST['query']
Validates against whitelist
Injects meta_query (EXISTS + not empty)
Injects orderby=meta_value_num, order=DESC, meta_key=weight
        ↓
Bricks executes WP_Query with modified args
        ↓
Results: only posts WITH a weight value, sorted highest → lowest
Other active filters (taxonomy, search) remain stacked — unaffected

Debugging Tips

Add temporary logging to trace exactly where things break:

add_filter('bricks/posts/query_vars', function($query_vars, $settings, $element_id, $element_name) {

    error_log('HOOK FIRED — element: ' . $element_id);
    error_log('jsfb_query_id: ' . ($settings['jsfb_query_id'] ?? 'NOT SET'));

    $query_data = $_POST['query'] ?? [];
    error_log('POST query: ' . print_r($query_data, true));

    $sort_field = sanitize_key($query_data['_plain_query_sort_by_field'] ?? '');
    error_log('sort_field extracted: ' . ($sort_field ?: 'EMPTY'));

    // ... rest of your logic

    error_log('Final query_vars: ' . print_r($query_vars, true));

    return $query_vars;

}, 99, 4);

Check your PHP error log (usually at /wp-content/debug.log with WP_DEBUG_LOG enabled) after each filter interaction.

Summary

What	How
Pass selected field to server	JSF Radio filter with `_plain_query::sort_by_field`
Read the value in PHP	`$_POST['query']['_plain_query_sort_by_field']`
Target the right loop	Check `$settings['jsfb_query_id']`
Filter posts missing the field	`meta_query` with `EXISTS` + `!= ''`
Sort numerically descending	`orderby=meta_value_num` + `meta_key` + `order=DESC`
Prevent JSF from overriding	Hook priority `99`
Correct hook signature	4 params, last arg to add_filter is `4`

How to Use the `bricks/form/custom_action` Hook in Bricks Builder

Muazzam — Sat, 25 Apr 2026 02:41:00 +0000

How to Use the `bricks/form/custom_action` Hook in Bricks Builder

You can run custom PHP code after a Bricks Builder form submission using the bricks/form/custom_action hook. This is ideal if you need to send emails, save entries, or connect with external services.

Step 1: Set Up the Form Action

In your Bricks Builder form settings, go to "Actions after successful form submit" and select Custom.

Step 2: Write Your PHP Logic

Add this code to your theme's functions.php file or use a WordPress code snippets plugin.

// Hook your function to the Bricks custom action
add_action('bricks/form/custom_action', 'my_form_custom_action', 10, 1);

function my_form_custom_action($form) {
    // Get all submitted form fields as an array
    $fields = $form->get_fields(); // Example: ['name' => 'Jane', 'email' => 'jane@example.com']

    // Always check the form ID so your code only runs for the intended form
    $form_id = isset($fields['formId']) ? $fields['formId'] : '';

    if ($form_id !== 'replace_with_your_form_id') {
        // Not the intended form — stop here
        return;
    }

    // Custom logic goes here!
    // Example: integrate with an API, save a post, or trigger a notification

    // Set a user-facing message after submit
    $form->set_result([
        'action'  => 'my_custom_action',
        'type'    => 'success', // 'success', 'error', or 'info'
        'message' => esc_html__('Custom action executed!', 'your-textdomain'),
    ]);
}

Helpful Notes for Junior Devs

Always check formId — This ensures your code only runs for the correct form, especially if you use custom actions on more than one form.
$form->get_fields() returns every value submitted by the user. Use it to process, validate, or forward data to external tools.
$form->set_result() controls what users see after submitting. Always provide friendly messages and handle errors gracefully.
For external integrations (webhooks, APIs), use WordPress's built-in wp_remote_post() rather than raw curl.
Replace all placeholder form IDs and field keys with the actual values from your Bricks form setup.

Example: Creating a WordPress Comment from Form Submission

add_action('bricks/form/custom_action', 'create_comment_from_form', 10, 1);

function create_comment_from_form($form) {
    $fields = $form->get_fields();

    // Only execute for the intended form
    if ($fields['formId'] !== 'myformid') return;

    // Prepare comment data from submitted fields
    $comment_data = [
        'comment_post_ID'      => $fields['postid'],
        'comment_author'       => $fields['name'],
        'comment_author_email' => $fields['email'],
        'comment_content'      => $fields['comment'],
        'comment_approved'     => 1,
    ];

    try {
        wp_insert_comment(wp_slash($comment_data));

        $form->set_result([
            'action'  => 'my_custom_action',
            'type'    => 'success',
            'message' => esc_html__('Comment created!', 'your-textdomain'),
        ]);
    } catch (Exception $e) {
        $form->set_result([
            'action'  => 'my_custom_action',
            'type'    => 'error',
            'message' => esc_html__('Something went wrong. Please try again.', 'your-textdomain'),
        ]);

        // Log the actual error server-side for debugging
        error_log('Bricks form error: ' . $e->getMessage());
    }
}

Note on error messages: Avoid exposing raw exception messages to users with $e->getMessage() — they can leak implementation details. Log errors server-side and show a generic message to the user instead.

DEV Community: Muazzam

Escaping Managed Hosting: What Happened When We Migrated a WooCommerce Site to a VPS (And Got Attacked)

Escaping Managed Hosting: What Happened When We Migrated a WooCommerce Site to a VPS (And Got Attacked)

Why We Left Managed Hosting

The Migration: What We Were Walking Into

Problem 1: Serialized Data URL Contamination

Problem 2: Missing SSL Config in wp-config.php

Problem 3: A Security Plugin Blocking Its Own Admin

The Attack: Day One on the VPS

Attacker 1: Malicious Bots

Attacker 2: The Meta Crawler (The Real Problem)

What Managed Hosting Was Silently Doing

The Permanent Solution: Cloudflare

Additional Server Hardening After Stabilization

Lessons Learned

The Outcome

How to Filter and Sort Posts by Custom Field Value Using JetSmartFilters + Bricks Builder

How to Filter and Sort Posts by Custom Field Value Using JetSmartFilters + Bricks Builder

The Goal

The Stack

Why This Isn't Straightforward

Step 1 — Set Up the Radio Filter in JSF

Step 2 — Note Your Bricks Loop Query ID

Step 3 — The PHP Hook

Critical Lessons Learned

1. The settings key is jsfb_query_id, not query_id

2. JSF uses POST, not GET, for AJAX filter requests

3. The _plain_query:: prefix transforms the POST key

4. Hook priority must be higher than JSF's own hooks

5. The hook signature takes 4 parameters

How the Full Flow Works

Debugging Tips

Summary

How to Use the `bricks/form/custom_action` Hook in Bricks Builder

How to Use the bricks/form/custom_action Hook in Bricks Builder

Step 1: Set Up the Form Action

Step 2: Write Your PHP Logic

Helpful Notes for Junior Devs

Example: Creating a WordPress Comment from Form Submission

1. The settings key is `jsfb_query_id`, not `query_id`

3. The `_plain_query::` prefix transforms the POST key

How to Use the `bricks/form/custom_action` Hook in Bricks Builder