DEV Community: Muazzam

From Audit Findings to Low-Risk Fixes on a Managed WordPress Site

Muazzam — Mon, 27 Apr 2026 10:18:36 +0000

From Audit Findings to Low-Risk Fixes on a Managed WordPress Site

A routine security review exposed several gaps on a live WordPress site hosted on WP Engine, including a missing security.txt file, missing HTTP security headers, and broader concerns around admin exposure. The challenge was not just fixing the findings, but doing so in a way that avoided downtime, avoided unnecessary plugins, and respected the realities of an already-running client environment.

The problem

The site had landed in the familiar middle ground that many long-running WordPress projects occupy: stable enough to stay online, but missing a few modern security controls that external audits now expect to see. The audit highlighted missing security.txt, missing headers such as Permissions-Policy, Referrer-Policy, Strict-Transport-Security, and X-Content-Type-Options, and recommendations around access restrictions for admin-related paths. None of these items existed in isolation; together, they raised the real question every developer has to answer on production work: how to improve security without creating avoidable breakage.

Why this was tricky

On paper, the fixes looked simple. In practice, applying security controls to a live managed-hosting setup can be risky when plugins, third-party scripts, old content, and operational habits have built up over time. A strong policy applied too aggressively can block legitimate assets, disrupt logins, or create support noise for a site that had otherwise been functioning normally.

That meant the job was not “apply every recommendation immediately.” The job was to split findings into safe wins, cautious changes, and deferred items that required testing or approval.

The first fix: `security.txt`

The first step was to publish a valid security.txt file at the standard discovery path expected by security tooling. The useful lesson here is that security.txt does not need to be overengineered from day one. Under RFC 9116, only Contact and Expires are required; fields such as Policy, Encryption, and Acknowledgments are optional.

That matters because many organizations do not yet have a formal vulnerability disclosure program, a public policy page, or a dedicated PGP key. In that situation, the right move is to publish a minimal but accurate file rather than a polished-looking file full of placeholders nobody will maintain.

A minimal version looked like this:

Contact: mailto:security@example.com
Expires: 2027-03-31T23:59:59Z

That solved the audit finding while keeping the implementation honest and maintainable.

The second fix: security headers in the right place

The next step was to add the missing HTTP security headers, but not through another WordPress plugin. On WP Engine, platform-level configuration through Web Rules is a cleaner and more supportable place to manage response headers than patching them into the application layer.

This distinction matters. A plugin-based fix may technically work, but it also adds more moving parts to the same WordPress stack that is already being audited for risk and complexity. Using the hosting platform for headers reduces that dependency footprint and makes the behavior easier to reason about across environments.

The rollout focused first on the safer headers:

X-Content-Type-Options: nosniff to reduce MIME-type sniffing risk.
Referrer-Policy: strict-origin-when-cross-origin to improve privacy without usually breaking normal behavior.
A conservative Permissions-Policy based on what the site actually needed, instead of a copied policy template.

The fix that needed caution

Strict-Transport-Security was not treated as a copy-paste checkbox. HSTS is valuable, but it changes browser behavior in a sticky way by telling clients to use HTTPS only for a defined period, which means a bad rollout can have consequences beyond a single deploy.

That is why the safer approach was to stage HSTS behind an HTTPS readiness check instead of enabling an aggressive policy immediately. If any assets, legacy links, or integrations still depend on http://, turning on HSTS too early can break parts of the site experience rather than harden it cleanly.

What actually solved the problem

The real solution was not one header or one file. The solution was a triage model:

Implement immediately what is low-risk and clearly beneficial.
Test carefully anything that can affect site behavior across browsers or subdomains.
Defer controls that require stakeholder approval, process change, or operational support.

That approach turned a potentially messy audit response into a practical remediation plan. It also kept the work aligned with the reality of WordPress development: good security changes are the ones that survive production, not just the ones that look impressive in a checklist.

What this is really about

Security work on WordPress often gets framed as a plugin hunt or a list of hardening tips. In production, it is usually a prioritization problem instead: deciding what belongs in hosting, what belongs in the app, what needs testing, and what should wait for process maturity.

That is the more useful lesson from this kind of task. The best security fix is often not the most aggressive one; it is the one that improves the posture of the site while keeping risk, complexity, and maintenance load under control.

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.

Sorting a Bricks query loop by a custom field chosen in a JetSmartFilters radio filter

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

I needed a sidebar radio list of custom field names (for example "Weight", "Length", "Rating") on a listing built with Bricks Builder, JetEngine and JetSmartFilters (JSF). When a user picks one, the listing should only show posts that have a value for that field, sorted highest to lowest by it, and any other active filters (taxonomy, search) should keep working alongside it.

JSF has a Sort widget and a Radio filter widget, but they work independently. Picking a radio value doesn't trigger a sort, and there's no setting for "when this value is selected, sort by that meta key". So I used the radio filter only to pass a plain value to the server, and changed the query in PHP through Bricks' bricks/posts/query_vars filter. No JavaScript needed.

The setup: a Bricks query loop with a JSF Query ID, a JetEngine CPT whose custom fields are all numeric, and a JSF Radio filter next to the existing taxonomy filters on the same page.

The radio filter

In JSF, create a Radio filter:

Data Source: Manual Input
Options List: one entry per field. Label is the display name, Value is the meta key.

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

This filter for: Bricks query loop
Query ID: the same ID set on your Bricks loop element (I used my-listing)
Apply on: Value change
Query Variable: _plain_query::sort_by_field

The _plain_query:: prefix tells JSF to pass the value through as a plain query variable instead of trying to build its own meta query from it.

On the Bricks side, select the query loop element and set the Query ID in the JSF settings panel (JSF adds the field once the element is marked as filterable). Every JSF filter on the page needs the same ID in "This filter for".

The hook

This goes in the 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 matters, see below


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

The whitelist is not optional. The meta key comes from the request, and without the check anyone could sort or filter your listing by any meta key in the database.

What made it fail first

The code above is short. Getting there took longer, and every failure had the same shape: the hook ran fine and did nothing, with no error anywhere.

The settings key is `jsfb_query_id`

Inside the hook, Bricks stores the JSF Query ID under jsfb_query_id, not query_id. Checking query_id always returns empty, so the hook skips every request. I only found it by dumping the whole 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);

Filter values arrive in POST

When a user clicks a filter, JSF sends an AJAX request and the values are in $_POST['query']. Reading $_GET gives you nothing on filter interactions.

The prefix changes the key name

With the Query Variable set to _plain_query::sort_by_field, the key in the POST payload is _plain_query_sort_by_field. The :: becomes _.

JSF overwrites you at default priority

This was the most painful one. At the default priority of 10, JSF runs its own bricks/posts/query_vars callback after mine and resets orderby back to date, so the code looks correct and the order is still wrong. Registering at 99 makes my hook run last, so it has the final say on the query arguments.

Also declare all four parameters ($query_vars, $settings, $element_id, $element_name) and pass 4 as the last argument to add_filter. $element_name was added in Bricks 1.11.1.

The full flow

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 it

When this kind of integration does nothing, I log each step so I can see exactly where the chain breaks instead of guessing:

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);

With WP_DEBUG_LOG enabled the output goes to /wp-content/debug.log. Check it after each filter click. If "HOOK FIRED" shows up but jsfb_query_id is empty, it's the key name. If the final query_vars look right but the order is still wrong, something is running after you, which in my case was JSF at a later priority.

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

From Audit Findings to Low-Risk Fixes on a Managed WordPress Site

From Audit Findings to Low-Risk Fixes on a Managed WordPress Site

The problem

Why this was tricky

The first fix: security.txt

The second fix: security headers in the right place

The fix that needed caution

What actually solved the problem

What this is really about

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

Sorting a Bricks query loop by a custom field chosen in a JetSmartFilters radio filter

The radio filter

The hook

What made it fail first

The settings key is jsfb_query_id

Filter values arrive in POST

The prefix changes the key name

JSF overwrites you at default priority

The full flow

Debugging it

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

The first fix: `security.txt`

The settings key is `jsfb_query_id`

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