Orchid CMS - another CMS on Laravel

Yes, yes, yes, you read everything correctly, another content management system, you can immediately get a brick and go to the comments by burning your torch.

When I first wrote the first articles on the slim framework, many people in the comments on Habré advised me to try Laravel, which I immediately thought was done. To say that I liked him, to say nothing. But since I worked in the development of sites where speed was required, it was difficult to find a justifiable argument to use it, the only solution was to create an administration package in my spare time, which would allow using my favorite technologies.

At the beginning

The first thing I did was abandon the CMS-specific solutions like: “Themes,” “Plugins” and “Routing Control”. Just let us go straight to cleanliness, not so often the work site needs a change of design, and the plugin one way or another should be put by the developer, to whom the composer will be nicer. There is no template editor or other parameters either, since in reality it conflicts with the version control system.
')

Highlights

First of all, a scheme was developed whereby each developer could make some changes in the logic or extend it. We had to think long enough, because the ideal variant probably does not exist, and an approach was chosen where a form is first created that has tabs, each such tab is independent, it has no idea that there is a different one and when the form is sent, the data comes in each tab. Thus, everyone can create arbitrarily these tabs, adding more and more parameters to the form.

For example, we have a user form, where two tabs with general information and access rights are specified by default, by adding new forms (registered using events) we can expand and add various information, while in the code you will see only the form view and the action to be done with the resulting model. This approach allows you to expand the already standard tabs and more clearly adapt to the necessary needs.

An example of a form that can be expanded



The field of this had to start thinking about how to store data. Reflecting on the structure, it was difficult not to notice that on most of the sites (which the company developed), the data on the structure were very similar, and sometimes translation storage was required. This gave me a reason to think about the EAV format, but the answer to the question how to store, I found the developers from the neighboring department, they used non-relational databases for mobile applications. Transferring it to MySQL and PostgreSQL, the system has already used the JSON type for data storage, continuing the issue of storage and ease of use, reproduced the wordpress structure, that is, created a table of records, and the data was stored in it in JSON format. For carrying out the manipulations, a separate field denoting its type was used. With which, you could manage the recording itself.

That is, the developer needed to describe the fields that he would like to display for editing and in what form, and the form to build itself. You can also specify the validation, or modules, modules - these are the forms I described above.

Record control example

namespace DummyNamespace; use Orchid\Behaviors\Many; class DummyClass extends Many { /** * @var string */ public $name = ''; /** * @var string */ public $slug = ''; /** * @var string */ public $icon = ''; /** * Slug url /news/{name}. * @var string */ public $slugFields = ''; /** * Rules Validation. * @return array */ public function rules() { return []; } /** * @return array */ public function fields() { return []; } /** * Grid View for post type. */ public function grid() { return []; } /** * @return array */ public function modules() { return []; } } 

Fields and behaviors are specified separately, which allows you to use only a key, for example, in a record we want a wysing editor, and the value will be a class. This allows you to change the editor from summernote to tinymce or ckeditor in almost one click.

 'types' => [ App\Core\Behaviors\Many\DemoPost::class, ], 'fields' => [ 'textarea' => Orchid\Fields\TextAreaField::class, 'input' => Orchid\Fields\InputField::class, 'tags' => Orchid\Fields\TagsField::class, 'robot' => Orchid\Fields\RobotField::class, 'place' => Orchid\Fields\PlaceField::class, 'datetime' => Orchid\Fields\DateTimerField::class, 'checkbox' => Orchid\Fields\CheckBoxField::class, 'path' => Orchid\Fields\PathField::class, 'code' => Orchid\Fields\CodeField::class, 'wysiwyg' => \Orchid\Fields\SummernoteField::class, ], 

Using these solutions, a developer can literally build a CRUD in minutes, for a variety of data types, and changing it by adding new parameters requires only adding new values ​​in their description.

Example of the form for adding a record



A separate moment concerning the design, at the beginning of development, and most likely even now, almost every administration panel used AdminLTE , I don’t want to say that it is bad or something else, but honestly - she was tired of talking to the designer about the price, I realized that is not my option. The only way out was the network, then I went to look for beautiful PSD layouts, and found the Dashboard60 UI Kit , having bought it, I began to not accurately or even roughly reproduce the main points (What would not get over the ears).

At this stage, all the "uniqueness" ends, and standard things begin:

• Role Based Permissions
• Widgets
• Tagging
• File upload
• Menu
• Settings

Total

To sum up, the system will be interesting only to those who have already worked with Laravel and want to make “simple websites” with a quick start with it, this can be seen even at the installation stage, which differs from many other similar applications that make their starter package for deployment, Orchid also comes as a package, that is, you first need to deploy the framework itself and after adding the package depending.

All code is published on github.com .