Client Workspace Portal

Overview

The Client Workspace Portal gives your clients a dedicated page on the frontend of their WordPress site where they can submit requests and track their status. Instead of sending emails or using external ticket systems, clients interact with a self-service interface that feeds directly into your AdminLocks workflow.

The portal runs entirely on the frontend using a WordPress shortcode. Clients never need to enter wp-admin. Each request is stored in a dedicated database table, logged to the audit log, and can be managed via the REST API or the AdminLocks Cloud dashboard.

Setting Up the Portal

Setting up the portal takes two steps: create a WordPress page and add the shortcode.

Step 1: Create a page

Create a new WordPress page (e.g., "Client Portal" or "Workspace"). You can use any page template. The portal renders its own UI inside the content area.

Step 2: Add the shortcode

Add the following shortcode to the page content:

[adminlocks_portal]

That is the entire setup. The shortcode handles authentication detection, asset loading, request display, and form rendering.

How it works behind the scenes

1. AdminLocks registers the adminlocks_portal shortcode on init.
2. On wp_enqueue_scripts, it checks if the current post contains the shortcode. If it does, it enqueues portal.css and portal.js. This means zero asset overhead on pages without the portal.
3. When the shortcode renders, it first checks is_user_logged_in(). Unauthenticated visitors see a login prompt with a link to wp_login_url() that redirects back to the portal page after login.
4. For authenticated users, it queries the last 50 requests from the adminlocks_portal_requests table and renders the portal template.

Request Types

The portal supports six request types, each representing a common category of client need. The type is selected from a dropdown when submitting a request.

If an invalid type is submitted, it silently defaults to general. The type list is validated server-side against a hardcoded allowlist.

Submitting Requests

Requests are submitted via AJAX to the wp_ajax_adminlocks_portal_submit action. The portal JavaScript handles form submission, nonce verification, and response display.

Request fields

Security

Every submission is protected by three layers of validation:

• Nonce verification — check_ajax_referer('adminlocks_portal', 'nonce') prevents CSRF attacks. The nonce is generated via wp_create_nonce() and passed to the frontend in the adminlocksPortal localized object.
• Authentication check — is_user_logged_in() is verified server-side. Unauthenticated requests receive a 403 error.
• Input sanitization — the title is sanitized with sanitize_text_field(), the description with sanitize_textarea_field(), and the type is validated against the allowlist.

// The AJAX submission flow (simplified)
jQuery.ajax({
    url: adminlocksPortal.ajaxUrl,
    method: 'POST',
    data: {
        action: 'adminlocks_portal_submit',
        nonce: adminlocksPortal.nonce,
        request_type: 'plugin_install',
        request_title: 'Install WooCommerce',
        request_description: 'We need e-commerce for our new product line.'
    },
    success: function(response) {
        // response.data.message: "Request submitted successfully."
        // response.data.id: 42
    }
});

What happens after submission

1. A new row is inserted into adminlocks_portal_requests with status = 'pending'.
2. The request is logged to the audit log as a portal_request_created event with severity info.
3. A success message is shown to the client and the request appears in their request list.

Managing Requests (Admin)

Administrators manage portal requests through the REST API. Two endpoints are available, both requiring the manage_options capability.

Request lifecycle

pending ──┬──> approved ──> completed
          └──> denied

The review endpoint accepts a status and optional note parameter:

// POST /wp-json/adminlocks/v1/portal-requests/42/review
{
    "status": "approved",
    "note": "WooCommerce installed and configured. Please review."
}

// Or deny with a reason
{
    "status": "denied",
    "note": "This plugin conflicts with your current theme."
}

// Or mark as completed after the work is done
{
    "status": "completed",
    "note": "Changes are live. Please check the site."
}

The allowed statuses are: pending, approved, denied, and completed. Each status update records the handler's user ID and note in the database row.

List response format

// GET /wp-json/adminlocks/v1/portal-requests
[
    {
        "id": 42,
        "type": "plugin_install",
        "title": "Install WooCommerce",
        "description": "We need e-commerce for our new product line.",
        "requested_by": 5,
        "requested_email": "client@example.com",
        "status": "pending",
        "handler_id": null,
        "handler_note": null,
        "created_at": "2026-03-05 14:22:10"
    }
]

Cloud Portal

When connected to AdminLocks Cloud, the portal experience is enhanced with several features beyond the base WordPress integration.

Cloud portal route

Cloud provides a dedicated portal route at /portal that renders a streamlined interface with a reduced sidebar. This route is designed for client users who have been granted access to the Cloud dashboard with limited permissions.

Site membership scoping

In the Cloud portal, clients only see requests associated with the sites they are members of. This is enforced through the Cloud's site membership system, ensuring that agency clients cannot see requests from other clients even if they share the same Cloud organization.

Linked approvals

Portal requests in the Cloud are linked to Approval records through the ClientRequest model. When a portal request requires an action that is also gated by the Approval Gates system (e.g., a plugin install request), the Cloud can automatically create an associated Approval record. This means approving the portal request can also pre-approve the corresponding WordPress capability, creating a seamless workflow.