Download the PHP package codelockpro/sdk without Composer
On this page you can find all versions of the php package codelockpro/sdk. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download codelockpro/sdk
More information about codelockpro/sdk
Files in codelockpro/sdk
Package sdk
Short Description Framework-agnostic, modular server-side SDK for CodeLockPro. Module one: Knowledge base. Pure library — no framework binding, no routing.
License proprietary
Homepage https://github.com/mbos01/codelockpro/tree/main/sdk/php#readme
Informations about the package sdk
codelockpro/sdk
Pure server-side, modular PHP SDK — the CodeLockPro client framework
on the server. Ships with the knowledge base as a built-in module and
includes portal/community module factories for forum operations;
additional modules plug into the same CodeLockPro instance through
the same registration surface.
Install
Source repository. This package is published to Packagist from a read-only subtree mirror at
mbos01/codelockpro-sdk-php. The canonical source lives inmbos01/codelockproundersdk/php/— open issues and PRs there.License. The SDK is proprietary and may only be used in combination with an active CodeLockPro account. See
LICENSE.
Architecture invariants
- Modular foundation. The core has no per-module coupling.
- Pure library. No framework binding (Laravel, Symfony, vanilla PHP — the developer wires the routes).
- Zero web-framework dependencies. Only
ext-curlandext-json.
Usage
$client->kb() is a convenience accessor for $client->module('kb').
The core has no KB-specific code path.
Registering more modules
Module author contract
A module factory is any callable(ModuleContext): object. The context
exposes:
$ctx->name— the registered name ("kb","checkout", …)$ctx->client— back-reference toCodeLockPro(userequest()for HTTP)$ctx->bus— shared event bus (on/off/emit)
Modules namespace their events as <ctx->name>.<event> so listeners
stay unambiguous when many modules are registered.
Knowledge base — module one
Mapped to the unified, secured KB REST surface (every call requires an
OAuth bearer carrying kb:read for reads and kb:write for writes;
view tracking is kb:read):
Each call returns the raw decoded JSON body as an associative array.
On a non-2xx response the client throws
CodeLockPro\CodeLockProApiException carrying the HTTP status and
response body.
Portal module (canonical)
Register the canonical portal module via the same module contract:
Community module (backward-compatible alias)
Register the community module via the same module contract:
Mapped to the upstream portal forum API surface:
Events emitted on the shared bus are namespaced with the registered module name:
community.thread.createdcommunity.post.createdcommunity.thread.flaggedcommunity.post.flagged
When registered as portal, event names are emitted as:
portal.thread.createdportal.post.createdportal.thread.flaggedportal.post.flagged
Migration (community → portal)
Legacy community naming is preserved for backward compatibility. New PHP integrations should use portal naming.
| Legacy | Canonical |
|---|---|
CodeLockPro\Modules\Community |
CodeLockPro\Modules\Portal |
$client->community() |
$client->portal() |
$client->register('community', ...) |
$client->register('portal', ...) |
Deprecation policy and timeline:
communitynaming remains fully supported in the current0.xline.portalnaming is the canonical path for all new integrations.- Any future removal of
communitynaming will happen only in a future major release, with migration notice published in advance.
Integrator migration checklist:
- PHP SDK: migrate registrations/accessors from
CodeLockPro\Modules\Communityand$client->community()toCodeLockPro\Modules\Portaland$client->portal(). - JS SDK parity: if your stack also uses JS, mirror the same naming
shift with
@codelockpro/sdk/portalandclient.portal(). - Events: prefer
portal.thread.created,portal.post.created,portal.thread.flagged,portal.post.flagged; keepcommunity.*listeners only until all integrations are migrated. - Routes/endpoints: use portal naming consistently for forum routes
(
/portal/*in proxy layers;/v1/portal/forum/*upstream).
All versions of sdk with dependencies
ext-curl Version *
ext-json Version *