Download the PHP package phlo/cms without Composer

On this page you can find all versions of the php package phlo/cms. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Informations about the package cms

Phlo CMS

Reusable CRUD and admin layer for the Phlo framework. Define a model schema and get list, record, create and edit views, a JSON REST API, dashboard widgets, a layout and a set of themes out of the box.

Phlo CMS lives in the application layer of the Phlo platform: the same .phlo language and resource model as your app, mounted as a resource path through Composer. The Phlo Dashboard is built on it.

See it running in the Phlo CMS demo, a complete blog with a committed dataset.

Features

Requirements

Install

Wire it into your Phlo app config (data/app.json):

  1. Add "%app/vendor/phlo/cms/" to paths.resources.
  2. List the CMS resources you use (for example CMS, CMS.layout, CMS.list, CMS.API, widgets/bar) in resources.
  3. Set "icons" to "%app/vendor/phlo/cms/icons/".

The action buttons in the record, create and change views call button(), and async forms (file/image uploads included) rely on the form submit handler, so the host app must also list tags.form and DOM/form in resources.

Interface text

The fixed interface text — the nav, the list and record/edit actions, and the empty and not-found states — renders through phlo's en() translation helper (the {en: ...} view shorthand, or en('...') in code), with English as the source language. The host app must therefore make an en() function available, in one of two ways:

Keep that on one line: phlo compiles a line that starts with function as an unconditional resource function (which would clash with lang's own en()), and PHP needs the braces to allow a function declaration inside the if. When lang is loaded it declares en() first, so the guard becomes a no-op and translation takes over.

Without either, the views raise Call to undefined function en() on the first render.

app.example.phlo is a minimal host app with the passthrough already in place; copy it to your app root as app.phlo and adapt.

Optional field styling

The base markup tags every rendered field with its view and type, e.g. class="label datetime" or class="input image" (see CMS::field()). The default look leaves those untouched, so nothing changes unless you opt in.

For a more polished record/edit view, add the per-type styling resources you want under styles/ to your resources list. They are theme-variable based, so they follow whichever theme is active:

Resource Effect
styles/bool Checkbox rendered as a toggle switch
styles/image Centered, clickable image preview
styles/file File row with icon, hidden native input
styles/datetime Freshness clock icon aligned with the timestamp
styles/number Right-aligned values and inputs
styles/child Scrollable list of linked child records
styles/many Wrapped list of linked records
styles/multiselect Chosen values rendered as pills
styles/wysiwyg Framed editor with a toolbar

These live in a subdirectory, so they are never auto-loaded; list only the ones you want. Your own field markup and styling keep working unchanged whether or not you opt in.

View or edit on click

By default a click in a list opens the record in view mode (with an Edit button). To open records straight in edit mode (/change/...) instead, set recordMode:

Values are 'view' (default) or 'edit'. The view route stays reachable either way (e.g. for child drill-down); only the default click target changes.

Defining a model

A model is a Phlo class (usually extends model) with a static schema() returning field() definitions. Everything else is optional and overrides a sensible default.

Schema and fields

Common field options: title, required, length, default, placeholder, search (adds the field to the list search box), prefix/suffix, and per-view visibility list / record / create / change (set to false to hide, or to 'label'/'input' to force a renderer). Relations use obj (target model); many also takes table (pivot), parent/child accept an explicit key.

create:false / change:false hide a field from that form and stop it being written from a posted payload, so they double as write-protection (a field with its own parse(), like created/token, still manages itself server-side). handle: true marks a field that must run on every save and on any single-field PATCH (used by date/datetime to auto-stamp created/changed); set it on a field whose value the model derives rather than the form.

Model statics

Static Purpose
$table Database table name
$order Default ORDER BY clause
$pp Rows per page (default 20)
$uriList / $uriRecord URL segments for the list / record (default: table / class)
$titleList / $titleRecord Display titles
canCreate / canChange / canDelete Permission flags or methods (canChange($record))
$recordMode 'view' (default) or 'edit', see above
$recordView / $listView / … Load a CMS.<mode>.<variant> layout variant instead of the default

List and dashboard hooks

These carry the obj prefix on purpose. A model extends model, whose magic accessor also exposes data columns, so anything the framework reads generically across every model lives in the reserved obj* namespace to guarantee it never collides with a column (objFilters, objSorts, objWidgets, alongside the ORM's objParents / objChildren / objValidate). The plain-named statics above (canCreate, uriList, titleList, recordMode, order, pp) are simple per-model config values, not column-shaped, so they stay unprefixed. Each obj* hook may be a static property or a static method: the framework accepts either.

Lifecycle hooks

Define any of these instance methods on the model to run logic around writes: beforeSave / afterSave, beforeCreate / afterCreate, beforeChange($old) / afterChange($old), beforeDelete / afterDelete.

License

MIT. See LICENSE.


All versions of cms with dependencies

PHP Build Version
Package Version
Requires php Version >=8.3
phlo/tech Version ^1.0
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package phlo/cms contains the following files

Loading the files please wait ...