Limitations of Zero CMS

Every engineering choice is a compromise. Zero CMS is optimized for speed, security, and zero-dependency longevity. However, these optimizations impose strict boundaries. This page details the limitations and constraints of Zero CMS so developers can make informed architectural decisions.

Because Zero CMS rejects 100% of third-party runtime PHP packages, you cannot resolve problems by simply running composer require some/library. (Composer itself is only ever used to install Zero CMS Core into a host project as a versioned package -- see bin/create-project -- never to pull in third-party runtime dependencies.) For example:

• OAuth/Social Login: Must be written manually with raw curl or curl-free PHP sockets and manual crypto signature verification.
• Payment Gateways: Integrations (e.g. Stripe, PayPal) require writing direct HTTP API requests, parsing responses, and checking signatures natively.
• Image Manipulation: Restricted to PHP's native GD or Imagick extensions without modern wrapper libraries.

Unlike WordPress, Laravel, or Drupal, there is no community marketplace for pre-built plugins, themes, or widgets. If a project requires a complex feature (such as portfolios, advanced SEO analyzers, or newsletters), the developer must implement the models, controllers, and views from scratch inside self-contained modules.

Zero CMS isolates multiple discrete site tenants inside a unified single database using time-ordered UUIDv7 and schema scoping (site_id). While this eliminates multiple database connection overheads and allows unified server maintenance, it means all tenants share the same database server resource pool. Under extreme high-throughput loads, resource contention (CPU, disk I/O, or connection limits) can degrade performance across all tenants.

The framework avoids heavy ORM dynamic abstraction layers (like Eloquent or Hibernate) in favor of lightweight Active Record traits (IsModel). This means there is no automated schema diffing generator or database-agnostic migration DSL. Schemas are updated using pure SQL, meaning migrations must be hand-written and aligned strictly with the database engine (MySQL/MariaDB).

Historically, the major argument against zero-dependency engineering was development velocity. Writing raw socket handlers, custom template engines, and direct SQL migrations by hand takes significant time. However, in the era of advanced AI, this bottleneck is completely eliminated.

By pairing zero-dependency philosophy with high-performance AI models like Gemini, developers can generate bespoke, secure, and production-ready code blocks instantly. Whether you need a raw PHP payment integration signature checker, a custom MIME email builder over TCP, or a precise SQL migration, Gemini generates highly optimized, custom solutions on demand.

This paradigm gives developers the best of both worlds: the absolute speed and permanent lifecycle security of a 100% zero-dependency framework, coupled with the rapid prototyping speed of an AI copilot. As a testament to this power, the entire Zero CMS framework itself—including multi-tenant routing, custom block-builders, full-featured Luxe e-commerce carts, and automated database seeders—was engineered, validated, and seeded from scratch in less than a week!