Improving structure diagrams

backend-controllers-ajax.md

@@ -18,16 +18,18 @@ The Winter CMS backend implements the MVC pattern. Controllers manage backend pa
 
 Each controller consists of a PHP file which resides in the the **/controllers** subdirectory of a Plugin directory. Controller views are `.htm` files that reside in the controller view directory. The controller view directory name matches the controller class name written in lowercase. The view directory can also contain controller configuration files. An example of a controller directory structure:
 
-    plugins/
-      acme/
-        blog/
-          controllers/
-            users/                <=== Controller view directory
-              _partial.htm        <=== Controller partial file
-              config_form.yaml    <=== Controller config file
-              index.htm           <=== Controller view file
-            Users.php             <=== Controller class
-          Plugin.php
+```css
+📂 plugins
+ ┗ 📂 acme
+   ┗ 📂 blog
+     ┣ 📂 controllers
+     ┃ ┣ 📂 users                 <=== Controller view directory
+     ┃ ┃ ┣ 📜 _partial.htm        <=== Controller partial file
+     ┃ ┃ ┣ 📜 config_form.yaml    <=== Controller config file
+     ┃ ┃ ┗ 📜 index.htm           <=== Controller view file
+     ┃ ┗ 📜 Users.php             <=== Controller class
+     ┗ 📜 Plugin.php
+```
 
 <a name="class-definition"></a>
 ### Class definition
@@ -236,4 +238,4 @@ public function __construct()
         // Middleware functionality
     })->except('index');
 }
-```
+```

backend-forms.md

@@ -158,13 +158,15 @@ Option  | Description
 
 Form fields are defined with the YAML file. The form fields configuration is used by the form behavior for creating the form controls and binding them to the model fields. The file is placed to a subdirectory of the **models** directory of a plugin. The subdirectory name matches the model class name written in lowercase. The file name doesn't matter, but **fields.yaml** and **form_fields.yaml** are common names. Example form fields file location:
 
-    plugins/
-      acme/
-        blog/
-          models/            <=== Plugin models directory
-            post/            <=== Model configuration directory
-              fields.yaml    <=== Model form fields config file
-            Post.php         <=== model class
+```css
+📂 plugins
+ ┗ 📂 acme
+   ┗ 📂 blog
+     ┗ 📂 models             <=== Plugin models directory
+       ┣ 📂 post             <=== Model configuration directory
+       ┃ ┗ 📜 fields.yaml    <=== Model form fields config file
+       ┗ 📜 Post.php         <=== model class
+```
 
 Fields can be placed in three areas, the **outside area**, **primary tabs** or **secondary tabs**. The next example shows the typical contents of a form fields definition file.
 

backend-lists.md

@@ -143,13 +143,15 @@ The **filter** option should make reference to a [filter configuration file](#li
 
 List columns are defined with the YAML file. The column configuration is used by the list behavior for creating the record table and displaying model columns in the table cells. The file is placed to a subdirectory of the **models** directory of a plugin. The subdirectory name matches the model class name written in lowercase. The file name doesn't matter, but the **columns.yaml** and **list_columns.yaml** are common names. Example list columns file location:
 
-    plugins/
-      acme/
-        blog/
-          models/                  <=== Plugin models directory
-            post/                  <=== Model configuration directory
-              list_columns.yaml    <=== Model list columns config file
-            Post.php               <=== model class
+```css
+📂 plugins
+ ┗ 📂 acme
+   ┗ 📂 blog
+     ┗ 📂 models                   <=== Plugin models directory
+       ┣ 📂 post                   <=== Model configuration directory
+       ┃ ┗ 📜 list_columns.yaml    <=== Model list columns config file
+       ┗ 📜 Post.php               <=== model class
+```
 
 The next example shows the typical contents of a list column definitions file.
 

backend-widgets.md

@@ -24,16 +24,18 @@ Widgets are the backend equivalent of frontend [Components](../cms/components).
 
 Widget classes reside inside the **widgets** directory of the plugin directory. The directory name matches the name of the widget class written in lowercase. Widgets can supply assets and partials. An example widget directory structure looks like this:
 
-    widgets/
-      /form
-        /partials
-          _form.htm     <=== Widget partial file
-        /assets
-          /js
-            form.js     <=== Widget JavaScript file
-          /css
-            form.css    <=== Widget StyleSheet file
-      Form.php          <=== Widget class
+```css
+📂 widgets
+ ┣ 📂 form
+ ┃ ┣ 📂 partials
+ ┃ ┃ ┗ 📜 _form.htm     <=== Widget partial file
+ ┃ ┗ 📂 assets
+ ┃   ┣ 📂 js
+ ┃   ┃ ┗ 📜 form.js     <=== Widget JavaScript file
+ ┃   ┗ 📂 css
+ ┃     ┗ 📜 form.css    <=== Widget StyleSheet file
+ ┗ 📜 Form.php          <=== Widget class
+```
 
 <a name="generic-class-definition"></a>
 ### Class definition
@@ -132,16 +134,18 @@ With form widgets you can add new control types to the backend [forms](../backen
 
 Form Widget classes reside inside the **formwidgets** directory of the plugin directory. The directory name matches the name of the widget class written in lowercase. Widgets can supply assets and partials. An example form widget directory structure looks like this:
 
-    formwidgets/
-      /form
-        /partials
-          _form.htm     <=== Widget partial file
-        /assets
-          /js
-            form.js     <=== Widget JavaScript file
-          /css
-            form.css    <=== Widget StyleSheet file
-      Form.php          <=== Widget class
+```css
+📂 formwidgets
+ ┣ 📂 form
+ ┃ ┣ 📂 partials
+ ┃ ┃ ┗ 📜 _form.htm     <=== Widget partial file
+ ┃ ┗ 📂 assets
+ ┃   ┣ 📂 js
+ ┃   ┃ ┗ 📜 form.js     <=== Widget JavaScript file
+ ┃   ┗ 📂 css
+ ┃     ┗ 📜 form.css    <=== Widget StyleSheet file
+ ┗ 📜 Form.php          <=== Widget class
+```
 
 <a name="form-class-definition"></a>
 ### Class definition
@@ -301,14 +305,16 @@ Report widgets can be used on the backend dashboard and in other backend report
 
 The report widget classes should extend the `Backend\Classes\ReportWidgetBase` class. As any other plugin class, generic widget controllers should belong to the [plugin namespace](../plugin/registration#namespaces). The class should override the `render` method in order to render the widget itself. Similarly to all backend widgets, report widgets use partials and a special directory layout. Example directory layout:
 
-    plugins/
-      winter/                    <=== Author name
-        googleanalytics/          <=== Plugin name
-          reportwidgets/          <=== Report widgets directory
-            trafficsources        <=== Widget files directory
-              partials
-                _widget.htm
-            TrafficSources.php    <=== Widget class file
+```css
+📂 plugins
+ ┗ 📂 winter                      <=== Author name
+   ┗ 📂 googleanalytics           <=== Plugin name
+     ┗ 📂 reportwidgets           <=== Report widgets directory
+       ┣ 📂 trafficsources        <=== Widget files directory
+       ┃ ┗ 📂 partials
+       ┃   ┗ 📜 _widget.htm
+       ┗ 📜 TrafficSources.php    <=== Widget class file
+```
 
 Example report widget class definition:
 

cms-themes.md

@@ -32,39 +32,39 @@ Object | Description
 
 Below, you can see an example theme directory structure. Each Winter theme is represented with a separate directory and generally, one active theme is used for displaying the website. This example displays the "example-theme" theme directory.
 
-```
+```css
 📂 themes
- ┣ 📂 example-theme
- ┃ ┣ 📂 assets                <-- Theme assets
- ┃ ┃ ┣ 📂 css
- ┃ ┃ ┣ 📂 fonts
- ┃ ┃ ┣ 📂 images
- ┃ ┃ ┣ 📂 javascript
- ┃ ┃ ┣ 📂 scss
- ┃ ┃ ┗ 📂 vendor
- ┃ ┣ 📂 content               <-- Static content files
- ┃ ┃ ┗ 📂 static-pages        <-- Content files from the Winter.Pages plugin
- ┃ ┃ ┃ ┗ 📜 index.htm
- ┃ ┃ ┗ 📜 welcome.htm
- ┃ ┣ 📂 layouts               <-- Theme Layouts (Page scaffolds / templates)
- ┃ ┃ ┣ 📜 default.htm
- ┃ ┃ ┗ 📜 sidebar.htm
- ┃ ┣ 📂 meta                  <-- Menu definitions and other plugin specific YAML files
- ┃ ┃ ┣ 📂 menus
- ┃ ┃ ┃ ┣ 📜 main-menu.yaml
- ┃ ┃ ┃ ┗ 📜 sitemap.yaml      <-- Meta file describing the sitemap
- ┃ ┃ ┗ 📜 static-pages.yaml   <-- Meta file describing the structure of the Winter.Pages static pages
- ┃ ┣ 📂 pages                 <-- Theme Pages (Contain the routing for the frontend)
- ┃ ┃ ┣ 📜 404.htm             <-- Page for 404 responses
- ┃ ┃ ┣ 📜 home.htm
- ┃ ┃ ┣ 📜 error.htm           <-- Page for 500 responses
- ┃ ┃ ┗ 📜 sitemap.htm         <-- Page for rendering the sitemap response
- ┃ ┣ 📂 partials              <-- Theme Partials (Reusable pieces of HTML markup)
- ┃ ┃ ┣ 📜 html-footer.htm
- ┃ ┃ ┣ 📜 html-header.htm
- ┃ ┃ ┗ 📜 navbar.htm
- ┃ ┣ 📜 theme.yaml            <-- Theme information file
- ┃ ┗ 📜 version.yaml          <-- Theme updates file
+ ┗ 📂 example-theme
+   ┣ 📂 assets                <-- Theme assets
+   ┃ ┣ 📂 css
+   ┃ ┣ 📂 fonts
+   ┃ ┣ 📂 images
+   ┃ ┣ 📂 javascript
+   ┃ ┣ 📂 scss
+   ┃ ┗ 📂 vendor
+   ┣ 📂 content               <-- Static content files
+   ┃ ┣ 📂 static-pages        <-- Content files from the Winter.Pages plugin
+   ┃ ┃ ┗ 📜 index.htm
+   ┃ ┗ 📜 welcome.htm
+   ┣ 📂 layouts               <-- Theme Layouts (Page scaffolds / templates)
+   ┃ ┣ 📜 default.htm
+   ┃ ┗ 📜 sidebar.htm
+   ┣ 📂 meta                  <-- Menu definitions and other plugin specific YAML files
+   ┃ ┣ 📂 menus
+   ┃ ┃ ┣ 📜 main-menu.yaml
+   ┃ ┃ ┗ 📜 sitemap.yaml      <-- Meta file describing the sitemap
+   ┃ ┗ 📜 static-pages.yaml   <-- Meta file describing the structure of the Winter.Pages static pages
+   ┣ 📂 pages                 <-- Theme Pages (Contain the routing for the frontend)
+   ┃ ┣ 📜 404.htm             <-- Page for 404 responses
+   ┃ ┣ 📜 home.htm
+   ┃ ┣ 📜 error.htm           <-- Page for 500 responses
+   ┃ ┗ 📜 sitemap.htm         <-- Page for rendering the sitemap response
+   ┣ 📂 partials              <-- Theme Partials (Reusable pieces of HTML markup)
+   ┃ ┣ 📜 html-footer.htm
+   ┃ ┣ 📜 html-header.htm
+   ┃ ┗ 📜 navbar.htm
+   ┣ 📜 theme.yaml            <-- Theme information file
+   ┗ 📜 version.yaml          <-- Theme updates file
 ```
 
 > The active theme is set with the `activeTheme` parameter in the `config/cms.php` file or with the Theme Selector on the System > CMS > Frontend Theme backend page. The theme set with the Theme Selector overrides the value in the `config/cms.php` file.
@@ -74,22 +74,23 @@ Below, you can see an example theme directory structure. Each Winter theme is re
 
 Winter supports single level subdirectories for **pages**, **partials**, **layouts** and **content** files, while the **assets** directory can have any structure. This simplifies the organization of large websites. In the example directory structure below, you can see that the **pages** and **partials** directories contain the **blog** subdirectory, and the **content** directory contains the **home** subdirectory.
 
-    themes/
-      website/
-        pages/
-          home.htm
-          blog/                  <=== Subdirectory
-            archive.htm
-            category.htm
-        partials/
-          sidebar.htm
-          blog/                  <=== Subdirectory
-            category-list.htm
-        content/
-          footer-contacts.txt
-          home/                  <=== Subdirectory
-            intro.htm
-        ...
+```css
+📂 themes
+ ┗ 📂 website
+   ┣ 📂 pages
+   ┃ ┣ 📜home.htm
+   ┃ ┗ 📂 blog                  <=== Subdirectory
+   ┃   ┣ 📜 archive.htm
+   ┃   ┗ 📜 category.htm
+   ┣ 📂 partials
+   ┃ ┣ 📜 sidebar.htm
+   ┃ ┗ 📂 blog                  <=== Subdirectory
+   ┃   ┗ 📜 category-list.htm
+   ┗ 📂 content
+     ┣ 📜 footer-contacts.txt
+     ┗ 📂 home                  <=== Subdirectory
+       ┗ 📜 intro.htm
+```
 
 To refer to a partial or a content file from a subdirectory, specify the subdirectory's name before the template's name. Example of rendering a partial from a subdirectory:
 

database-model.md

@@ -25,15 +25,17 @@ Winter provides a beautiful and simple Active Record implementation for working
 
 Model classes reside in the **models** subdirectory of a plugin directory. An example of a model directory structure:
 
-    plugins/
-      acme/
-        blog/
-          models/
-            user/             <=== Model config directory
-              columns.yaml    <=== Model config files
-              fields.yaml     <==^
-            User.php          <=== Model class
-          Plugin.php
+```css
+📂 plugins
+ ┗ 📂 acme
+   ┗ 📂 blog
+     ┣ 📂 models
+     ┃ ┣ 📂 user              <=== Model config directory
+     ┃ ┃ ┣ 📜 columns.yaml    <=== Model config files
+     ┃ ┃ ┗ 📜 fields.yaml     <==^
+     ┃ ┗ 📜 User.php          <=== Model class
+     ┗ 📜 Plugin.php
+```
 
 The model configuration directory could contain the model's [list column](../backend/lists#list-columns) and [form field](../backend/forms#form-fields) definitions. The model configuration directory name matches the model class name written in lowercase.
 

plugin-components.md

@@ -24,14 +24,16 @@
 
 Components files and directories reside in the **/components** subdirectory of a plugin directory. Each component has a PHP file defining the component class and an optional component partials directory. The component partials directory name matches the component class name written in lowercase. An example of a component directory structure:
 
-    plugins/
-      acme/
-        myplugin/
-          components/
-            componentname/       <=== Component partials directory
-              default.htm        <=== Component default markup (optional)
-            ComponentName.php    <=== Component class file
-          Plugin.php
+```css
+📂 plugins
+ ┗ 📂 acme
+   ┗ 📂 myplugin
+     ┣ 📂 components
+     ┃ ┣ 📂 componentname        <=== Component partials directory
+     ┃ ┃ ┗ 📜 default.htm        <=== Component default markup (optional)
+     ┃ ┗ 📜 ComponentName.php    <=== Component class file
+     ┗ 📜 Plugin.php
+```
 
 Components must be [registered in the Plugin registration class](#component-registration) with the `registerComponents` method.
 

plugin-localization.md

@@ -13,15 +13,16 @@ Plugins can have localization files in the **lang** subdirectory of the plugin d
 
 Below is an example of the plugin's lang directory:
 
-    plugins/
-      acme/
-        todo/             <=== Plugin directory
-          lang/           <=== Localization directory
-            en/           <=== Language directory
-              lang.php    <=== Localization file
-            fr/
-              lang.php
-
+```css
+📂 plugins
+ ┗ 📂 acme
+   ┗ 📂 todo              <=== Plugin directory
+     ┗ 📂 lang            <=== Localization directory
+       ┣ 📂 en            <=== Language directory
+       ┃ ┗ 📜 lang.php    <=== Localization file
+       ┗ 📂 fr
+         ┗ 📜 lang.php
+```
 
 The **lang.php** file should define and return an array of any depth, for example:
 
@@ -55,11 +56,13 @@ The localization strings can be loaded with the `Lang` class. The parameter it a
 
 System users can override plugin localization strings without altering the plugins' files. This is done by adding localization files to the **lang** directory. For example, to override the lang.php file of the **acme/blog** plugin you should create the file in the following location:
 
-    lang/               <=== App localization directory
-      en/               <=== Language directory
-        acme/           <=== Plugin / Module directory
-          blog/         <===^
-            lang.php    <=== Localization override file
+```css
+📂 lang                 <=== App localization directory
+ ┗ 📂 en                <=== Language directory
+   ┗ 📂 acme            <=== Plugin / Module directory
+     ┗ 📂 blog          <===^
+       ┗ 📜 lang.php    <=== Localization override file
+```
 
 The file could contain only strings you want to override, there is no need to replace the entire file. Example: