WP Manifestindependent plugin directory
manifest / users / client-access-portal

Client Access Portal

Core platform plugin for secure client portals, provider-backed file access, and client workflow management.

by Nic Scott · github.com/nicscott01/client-access-portal

★ 0stars
0forks

Install

No release zip yet. The repository archive installs, but the folder name will carry the branch suffix and updates will not flow:

wp plugin install https://github.com/nicscott01/client-access-portal/archive/refs/heads/main.zip
Readme github.com/nicscott01/client-access-portal ↗

Core WordPress plugin for managing client records, linking client contacts to WordPress users, collecting staff/client notes, and exposing a secure frontend portal backed by pluggable file-storage providers.

What It Does

  • Adds a Client Access Portal admin area for managing clients
  • Stores client records, client contacts, notes, and provider links in custom tables
  • Lets staff assign a primary file-storage provider per client
  • Exposes a frontend portal via the [client_access_portal] shortcode
  • Lets logged-in client contacts:
    • switch between linked clients
    • view approved files from the assigned provider
    • upload files for review, including large direct-to-provider uploads when supported
    • add and edit file notes/captions
    • submit portal notes
  • Includes frontend compatibility hooks for Breakdance button/form classes

Current Admin Areas

  • Client Access Portal > All Clients
  • Client Access Portal > Add New
  • Client Access Portal > Settings

Client edit screens include:

  • core client/contact details
  • notes
  • provider selection
  • file storage links / quick access links when supported by the provider

Frontend Portal

Render the portal on a WordPress page with:

[client_access_portal]

By default, the plugin expects the portal page slug to be my-portal. That can be changed in the plugin settings.

Settings

Core settings currently include:

  • portal slug
  • max upload size
  • blocked file extensions
  • upload and file-access rate limits
  • notification/from email fields
  • welcome email subject/body

Upload Behavior

Frontend uploads can use provider-backed direct upload sessions when the assigned storage provider supports them. In that flow, WordPress creates the provider upload session and finalizes the completed upload, while the browser transfers the file body directly to the provider. This avoids WordPress and the web server receiving the large request body while keeping the portal in control of client authorization, upload policy checks, provider routing, database records, and notifications.

Direct provider uploads are used for files of 8 MB or larger by default. The threshold can be adjusted with the client_access_portal_direct_upload_min_size filter.

Providers that do not support direct upload sessions can still use the existing chunked AJAX upload path. Frontend uploads larger than the configured chunk size are split into smaller AJAX requests before being assembled by the portal.

The upload form includes a progress indicator while the file is transferred, then switches to a finalizing or processing state while the portal completes the upload record.

The default chunk size is 512 KB. It can be adjusted with the client_access_portal_upload_chunk_size filter when a hosting stack supports larger request bodies.

Provider Architecture

Storage providers register through the core provider registry via:

do_action( 'client_access_portal_register_providers', $provider_registry );

The provider contract lives at src/Contracts/StorageProvider.php.

Breakdance Integration

When Breakdance is active, the frontend portal can append Breakdance-style classes to buttons and form elements so the portal inherits the site’s existing form/button styling more cleanly.

Available frontend class filters include:

  • client_access_portal_frontend_button_classes
  • client_access_portal_frontend_form_classes
  • client_access_portal_frontend_form_field_classes
  • client_access_portal_frontend_form_label_classes
  • client_access_portal_frontend_form_input_classes
  • client_access_portal_frontend_form_footer_classes

Requirements

  • WordPress 6.0+
  • PHP 8.0+

Changelog

0.1.9

  • Constrained Breakdance form fields and portal panels so upload controls stay within the mobile portal card.

0.1.8

  • Set a minimum visible width for the upload progress container to avoid collapsed progress bars on iOS.

0.1.7

  • Fixed direct-upload finalization token handling so production retries can verify the original upload session.

0.1.6

  • Extended direct-upload finalization retries to allow more time for Google Drive metadata visibility.
  • Reworked the upload progress markup to use an explicit track/fill element for browser compatibility.

0.1.5

  • Added upload progress feedback for small-file PHP uploads.
  • Improved direct-upload finalization when browsers cannot read Google's successful CORS-blocked upload response.
  • Disabled the upload button until a file is selected.
  • Widened the upload progress display and prevented progress labels from wrapping.

0.1.4

  • Added direct browser-to-provider upload support for large files when the assigned storage provider supports direct upload sessions.
  • Kept small uploads on the normal PHP upload path so short videos and images do not use tiny chunks unnecessarily.
  • Added a client_access_portal_direct_upload_min_size filter for tuning the direct-upload threshold.

0.1.3

  • Reduced the default upload chunk size to 512 KB to stay below 1 MB request-body ceilings after multipart overhead.

0.1.2

  • Reduced the default upload chunk size to 1 MB for mobile and stricter request-body limits.
  • Added a client_access_portal_upload_chunk_size filter for host-specific tuning.

0.1.1

  • Added chunked frontend uploads for larger portal files.
  • Added upload progress feedback in the frontend portal.
  • Added server-side chunk validation and assembly safeguards.