Building WP Career Board: A Block-Native Job Board With Zero Third-Party Dependencies

Every WordPress job board plugin I’ve looked at was built on technology from 2012. Shortcodes. jQuery. admin-ajax.php. Full page reloads on every search. Custom templates that break with theme updates. I decided to build one from scratch, on the stack WordPress itself is moving toward. The result is WP Career Board, and I want to talk about the technical decisions behind it.

The Architecture: Blocks + Interactivity API

WP Career Board has zero shortcodes. Every feature is a Gutenberg block, 14 in the free plugin, 15 more in Pro. Drop them on any page, in any theme. The block editor handles the layout. The frontend runs entirely on the WordPress Interactivity API. If you haven’t worked with it yet: it’s WordPress’s answer to Alpine.js/htmx. Server-rendered HTML with declarative data-wp-* directives that handle interactions client-side. What this means in practice:

Zero jQuery. The entire plugin has no jQuery dependency. Search, filtering, pagination, application submissions, dashboard interactions, all Interactivity API stores.
Zero admin-ajax.php. Every data operation goes through the wcb/v1 REST API. Proper endpoints with schema validation, permission callbacks, and typed responses.
Zero page reloads. Candidate applies for a job? The application panel updates inline. Employer reviews an application? Status changes instantly. Everything stays on the page.
Server-side rendering. Every block renders its initial state via render.php with wp_interactivity_state(). The page loads complete, the Interactivity API hydrates it for interactions. Good for SEO, good for perceived performance.

The Block Architecture

Each block follows a strict pattern:

blocks/{name}/
├── block.json    # apiVersion: 3, interactivity support
├── render.php    # Server render + wp_interactivity_state()
├── view.js       # Interactivity API store
└── style.css     # Block styles

Registered via register_block_type_from_metadata(), no manual PHP registration arrays. The block.json declares everything: attributes, supports, styles, interactivity support. The key blocks:

wcb/job-listings, Server-rendered job cards with instant search, category/location/type filters, and pagination. All Interactivity API.
wcb/employer-dashboard, A full tabbed dashboard (Overview, Jobs, Applications, Company) rendered as a single block. Tab switching and data loading happen client-side via REST.
wcb/candidate-dashboard, Same pattern for candidates: Applications, Saved Jobs, Profile. Real-time status updates.
wcb/job-form, Multi-step job posting form (Basics → Details → Categories → Preview) with inline validation.

REST API First

The REST API isn’t an afterthought, it’s the backbone. Every block fetches data from /wp-json/wcb/v1/ endpoints. Every form submission POSTs to REST. The admin dashboard reads from the same endpoints.

wcb/v1/jobs, CRUD + search + filters
wcb/v1/applications, Submit, status updates, employer actions
wcb/v1/companies, Profile management
wcb/v1/candidates, Profile, saved jobs
wcb/v1/admin, Settings, import, analytics

Every endpoint follows the same pattern: extends WCB\Api\REST_Controller, declares schema in get_item_schema(), validates with validate_callback, sanitizes with sanitize_callback, checks permissions with permission_callback. No ad-hoc JSON responses.

PHP 8.1+ and Modern WordPress

The minimum is PHP 8.1 and WordPress 6.9. This isn’t a checkbox requirement, the code actually uses modern PHP:

Typed properties and return types on all public methods
Enums for application statuses (ApplicationStatus::Submitted, not magic strings)
Named arguments where they improve readability
Match expressions instead of switch/case chains
declare(strict_types=1) in every file
PSR-4 autoloading via spl_autoload_register, namespace WCB\ maps to directory structure

The Modular Architecture

The plugin is organized into self-contained modules:

modules/
├── antispam/, reCAPTCHA v3 + Turnstile drivers
├── boards/, Multi-board support
├── notifications/, 8 email templates
├── search/, Search indexing
├── seo/, JobPosting schema.org structured data
└── theme-integration/, Reign, BuddyX Pro, BuddyPress bridges

Each module registers itself, declares its hooks, and handles its own lifecycle. The core plugin doesn’t know the details, it just loads modules.

Pro: Same Architecture, Extended Features

WP Career Board Pro extends Free through hooks and filters, never duplicates. The Pro plugin:

Kanban Application Pipeline, Configurable hiring stages with drag-and-drop. The only WordPress job board with a real ATS-style pipeline. Built as an Interactivity API block with REST-backed drag operations.
Multi-Board Engine, Unlimited independent job boards from one WordPress install. Each board has its own settings, categories, and appearance. Useful for agencies running boards for multiple clients.
Resume Builder + Search, 7-section structured resumes that candidates build from the frontend. Employers search with filters. PDF export via DomPDF (the only vendor dependency in the entire stack).
WooCommerce Credit System, Employers buy credits to post jobs. Built on the Wbcom Credits SDK, more on this below.
AI Job Descriptions, OpenAI, Anthropic Claude, or self-hosted Ollama. Employers describe the role, AI generates the listing. All API calls happen server-side through a unified provider abstraction.
Job Alerts, Keyword + location subscriptions with instant and digest emails.
XML Job Feed, Feeds compatible with Indeed, LinkedIn, and Google Jobs.

The Wbcom Credits SDK: Plug-and-Play Monetization for Any Plugin

This is one of the most important pieces of infrastructure we built for WP Career Board, and it’s designed to be reused across every Wbcom plugin going forward. The problem: every WordPress plugin that needs to charge users for something (job postings, premium listings, service bookings, content access) ends up building its own payment integration from scratch. You wire up Stripe, handle webhooks, manage balance tables, build admin UIs. Then the next plugin needs the same thing, and you do it all over again. The Wbcom Credits SDK solves this once. It’s a standalone PHP library that any plugin can bundle in its vendor/ directory. Here’s how it works:

Append-Only Ledger

Credits are tracked in a single ledger table with four entry types: topup, hold, deduct, refund. Balance = SUM of all signed amounts. No row is ever updated or deleted, you always have a complete audit trail. When an employer posts a job:

Hold, Credits are reserved (deducted from available balance but not spent)
Deduct, Job is approved, hold converts to a permanent deduction
Or Refund, Job is rejected, credits return to the employer’s balance

This is the same pattern payment processors use. It prevents double-spending and makes refunds clean.

Carousel tile 1: Hire the way your community works

Payment Adapter Architecture

The SDK doesn’t process payments itself. It defines a GatewayInterface with three adapters:

WooCommerce Adapter, Employers buy credit packages as WooCommerce products. Order completes → credits deposited. Works with any WooCommerce payment gateway (Stripe, PayPal, bank transfer, whatever you already have).
Paid Memberships Pro Adapter, Credits bundled with membership levels. Members get X credits per month as part of their subscription.
MemberPress Adapter, Same concept for MemberPress subscriptions.

The plugin never touches payment processing. Your existing WordPress commerce stack handles the money. The SDK just manages the credit balance.

Why This Matters for the Ecosystem

WP Career Board is the first plugin to ship with the Credits SDK, but it won’t be the last. The same SDK will power monetization across our entire plugin line:

WP Career Board Pro, Employers buy credits to post jobs (live now)
Future plugins, Any Wbcom plugin that needs usage-based billing can bundle the same SDK. Service marketplace listings, premium directory entries, paid community features, all using the same credit system, the same admin UI, the same WooCommerce/PMPro/MemberPress adapters.

For site owners, this means one credit balance across multiple plugins. An employer buys a credit package once and can spend credits on job postings, featured listings, or any other credit-powered feature, all from the same balance. No separate payment setups per plugin. For developers building on our ecosystem, it means monetization is plug-and-play. Bundle the SDK, call $credits->hold() and $credits->deduct(), and you have a complete credit system with admin UI, WooCommerce integration, and ledger tracking, without writing a single line of payment code.

Zero Third-Party Runtime Dependencies

This is the decision I’m most deliberate about. At runtime, WP Career Board depends on:

WordPress core
The WordPress Interactivity API (core since 6.5)
DomPDF for resume PDF export (Pro only)

That’s it. No jQuery. No React frontend. No external CSS frameworks. No Stripe SDK. No external analytics. No third-party SaaS calls (except optional AI providers that the admin explicitly configures). Why? Because every dependency you add is a dependency your users inherit. A Stripe SDK update breaks checkout. A jQuery version conflict breaks the frontend. An external API goes down and your plugin stops working. The WordPress ecosystem has everything we need. WooCommerce handles payments. The block editor handles layouts. The Interactivity API handles frontend interactions. The REST API handles data. We don’t need to bolt on external stacks.

The Ecosystem: Reign + BuddyX + WP Career Board

This is the bigger picture. At Wbcom Designs, we’re building a self-contained WordPress ecosystem:

Reign Theme, The community theme. BuddyPress, BuddyBoss, LearnDash, WooCommerce. One theme that handles everything.
BuddyX / BuddyX Pro, The developer-friendly alternative. Lightweight, FSE-ready, clean codebase.
WP Career Board, The job board layer. Works with any theme, but integrates deeply with Reign and BuddyX.
Wbcom Credits SDK, The shared monetization layer. One credit system powering all plugins.

The integration isn’t cosmetic. WP Career Board detects Reign or BuddyX Pro at runtime and bridges CSS custom properties, colors, fonts, spacing all inherit from the theme’s design tokens. Zero custom CSS needed. With BuddyPress, it goes deeper: member types map to employer/candidate roles, activity streams show job-related actions, and profile tabs integrate job/application data. The vision is straightforward: a community site owner installs Reign + BuddyPress + WP Career Board and has a fully functional job board inside their community. No external platforms. No iframe embeds. No sending members to third-party sites. Everything stays on WordPress.

Code Quality: CI + PHPStan + WPCS

Both Free and Pro run CI on every push:

PHP Lint across PHP 8.1, 8.2, 8.3, and 8.4
PHPStan Level 5 with baseline, catches type errors, dead code, incorrect API usage
WPCS (WordPress Coding Standards) enforced locally before every commit

The free plugin is open source on GitHub. PRs welcome.

What’s Next

v1.0.1 is live today. The roadmap includes:

Full i18n and currency localization
Advanced notification system with in-app notifications
Deeper BuddyX Pro and Reign theme integrations
Performance optimizations for boards with 10,000+ listings
Credits SDK adoption across more Wbcom plugins

If you’ve been looking for a WordPress job board that doesn’t feel like it was built in 2012, try WP Career Board. It’s free, it’s open source, and it’s built on the stack WordPress is actually moving toward.