wintercms · LukeTowers · Jan 4, 2022 · Jan 4, 2022 · Jan 4, 2022 · Jan 4, 2022
diff --git a/help-unit-testing.md b/help-unit-testing.md
@@ -12,82 +12,90 @@ Individual plugin test cases can be run by running [the `winter:test` command](.
 
 Plugins can be tested by creating a file called `phpunit.xml` in the base directory with the following content, for example, in a file **/plugins/acme/blog/phpunit.xml**:
 
-    <?xml version="1.0" encoding="UTF-8"?>
-    <phpunit backupGlobals="false"
-             backupStaticAttributes="false"
-             bootstrap="../../../tests/bootstrap.php"
-             colors="true"
-             convertErrorsToExceptions="true"
-             convertNoticesToExceptions="true"
-             convertWarningsToExceptions="true"
-             processIsolation="false"
-             stopOnFailure="false"
-    >
-        <testsuites>
-            <testsuite name="Plugin Unit Test Suite">
-                <directory>./tests</directory>
-            </testsuite>
-        </testsuites>
-        <php>
-            <env name="APP_ENV" value="testing"/>
-            <env name="CACHE_DRIVER" value="array"/>
-            <env name="SESSION_DRIVER" value="array"/>
-        </php>
-    </phpunit>
+```xml
+<?xml version="1.0" encoding="UTF-8"?>
+<phpunit backupGlobals="false"
+         backupStaticAttributes="false"
+         bootstrap="../../../tests/bootstrap.php"
+         colors="true"
+         convertErrorsToExceptions="true"
+         convertNoticesToExceptions="true"
+         convertWarningsToExceptions="true"
+         processIsolation="false"
+         stopOnFailure="false"
+>
+    <testsuites>
+        <testsuite name="Plugin Unit Test Suite">
+            <directory>./tests</directory>
+        </testsuite>
+    </testsuites>
+    <php>
+        <env name="APP_ENV" value="testing"/>
+        <env name="CACHE_DRIVER" value="array"/>
+        <env name="SESSION_DRIVER" value="array"/>
+    </php>
+</phpunit>
+```
 
 Then a **tests/** directory can be created to contain the test classes. The file structure should mimic the base directory with classes having a `Test` suffix. Using a namespace for the class is also recommended.
 
-    <?php namespace Acme\Blog\Tests\Models;
+```php
+<?php namespace Acme\Blog\Tests\Models;
 
-    use Acme\Blog\Models\Post;
-    use PluginTestCase;
+use Acme\Blog\Models\Post;
+use PluginTestCase;
 
-    class PostTest extends PluginTestCase
+class PostTest extends PluginTestCase
+{
+    public function testCreateFirstPost()
     {
-        public function testCreateFirstPost()
-        {
-            $post = Post::create(['title' => 'Hi!']);
-            $this->assertEquals(1, $post->id);
-        }
+        $post = Post::create(['title' => 'Hi!']);
+        $this->assertEquals(1, $post->id);
     }
+}
+```
 
 The test class should extend the base class `PluginTestCase` and this is a special class that will set up the Winter database stored in memory, as part of the `setUp` method. It will also refresh the plugin being tested, along with any of the defined dependencies in the plugin registration file. This is the equivalent of running the following before each test:
 
-    php artisan winter:up
-    php artisan plugin:refresh Acme.Blog
-    [php artisan plugin:refresh <dependency>, ...]
+```bash
+php artisan winter:up
+php artisan plugin:refresh Acme.Blog
+[php artisan plugin:refresh <dependency>, ...]
+```
 
 > **NOTE:** If your plugin uses [configuration files](../plugin/settings#file-configuration), then you will need to run `System\Classes\PluginManager::instance()->registerAll(true);` in the `setUp` method of your tests. Below is an example of a base test case class that should be used if you need to test your plugin working with other plugins instead of in isolation.
 
-    use System\Classes\PluginManager;
+```php
+use System\Classes\PluginManager;
 
-    class BaseTestCase extends PluginTestCase
+class BaseTestCase extends PluginTestCase
+{
+    public function setUp(): void
     {
-        public function setUp(): void
-        {
-            parent::setUp();
+        parent::setUp();
 
-            // Get the plugin manager
-            $pluginManager = PluginManager::instance();
+        // Get the plugin manager
+        $pluginManager = PluginManager::instance();
 
-            // Register the plugins to make features like file configuration available
-            $pluginManager->registerAll(true);
+        // Register the plugins to make features like file configuration available
+        $pluginManager->registerAll(true);
 
-            // Boot all the plugins to test with dependencies of this plugin
-            $pluginManager->bootAll(true);
-        }
+        // Boot all the plugins to test with dependencies of this plugin
+        $pluginManager->bootAll(true);
+    }
 
-        public function tearDown(): void
-        {
-            parent::tearDown();
+    public function tearDown(): void
+    {
+        parent::tearDown();
 
-            // Get the plugin manager
-            $pluginManager = PluginManager::instance();
+        // Get the plugin manager
+        $pluginManager = PluginManager::instance();
 
-            // Ensure that plugins are registered again for the next test
-            $pluginManager->unregisterAll();
-        }
+        // Ensure that plugins are registered again for the next test
+        $pluginManager->unregisterAll();
     }
+}
+```
 
 #### Changing database engine for plugins tests
 

diff --git a/help-using-composer.md b/help-using-composer.md
@@ -32,7 +32,7 @@ In order to use Composer with a Winter CMS instance that has been installed usin
 
 If you plan on submitting pull requests to the Winter CMS project via GitHub, or are actively developing a project based on Winter CMS and want to stay up to date with the absolute latest version, we recommend switching your composer dependencies to point to the `develop` branch where all the latest improvements and bug fixes take place. Doing this will allow you to catch any potential issues that may be introduced (as rare as they are) right when they happen and get them fixed while you're still actively working on your project instead of only discovering them several months down the road if they eventually make it into production.
 
-```
+```json
 "winter/storm": "dev-develop as 1.1",
 "winter/wn-system-module": "dev-develop",
 "winter/wn-backend-module": "dev-develop",
@@ -89,24 +89,26 @@ composer require --dev <your package name> "<version constraint>"
 
 When publishing your plugins or themes to the marketplace, you may wish to also make them available via Composer. An example `composer.json` file for a plugin is included below:
 
-    {
-        "name": "winter/wn-demo-plugin",
-        "type": "winter-plugin",
-        "description": "Demo Winter CMS plugin",
-        "keywords": ["winter", "cms", "demo", "plugin"],
-        "license": "MIT",
-        "authors": [
-            {
-                "name": "Winter CMS Maintainers",
-                "url": "https://wintercms.com",
-                "role": "Maintainer"
-            }
-        ],
-        "require": {
-            "php": ">=7.2",
-            "composer/installers": "~1.0"
+```json
+{
+    "name": "winter/wn-demo-plugin",
+    "type": "winter-plugin",
+    "description": "Demo Winter CMS plugin",
+    "keywords": ["winter", "cms", "demo", "plugin"],
+    "license": "MIT",
+    "authors": [
+        {
+            "name": "Winter CMS Maintainers",
+            "url": "https://wintercms.com",
+            "role": "Maintainer"
         }
+    ],
+    "require": {
+        "php": ">=7.2",
+        "composer/installers": "~1.0"
     }
+}
+```
 
 Be sure to start your package `name` with **wn-** and end it with **-plugin** or **-theme** respectively - this will help others find your package and is in  accordance with the [quality guidelines](../help/developer/guide#repository-naming).
 
@@ -166,47 +168,51 @@ However, this can create problems with Winter's plugin oriented design, since th
 
 You may place this code in your Plugin registration file and call it from the  the `boot()` method.
 
-    public function bootPackages()
-    {
-        // Get the namespace code of the current plugin
-        $pluginNamespace = str_replace('\\', '.', strtolower(__NAMESPACE__));
-
-        // Locate the packages to boot
-        $packages = \Config::get($pluginNamespace . '::packages');
-
-        // Boot each package
-        foreach ($packages as $name => $options) {
-            // Apply the configuration for the package
-            if (
-                !empty($options['config']) &&
-                !empty($options['config_namespace'])
-            ) {
-                Config::set($options['config_namespace'], $options['config']);
-            }
+```php
+public function bootPackages()
+{
+    // Get the namespace code of the current plugin
+    $pluginNamespace = str_replace('\\', '.', strtolower(__NAMESPACE__));
+
+    // Locate the packages to boot
+    $packages = \Config::get($pluginNamespace . '::packages');
+
+    // Boot each package
+    foreach ($packages as $name => $options) {
+        // Apply the configuration for the package
+        if (
+            !empty($options['config']) &&
+            !empty($options['config_namespace'])
+        ) {
+            Config::set($options['config_namespace'], $options['config']);
         }
     }
+}
+```
 
 Now you are free to provide the packages configuration values the same way you would with regular plugin configuration values.
 
-    return [
-        // Laravel Package Configuration
-        'packages' => [
-            'packagevendor/packagename' => [
-                // The accessor for the config item, for example,
-                // to access via Config::get('purifier.' . $key)
-                'config_namespace' => 'purifier',
-
-                // The configuration file for the package itself.
-                // Copy this from the package configuration.
-                'config' => [
-                    'encoding'      => 'UTF-8',
-                    'finalize'      => true,
-                    'cachePath'     => storage_path('app/purifier'),
-                    'cacheFileMode' => 0755,
-                ],
+```php
+return [
+    // Laravel Package Configuration
+    'packages' => [
+        'packagevendor/packagename' => [
+            // The accessor for the config item, for example,
+            // to access via Config::get('purifier.' . $key)
+            'config_namespace' => 'purifier',
+
+            // The configuration file for the package itself.
+            // Copy this from the package configuration.
+            'config' => [
+                'encoding'      => 'UTF-8',
+                'finalize'      => true,
+                'cachePath'     => storage_path('app/purifier'),
+                'cacheFileMode' => 0755,
             ],
         ],
-    ];
+    ],
+];
+```
 
 Now the package configuration has been included natively in Winter CMS and the values can be changed normally using the [standard configuration approach](../plugin/settings#file-configuration).
 

diff --git a/markup-filter-app.md b/markup-filter-app.md
@@ -2,22 +2,30 @@
 
 The `| app` filter returns an address relative to the public path of the website. The result is an absolute URL, including the domain name and protocol, to the location specified in the filter parameter. The filter can be applied to any path.
 
-    <link rel="icon" href="{{ '/favicon.ico' | app }}" />
+```twig
+<link rel="icon" href="{{ '/favicon.ico' | app }}" />
+```
 
 If the website address is __https://example.com__ the above example would output the following:
 
-    <link rel="icon" href="https://example.com/favicon.ico" />
+```html
+<link rel="icon" href="https://example.com/favicon.ico" />
+```
 
 It can also be used for static URLs:
 
-    <a href="{{ '/about-us' | app }}">
-        About Us
-    </a>
+```twig
+<a href="{{ '/about-us' | app }}">
+    About Us
+</a>
+```
 
 The above would output:
 
-    <a href="https://example.com/about-us">
-        About us
-    </a>
+```html
+<a href="https://example.com/about-us">
+    About us
+</a>
+```
 
 > **NOTE**: The `| page` filter is recommended for linking to other pages.
diff --git a/markup-filter-default.md b/markup-filter-default.md
@@ -2,14 +2,18 @@
 
 The `| default` filter returns the value passed as the first argument if the filtered value is undefined or empty, otherwise the filtered value is returned.
 
-    {{ variable | default('The variable is not defined') }}
+```twig
+{{ variable | default('The variable is not defined') }}
 
-    {{ variable.foo | default('The foo property on variable is not defined') }}
+{{ variable.foo | default('The foo property on variable is not defined') }}
 
-    {{ variable['foo'] | default('The foo key in variable is not defined') }}
+{{ variable['foo'] | default('The foo key in variable is not defined') }}
 
-    {{ '' | default('The variable is empty')  }}
+{{ '' | default('The variable is empty')  }}
+```
 
 When using the `default` filter on an expression that uses variables in some method calls, be sure to use the `default` filter whenever a variable can be undefined:
 
-    {{ variable.method(foo | default('bar')) | default('bar') }}
+```twig
+{{ variable.method(foo | default('bar')) | default('bar') }}
+```
diff --git a/markup-filter-image-height.md b/markup-filter-image-height.md
@@ -4,9 +4,11 @@ The `| imageHeight` filter attempts to identify the width in pixels of the provi
 
 > **NOTE:** This filter does not support thumbnail (already resized) versions of FileModels being passed as the image source.
 
-    {% set resizedImage = 'banner.jpg' | media | resize(1920, 1080) %}
-    <img src="{{ resizedImage }}" height="{{ resizedImage | imageHeight }}" />
+```twig
+{% set resizedImage = 'banner.jpg' | media | resize(1920, 1080) %}
+<img src="{{ resizedImage }}" height="{{ resizedImage | imageHeight }}" />
+```
 
 See the [image resizing docs](../services/image-resizing#resize-sources) for more information on what image sources are supported.
 
-> **NOTE:** The image resizing functionality requires a cache driver that persists cache data between requests in order to function, `array` is not a supported cache driver if you wish to use this functionality.
+> **NOTE:** The image resizing functionality requires a cache driver that persists cache data between requests in order to function, `array` is not a supported cache driver if you wish to use this functionality.
diff --git a/markup-filter-image-width.md b/markup-filter-image-width.md
@@ -4,9 +4,11 @@ The `| imageWidth` filter attempts to identify the width in pixels of the provid
 
 > **NOTE:** This filter does not support thumbnail (already resized) versions of FileModels being passed as the image source.
 
-    {% set resizedImage = 'banner.jpg' | media | resize(1920, 1080) %}
-    <img src="{{ resizedImage }}" width="{{ resizedImage | imageWidth }}" />
+```twig
+{% set resizedImage = 'banner.jpg' | media | resize(1920, 1080) %}
+<img src="{{ resizedImage }}" width="{{ resizedImage | imageWidth }}" />
+```
 
 See the [image resizing docs](../services/image-resizing#resize-sources) for more information on what image sources are supported.
 
-> **NOTE:** The image resizing functionality requires a cache driver that persists cache data between requests in order to function, `array` is not a supported cache driver if you wish to use this functionality.
+> **NOTE:** The image resizing functionality requires a cache driver that persists cache data between requests in order to function, `array` is not a supported cache driver if you wish to use this functionality.
diff --git a/markup-filter-md.md b/markup-filter-md.md
@@ -2,8 +2,12 @@
 
 The `| md` filter converts the value from Markdown to HTML format.
 
-    {{ '**Text** is bold.' | md }}
+```twig
+{{ '**Text** is bold.' | md }}
+```
 
 The above will output the following:
 
-    <p><strong>Text</strong> is bold.</p>
+```html
+<p><strong>Text</strong> is bold.</p>
+```