Live CockpitCMS+Svelte Projects:
2. CockpitCMS Administration
Why CockpitCMS
The essence of administration through CockpitCMS should be speed, simplicity, clarity for the administrator (or editor) and at the same time a feeling of omnipotence for the developer.
CockpitCMS is the ideal solution (with the exception of documentation), because it allows complete configurability and extensibility for the developer.
Alternative solutions like WordPress have greater support coverage, but at the same time very low flexibility for the modern era of web presentations, because to achieve the ideal design impression it is often necessary to make compromises not only from the developer's perspective, but also the editor's.
WordPress has its place among blogs and simple classic websites, not modern design presentations.
Why Svelte?
For the front-end, a JavaScript variant was chosen instead of SSR solutions like various PHP frameworks (e.g. Laravel) due to increased development speed (lack of knowledge of PHP frameworks), code uniformity (everything public goes through Svelte with uniform syntax, Laravel has diverse content separation) and simple extensibility (creating a new component and connecting to the API is a matter of 5 minutes to maximum half an hour).
Among front-end frameworks, Svelte is the fastest and simplest option compared to monolithic React or the more modern but somewhat syntactically more complicated Vue (originally the concept of this very project was done in Vue and several reasons (syntax and speed) led me to 100% migration to Svelte).
For the editor
Main interface
 |
|---|
| The first (and main) part the editor sees - general administration navigation, i.e. list of structures |
A user in the Editor group is immediately after login thrown into the list of structures that define the website, of which the most essential are Pages. Additionally, they have quick access to a unit of general Website Settings.
 |
|---|
| List of pages (after clicking Pages in the list of structures) |
Besides the ability to edit a few clear structures, they can access and organize media, or edit a few details of their account. Nothing more, nothing less, the essence is simplicity, so that the editor doesn't feel overwhelmed.
Page editing
After selecting the pages structure from the main interface, they have access to individual pages, where they can clearly see their publication status, access subaddress (slug) and of course, their name.
 |
|---|
| Individual fields from which the editing of a specific page for the editor is composed. Components play the main role (yellow color). |
After opening, the editor has the option to fill in all necessary or unnecessary fields and thus construct some idea of the future page. The option of localization into different languages is also available.
The main part is the area for adding components, which is not only the place where the editor will spend the most time, but also the place that the developer most often customizes and modifies.
 |
|---|
| After clicking the big plus, just select the appropriate component. |
Individual components can be sorted, rearranged and most importantly clicked open for editing editor-essential parts. Styling details or adherence to some design code is therefore technically guaranteed, since the modification of these options only reaches to a certain extent.
 |
|---|
| A specific component can be easily edited by clicking, all fields have understandable labels and uniform display within the administration, and are also precisely defined in the background. This definition is also reflected in the page API. |
Live preview
In addition to breaking down elements and their values, the editor has the option to view them directly via live preview by clicking the eye. Changes in the preview are reflected almost immediately, it is a perfect way to view any presentation and thanks to publication management long before it will even be published.
 |
|---|
| All components are editable just as in the full-screen layout here as well. |
As the cherry on top are buttons for adjusting the display according to device type, so that the editor can really trust that the presentation looks perfect on any device.
For the developer
If a CockpitCMS user has an account in the Admin group, hidden options for CMS modifications, add-ons, pages, hidden structures, field modifications, field types (field-types), labels and settings for all structures are displayed.
 |
|---|
| Main administration. A number of hidden corners for figuring out the ideal editing layout. |
Unused capabilities such as creating regions or forms, which may eventually come in handy, are hidden from the editor to maintain simplicity.
 |
|---|
System menu that appears after clicking the logo. For the editor, the logo simply redirects to the list of structures, admin however has various options, one of them is also to play with the GraphQL API extension for custom implementations. |
 |
|---|
The special Layout-Components add-on allows you to directly define individual components within the CMS, which will be implemented via Svelte. This add-on has been manually modified with additional icon support and better display of summary information during definition. |
 |
|---|
| All fields are arranged exactly as they will be accessible to the editor. Each also has a settings button for assigning labels, groups, additional options, type, etc. |
Previous: 1. Folder Hierarchy
Next: 3. Backend parts of CockpitCMS