Download the PHP package clumsy/cms without Composer

On this page you can find all versions of the php package clumsy/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

Clumsy

A white-label CMS for Laravel

Latest Stable Version

Installing

Use Composer to install:

In the config/app.php file, add this to the providers key:

Optionally, you can set the following aliases:

Publish Clumsy configuration:

Run migrations to get the admin area's authentication tables and media management tables:

Finally, publish all Clumsy public assets:

Usage

Clumsy will create an admin area where its users can manage resources. Before you start adding resources and routes, it could be a good idea to make sure you have access to it. Ideally, if you have many users, you would create a seeder in which you would register them all at once. If you just want to get up and running for development, you can user the following:

You will be prompted for email, name, password and optionally a user level.

With a user of your own you can proceed to the admin area. By default this will be http://example.com/admin (you can configure this by editing the authentication-prefix in the config). After successful authentication, if you haven't yet defined a route which resolves the http://example.com/admin URL, you will see a simple message that reads: [Admin home] Clumsy is correctly set up.

Adding routes to that authenticated admin area is easy: whatever route that uses the clumsy middleware will automatically be managed by Clumsy.

Creating new resources

A resource that will be managed inside the admin area is basically an Eloquent model with some standard methods and properties. Most of the funcionalities which make up Clumsy are achieved by those model methods plus a standardized controller and a type of class which we call Panels. Because the Clumsy admin area can be customized entirely, all those classes inhabit your local app's folders and not the package's. Luckily there's an easy way to just create all those objects at once:

The resource name (post in this example) defines what the classes will be called. The above command will create the following:

(The above paths are based on default configuration. All object namespaces can be overridden so that the resource generator puts them in the correct place inside your local application.)

The command output will also give you the resourceful route. By now your routes\web.php might look like this:

Which means that, after running the newly created migration, you can go to http://example.com/admin/post and see the index for the post resource and from there create, update and delete entries.

Panels: customizing data and features

By default the admin panels have all features disabled. The index assumes you want to show all items, and that a title column exists and is all that can be viewed and edited. Of course this are just unassuming defaults and are meant to be easily extended or overridden. In order to achieve this, Clumsy relies on a object which we call a Panel, which can be thought of as an objectual representation of the view you want to render. The index of a resource is generated by an Index panel, the editing form is generated by an Edit panel and so on. Custom panels are located inside your app/Panels/{Resource} folder (unless overridden by config), where {Resource} is the actual studly case name of the resource you want to customize (e.g. app/Panels/Post).

Customizing views

Clumsy will prioritize your local application's views whenever they're available at your views/admin folder and fallback to its default templates. Clumsy's templates are small bits of code in Blade syntax, intentionally small so you can override them in a very granular manner.

Say you want to override the editing form of your post resource. Instead of overriding the entire page, you can just create a resources\views\admin\post\fields.blade.php and place your HTML inputs inside it. Clumsy will use them for the create and edit forms. If you want your create forms to be different from your edit forms, you can create a resources\views\admin\post\create\fields.blade.php which will be used only during creation.

Cascading view priority

Clumsy's ViewResolver will cascade through a series of folders and check for overriding view files before assuming they don't exist and use the defaults. As a general rule, the cascade includes a domain and an action. The domain is the slug of the resource, while the action relates to the current panel in view (index, edit, create, reorder). You can also have local templates which are common to many resources inside your admin area. So, for a given template while viewing the list of a resource named post, this is the order files it will run through to see if the main index view should be overridden:

If none of those files are found, Clumsy will make the same cascade (domain + action > domain > template) inside it's own templates folder.

For clarity's sake, say you want to add a button after the page title when editing a post resource. There's a template called after-title that's included especially for that purpose, and it could be located in any of these folders for Clumsy to use it instead of the default:

Domain-agnostic templates

An admin area can easily be built using Clumsy's controllers and views. But you could also choose to have your own controllers and views and not extend any of Clumsy, which is fine. For consistency's sake, though, it assumes the navbar will display even on those "stand-alone" pages which do not use Clumsy code, meaning the navbar is a domain-agnostic set of templates: if you want to customize it, place the overrides in the root of your views/admin folder. Here's a full list of domain-agnostic templates:

Available templates

Here's an exhastive list of the templates which Clumsy uses and which can be overridden:

Where [...] are the templates of a given panel currently in view, which extend the master template (unless otherwise noted):

Note that the templates also use Blade sections, so you can override certain templates without resorting to replacing each individual files, but rather by using Blade's native syntax. A combination of the two techniques should give developers an almost limitless array of possibilities to customize Clumsy's templates.

Overriding views natively in Laravel

Of course you can also override all Clumsy's views by resorting to Laravel's native vendor publishing. When placed inside your views/vendor folder, Clumsy's fallback templates will be loaded from there, having priority over the package's views. This is especially useful for views that don't get the cascading priority treatment, such as authentication templates.

In order to publish Clumsy views:

Legacy

Upgrading from 0.22


All versions of cms with dependencies

PHP Build Version
Package Version
Requires laravel/framework Version 5.3.*
laravelcollective/html Version 5.3.*
clumsy/assets Version 0.7.*
clumsy/utils Version 0.10.*
clumsy/eminem Version 0.14.*
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 clumsy/cms contains the following files

Loading the files please wait ....