Vision

Every small website is built by a developer and an agent together, is owned by the client, and runs on hosting the client can afford.

The manifesto explains why. This page explains how MelaCMS is designed to get there, where it stands today, and what comes next.

Principles

These rules shape every part of the core. When a feature does not fit them, it does not go in.

The site is code, the core is a dependency

A MelaCMS site is a normal Laravel app in its own repository. The core arrives through Composer and lives in vendor/, where nobody edits it. Everything specific to the site, such as its models, admin screens, views, routes and theme, is in the site's repository.

What every site needs is in the core, and what differs is in the site

If a feature works the same on every site, the core provides it: roles, languages, settings, media, pages, SEO. If it differs from site to site, the core gives a building block for it, such as a trait, a form field or a base class, and the site writes the rest.

Every core screen can be replaced

A site can never edit vendor/, so every screen the core adds is named in the config. A site can extend it, replace it with its own class, or switch it off.

The site owns its files

The installer copies the workflow files into the site, and from then on they belong to the site. An update never overwrites a file the site changed without asking first, and it asks only when the core really changed that template.

One way to do each thing

There is one media library, one settings store, and one way to translate content: JSON columns. An agent should not have to choose between three plugins that do the same thing. Neither should you.

Fast on a cheap host

Each kind of content gets its own table with real columns, translations stay in the same row, and nothing runs on a request that the site did not ask for. A site should stay fast on shared hosting as its content grows, without a cache layer added to rescue it.

Agent instructions are tested

The instructions the core gives to agents are part of the product. The guide for adding an entity is run by the core's test suite, and every class it names must exist. If the behaviour changes, the guide changes in the same pull request.

Updates are boring

One command updates the core, applies its migrations, refreshes the agent instructions and asks about the templates that changed. CI then checks that nothing was forgotten. A release ships the update like any other fix.

Content belongs to the client, structure belongs to the repository

Editors write pages, upload files and change settings in the panel. Everything that decides how the site works is in git, reviewed and tested.

Where MelaCMS stands

MelaCMS is at 0.8.1. The backbone is done and in use on a live site:

• install, update and the release and deploy workflows,
• the admin panel, users and roles,
• languages with translated addresses,
• settings, the media library, pages, SEO and the sitemap,
• the agent instructions and the entity guide.

The package is open source and published on Packagist, so it installs with a plain composer require.

What comes next

Planned:

• The core's own labels in the admin language. Filament's texts already follow the language chosen for the panel. The labels the core adds are English only for now.

Being considered, not decided:

• A deploy for hosts without SSH. The current deploy needs SSH access to the server.
• Atomic deploys with a rollback. Today the deploy copies over the live directory, so files removed from the repository stay on the server.
• A starter project, to create a site with one composer create-project command.
• Static analysis in the core's CI.

Known limits of the current features are listed in each chapter of the guide.

Read the manifesto → · Get started →