aimeos / pagible-graphql
Pagible CMS - GraphQL API
Requires
- php: ^8.2
- aimeos/laravel-analytics-bridge: ~1.0
- aimeos/pagible-core: 0.12.*
- mll-lab/graphql-php-scalars: ^6.4
- nuwave/lighthouse: ^6.54
Requires (Dev)
- orchestra/testbench: ^9.0||^10.0||^11.0
This package is auto-updated.
Last update: 2026-08-08 09:34:32 UTC
README
GraphQL API for Pagible CMS built on Lighthouse. Provides full CRUD for pages, elements, files, and metrics.
This package is part of the Pagible CMS monorepo. For full installation, use:
composer require aimeos/pagible
Configuration
GraphQL-specific configuration is available in config/cms/graphql.php:
| Option | Env Variable | Default | Description |
|---|---|---|---|
maxdepth |
CMS_GRAPHQL_MAXDEPTH |
15 |
Maximum query nesting depth |
maxcomplexity |
CMS_GRAPHQL_MAXCOMPLEXITY |
10000 |
Maximum query complexity score |
The upload policy is shared by every CMS interface and configured through upload.filesize and upload.mimetypes in config/cms.php.
Page access
The Page.restricted field tells page viewers whether immediate frontend access rules exist without exposing their values. Page.access requires page:access and represents the rules independently from page versions:
nullmeans public access- an empty list permits authenticated users of the current tenant
- a non-empty list permits users granted any listed access value
Users with page:access can replace this state with setPageAccess(id:, access:, descendants:). The nullable access argument must be provided explicitly. Multiple selected page IDs are supported; recursive changes are limited to one root page. Page bulk operations are limited to 1,000 unique pages, and recursive calls fail before writing if the resolved subtree exceeds 1,000 pages. Query.access lists catalog names for both the general catalog screen and page access controls, so it accepts either access:view or page:access. Without arguments it returns the complete bounded catalog; callers can provide term and first for autocomplete searches. The permissions remain registered in separate namespaces.
The admin access route and navigation require access:view. Within its Users tab, user creation, frontend access, and CMS editor permissions remain independent capabilities:
createUser(email:)requiresuser:create. It creates a user through the active Eloquent authentication provider with a hashed random password, the email as the internal name fallback, and no frontend access or CMS permissions. Existing emails are rejected rather than modified, and the createdCmsUserDatacan be used without another lookup.cmsUser(email:)performs one exact normalized email lookup and returns the narrowCmsUserDataprojection, including an opaque ID for subsequent writes. The query accepts eitheruser:accessoruser:permission; itsaccessandpermissionsfields enforce those capabilities independently.setUserAccess(id:, access:)requiresuser:accessand atomically replaces direct frontend values supported by the configured access adapter.permissionsreturns configured CMS role names and registered permission names, whilesetUserPermissions(id:, permissions:)atomically replaces the rawcmspermsentries. Both requireuser:permission; this is a super-admin capability that permits assigning any configured role or permission, including to the current user. Supported role, permission, wildcard, and deny values are validated before writing.
All user-specific operations resolve users through the configured authentication provider and apply Tenancy::allows() before disclosure or change. Missing and foreign-tenant users are indistinguishable. CmsUserData exposes only an opaque ID, the email, and independently protected authorization assignments; clients must treat the ID as opaque and use it instead of the mutable email for assignment writes. CmsUser remains the authenticated-user projection returned by me, and the application's standard User GraphQL type is not extended. The generated password is never returned, so applications need a password-reset or invitation flow before password login. Successful creation and assignment replacement emit the structured UserChanged audit event; the built-in watch listener records it as cms.user with actor, target, tenant, and resulting assignments.
Commands
cms:install:graphql
Installs the Pagible GraphQL package.
php artisan cms:install:graphql
Publishes the Lighthouse schema and configuration, registers CMS models/mutations/queries in the Lighthouse config, and adds the CMS schema import to graphql/schema.graphql.
cms:benchmark:graphql
Runs GraphQL mutation and query benchmarks.
php artisan cms:benchmark:graphql [options]
| Option | Default | Description |
|---|---|---|
--tenant |
benchmark |
Tenant ID |
--domain |
Domain name | |
--seed |
Seed benchmark data first | |
--pages |
10000 |
Number of pages to generate |
--tries |
100 |
Iterations per benchmark |
--chunk |
50 |
Rows per bulk insert batch |
--unseed |
Remove benchmark data and exit | |
--force |
Run in production |
License
MIT