DEV Community: Pratap

The PHP Stack I Built TrustGate On — And Why I'd Do It Differently Today

Pratap — Sat, 23 May 2026 18:36:44 +0000

I built TrustGate — India's independent business review platform — entirely as a custom WordPress plugin.

Full REST API. Custom database tables with versioned migrations. Cryptographically secure random tokens for a live embeddable badge system. A bulk email campaign engine. Claim verification flows with fraud detection, appeal systems, and audit trails. JSON-LD schema markup on every business profile page.

All of it. Solo. In PHP. On WordPress.

This is not a tutorial. This is an honest breakdown of the architectural decisions I made, the ones that hurt me, and what I'd tell you before you write a single line.

The Stack

WordPress (latest)
├── Custom Plugin — trustgate-reviews
│   ├── core/
│   │   ├── class-database.php       — DB tables + versioned migrations
│   │   └── class-reviews.php        — Business/review CRUD
│   ├── includes/
│   │   ├── class-rest-api.php       — Route registration
│   │   ├── trait-rest-api-businesses.php
│   │   ├── trait-rest-api-reviews.php
│   │   ├── trait-rest-api-claims.php
│   │   ├── trait-rest-api-badge.php
│   │   ├── trait-rest-api-helpers.php
│   │   └── trait-rest-api-auth-admin.php
│   ├── admin/
│   │   ├── class-admin.php          — Menu registration
│   │   ├── class-admin-pages.php    — All admin page methods (3,200 lines)
│   │   └── partials/                — Admin page templates
│   └── public/
│       ├── templates/               — Custom page templates
│       │   ├── single-business.php
│       │   ├── for-businesses.php
│       │   ├── pricing.php
│       │   └── partials/
│       └── js/
│           └── trustgate-badge.js   — The embeddable badge widget

The database layer has its own versioned migration system — not relying on dbDelta alone. Every schema change goes through maybe_run_migrations(), which checks a version option and runs incrementally:

public static function maybe_run_migrations() {
    $current = get_option('trustgate_db_migration_version', '0');
    global $wpdb;

    if (version_compare($current, '1.1', '<')) {
        // Add sub_ratings + experience_tags columns
    }

    if (version_compare($current, '1.2', '<')) {
        // Create badge_applications + badge_activations tables
    }

    if (version_compare($current, '1.3', '<')) {
        // Add response_updated_at to reviews
    }

    if (version_compare($current, '1.4', '<')) {
        // Add campaign_emailed_at to businesses
    }

    update_option('trustgate_db_migration_version', '1.4');
}

This keeps the schema in sync across environments without manual SQL runs.

The Decision I'd Revisit

I built the entire admin interface inside a single PHP class — class-admin-pages.php.

At launch: ~800 lines. Every method was readable, the file was navigable, and I felt in control.

By the time I added the badge system, campaign email engine, claim appeals, fraud detection, and the badge applications admin panel — it was 3,200 lines in a single file.

Every new feature meant scrolling through thousands of lines to find the right method. Every bug fix risked breaking something three functions away. A str_replace gone wrong during a bulk edit once nuked a working modal and cost me two hours.

The fix was obvious in hindsight: split into traits from day one. I eventually did this for the REST API layer:

class Trustgate_Reviews_REST_API {
    use Trustgate_REST_API_Businesses_Trait;
    use Trustgate_REST_API_Reviews_Trait;
    use Trustgate_REST_API_Claims_Trait;
    use Trustgate_REST_API_Badge_Trait;
    use Trustgate_REST_API_Helpers_Trait;
    use Trustgate_REST_API_Auth_Admin_Trait;
}

Each trait owns exactly one domain. trait-rest-api-badge.php handles everything badge-related — route registration, apply/approve/reject endpoints, domain whitelisting, email templates, the campaign send engine. It's ~600 lines and a pleasure to work in.

The admin class still isn't split. It's on the roadmap. It's also my biggest current regret.

The WordPress Decision

I chose WordPress + custom PHP plugin instead of a headless Next.js + Node architecture. Most people in my network said that was the wrong call for a platform product.

They were partially right — and entirely wrong.

What WordPress gave me for free on day one:

Authentication, user roles, capability checks — current_user_can('manage_options'), done
Media handling — logo/banner uploads without writing a single upload handler
WP-Cron — scheduled tasks without a separate worker process
wp_mail() — transactional email through the host's SMTP, no Sendgrid setup
WP REST API — production-ready, versioned, nonce-authenticated endpoints out of the box
$wpdb->prepare() — parameterised queries with a clean API
Plugin activation hooks — register_activation_hook runs dbDelta to create tables on install

The alternative would have been two months of infrastructure before I wrote a single domain-specific line of code.

What it cost me:

Fighting Astra theme layout conflicts on custom template pages. The pattern that worked — close Astra's containers after get_header(), output your content freely, reopen before get_footer() — took two days to figure out:

get_header();
?>
<!-- Close Astra containers -->
</div></div></main>

<div class="my-page-wrap">
  <!-- Custom page content here -->
</div>

<!-- Reopen Astra containers for footer -->
<main class="site-main"><div class="ast-container"><div class="ast-row">

<?php get_footer(); ?>

Not elegant. But it works with any Astra child theme without touching theme files.

The other cost: wp_magic_quotes(). WordPress applies addslashes() to all $_POST / $_GET data — including REST API request bodies. Which means a business name like Manoj's Geography Classes gets stored in the DB as Manoj\'s Geography Classes unless you explicitly call wp_unslash() before saving.

I found this bug after a business owner reported garbled text on their profile page. The fix was one line. The diagnosis took longer than it should have because I assumed sanitize_text_field() handled it — it doesn't. The correct pattern:

'name' => sanitize_text_field(wp_unslash($params['business_name'])),

Always wp_unslash() first, then sanitize.

The Badge System

The feature I'm most proud of is the TrustGate Verified Badge.

Business owners claim their profile, get verified by admin, apply for the badge, and receive an approval email with embed codes. They paste one line of HTML into their website. The badge renders live data — star rating, review count — fetched from our REST API using a cryptographically secure random token:

// Token generation on badge approval
$token = bin2hex(random_bytes(32)); // 64-char hex token

The badge JS is under 4KB, async-loaded:

<div class="tg-badge" data-token="YOUR_TOKEN" data-style="compact"></div>
<script src="https://trustgate.in/wp-content/plugins/trustgate-reviews/public/js/trustgate-badge.js" async></script>

The live data endpoint validates the token and — critically — enforces domain whitelisting:

public function get_badge_live_data($request) {
    $token      = sanitize_text_field($request['token']);
    $activation = $wpdb->get_row($wpdb->prepare(
        "SELECT business_id, embed_domain FROM $activations_table
         WHERE token = %s AND is_active = 1",
        $token
    ));

    if (!$activation) {
        return new WP_Error('invalid_token', 'Invalid token.', ['status' => 404]);
    }

    // Domain whitelisting — prevent token theft
    if (!empty($activation->embed_domain)) {
        $allowed      = strtolower(preg_replace('/^www\./i', '', $activation->embed_domain));
        $raw_origin   = $_SERVER['HTTP_ORIGIN'] ?? $_SERVER['HTTP_REFERER'] ?? '';
        $request_host = strtolower(preg_replace('/^www\./i', '', parse_url($raw_origin, PHP_URL_HOST) ?? ''));

        if (!empty($request_host) && $request_host !== $allowed) {
            return new WP_Error('domain_not_allowed', 'Unauthorised domain.', ['status' => 403]);
        }
    }

    // Return live data...
}

Without this, any competitor could scrape a badge token from the page source and embed another business's ratings on their own site.

What TrustGate Has Today

Verified business profiles with GST/MCA entity grounding
Review submission with sub-ratings, experience tags, and consent gates
Owner dashboard — respond to reviews, edit responses with audit timestamps
Full moderation pipeline — approve/reject with email notifications, fraud flagging, appeal system with 3-attempt blocking
TrustGate Verified Badge — 3 embed styles, live API, domain whitelisting, 1,000 founding partner limit
Badge campaign system — bulk/single email targeting unclaimed businesses, TinyMCE body editor, placeholder chips, batch sending with progress bar
/for-businesses/ and /pricing/ as WordPress template overrides with full SEO schema
RankMath integration — custom title/description per business profile, schema disabled selectively per page type
JSON-LD schema — LocalBusiness, AggregateRating, Review, FAQPage, BreadcrumbList on every business page

All of it in a single WordPress plugin. All of it solo.

What I'd Tell You Before You Write a Single Line

Don't let the stack be your first debate. Let the problem be your first debate.

I've watched teams spend three months choosing between Next.js and Remix for products that had zero validated demand. I spent that time building.

Pick the stack that gets you to your first 100 real users. You can refactor architecture. You cannot un-waste six months building infrastructure for a product nobody is using yet.

The architecture that matters most is the one that ships.

If you're building a review platform, a directory, or any consumer-facing product — I'm happy to talk through specific decisions. Drop a comment or find me on LinkedIn.

And if you have a business listed anywhere in India — check if you're already on TrustGate. Our founding partner badge program is free for the first 1,000 verified businesses.

Building a Business Review Platform on WordPress with REST API — What I Learned

Pratap — Mon, 11 May 2026 10:50:03 +0000

I built TrustGate from scratch — a business review and trust platform for the Indian market. Think verified business profiles, customer reviews, owner responses, and an embeddable trust badge that pulls live data.

The entire backend runs on a custom WordPress plugin using the REST API exclusively. No admin-ajax.php. Not a single call to it.

This post is about what I learned building it, what broke, what I got wrong the first time, and the decisions that actually held up.

Why REST API and not admin-ajax

When I started, the easy path was admin-ajax.php. Every tutorial uses it. It works. But it has real problems for a platform of this type.

Every request, regardless of whether a user is logged in or not, boots the entire WordPress admin. That is expensive. For a review platform where anonymous users are searching and browsing businesses constantly, that overhead adds up fast.

The REST API routes only load what they need. Public endpoints run lean. Authenticated endpoints check permissions early and bail out before doing unnecessary work.

The other reason is structure. admin-ajax.php encourages you to dump everything into one giant handler function. The REST API forces you into proper route registration with explicit HTTP methods, permission callbacks, and sanitization callbacks — all separated. Your code ends up cleaner whether you like it or not.

The basic structure I settled on

Everything lives under a versioned namespace:

add_action( 'rest_api_init', function() {
    register_rest_route( 'trustgate/v1', '/businesses', [
        'methods'             => 'GET',
        'callback'            => 'tg_get_businesses',
        'permission_callback' => '__return_true',
    ]);

    register_rest_route( 'trustgate/v1', '/reviews', [
        'methods'             => 'POST',
        'callback'            => 'tg_submit_review',
        'permission_callback' => 'tg_is_logged_in',
    ]);
});

Public routes like business listings get __return_true as the permission callback. Anything that writes data — submitting a review, claiming a business, owner responses — requires authentication.

The permission callback runs before the main callback. If it returns false, WordPress automatically returns a 403 before your main function even runs. This is clean and hard to accidentally skip.

The NULL safety problem I kept hitting

The platform stores a lot of optional data. Business logos, banner images, contact numbers, website URLs — not every business has all of these filled in. Early on I was doing things like:

$logo_url = get_post_meta( $business_id, 'tg_logo_url', true );
echo '<img src="' . $logo_url . '">';

Which works until it doesn't. Empty strings, NULL values from the database, and unset meta keys all behave slightly differently in PHP depending on context. The approach that fixed this completely was wrapping every meta retrieval:

function tg_get_meta( $post_id, $key, $default = '' ) {
    $value = get_post_meta( $post_id, $key, true );
    return ( $value !== '' && $value !== null && $value !== false ) 
        ? $value 
        : $default;
}

One function. Every meta call goes through it. No more inconsistent empty values breaking JSON responses.

Sanitization and validation are not the same thing

This distinction cost me time. I was mixing them up.

Validation checks whether the input is acceptable. If it fails, you return an error.

Sanitization cleans the input. You use it when you'd rather transform bad input than reject it.

For review submissions, the star rating should be validated — it must be an integer between 1 and 5, and if it isn't, the request should fail:

register_rest_route( 'trustgate/v1', '/reviews', [
    'methods'  => 'POST',
    'callback' => 'tg_submit_review',
    'permission_callback' => 'tg_is_logged_in',
    'args' => [
        'rating' => [
            'required'          => true,
            'validate_callback' => function( $value ) {
                return is_numeric( $value ) 
                    && (int) $value >= 1 
                    && (int) $value <= 5;
            },
        ],
        'review_text' => [
            'required'          => true,
            'sanitize_callback' => 'sanitize_textarea_field',
        ],
    ],
]);

Review text gets sanitized — strip any HTML, clean whitespace, but don't reject the whole request over formatting. Rating gets validated strictly. This split makes the API predictable.

Handling the trust badge

The embeddable badge was the most interesting technical piece to build.

Each verified business gets a badge they can paste on their website — a small script tag that renders their current TrustGate rating and review count dynamically. The script hits a public REST endpoint:

GET /wp-json/trustgate/v1/badge/{business_id}

Which returns:

{
  "business_name": "Example Business",
  "rating": 4.7,
  "review_count": 83,
  "verified": true,
  "badge_url": "https://trustgate.in/business/example-business"
}

The embedded script fetches this and renders the badge in the business's own website. Under 4KB. Loads asynchronously so it has zero impact on the host page's performance.

The key decision here was keeping this endpoint completely public and cached aggressively. No authentication, no session lookup, just a fast database read and a JSON response. Response time for this endpoint matters more than almost anything else because it affects websites that are not even ours.

The claim verification workflow

Business owners can claim their profile by submitting documents — GST certificate, MCA filing, Udyam certificate. The claim goes into a pending queue that an admin reviews manually.

I built a three-attempt limit into this. After three failed or rejected claim attempts, the user account is flagged and the claim form is blocked. This was necessary because some users were submitting incomplete documentation repeatedly without fixing anything.

The flag status is stored in user meta and checked by a permission callback before the claim endpoint even processes:

function tg_can_submit_claim( $request ) {
    if ( ! is_user_logged_in() ) {
        return new WP_Error( 
            'not_logged_in', 
            'You must be logged in.', 
            [ 'status' => 401 ] 
        );
    }

    $attempts = (int) get_user_meta( 
        get_current_user_id(), 
        'tg_claim_attempts', 
        true 
    );

    if ( $attempts >= 3 ) {
        return new WP_Error( 
            'claim_blocked', 
            'Maximum claim attempts reached.', 
            [ 'status' => 403 ] 
        );
    }

    return true;
}

Returning a WP_Error from a permission callback sends the right HTTP status code automatically. The client receives a 403 with a clear message. No extra handling needed in the main callback.

Structured data and SEO

Every business profile page outputs JSON-LD structured data built from the REST API response. The review schema tells Google about the aggregate rating, individual reviews, and the business itself.

This was a deliberate architecture decision. The data driving the structured data markup comes from the same place as the data driving the page — the REST API. No duplication, no chance of them going out of sync.

The platform started ranking on Google within weeks of launch. Positions 2 to 7 for target keywords with zero advertising. Structured data was a significant factor.

What I got wrong

A few things I would do differently:

Custom tables vs post meta. Reviews are stored as a custom post type with meta. This made sense early on for simplicity but it is getting slow as volume grows. Custom database tables with proper indexing would have been faster and easier to query for aggregate data like average ratings.

Caching too late. I added object caching to expensive queries after I noticed slowdowns rather than designing for it from the start. Building cache invalidation into the write endpoints from day one would have saved refactoring time.

Not versioning endpoints sooner. The /trustgate/v1/ namespace is there from the start, which is good. But I did not think carefully about what a v2 would need to change until v1 was already embedded in the badge scripts on other websites. Versioning is cheap to add and expensive to skip.

The one thing that helped most

Treating every endpoint like a public API even when it was only being used internally. That means proper HTTP status codes, consistent JSON response shapes, explicit error messages, and no shortcuts on permission checks.

When you do this, debugging becomes straightforward. The browser dev tools tell you exactly what went wrong and why. Frontend code can rely on the response structure. And when you eventually do open an endpoint to external use, you have nothing to fix.

WordPress gets dismissed as a toy by a lot of developers. The REST API is genuinely good. The constraint is not the framework — it is whether you treat it seriously.

TrustGate is live at trustgate.in. Feedback welcome.