From 8778d051037e2dcfbfb53cafef54584205f90177 Mon Sep 17 00:00:00 2001 From: latent-9 <296084221+latent-9@users.noreply.github.com> Date: Sun, 9 Aug 2026 14:57:39 +1200 Subject: [PATCH] Fix documentation typos --- architecture/using-composer.md | 2 +- backend/controllers-ajax.md | 4 ++-- backend/forms.md | 2 +- snowboard/extras.md | 4 ++-- snowboard/request.md | 2 +- 5 files changed, 7 insertions(+), 7 deletions(-) diff --git a/architecture/using-composer.md b/architecture/using-composer.md index acb5032f..b1162c86 100644 --- a/architecture/using-composer.md +++ b/architecture/using-composer.md @@ -185,7 +185,7 @@ Laravel packages will often provide configuration files, and they will usually c However, this can create problems with Winter's plugin oriented design, since there would now be random config files in the core `/config` directory. In order to solve this problem, it is recommended that you proxy the included package's configuration through your plugin instead. -You may place this code in your Plugin registration file and call it from the the `boot()` method. +You may place this code in your Plugin registration file and call it from the `boot()` method. ```php public function bootPackages() diff --git a/backend/controllers-ajax.md b/backend/controllers-ajax.md index e10a1f94..3b216eff 100644 --- a/backend/controllers-ajax.md +++ b/backend/controllers-ajax.md @@ -4,7 +4,7 @@ The Winter CMS backend implements the MVC pattern. Controllers manage backend pages and implement various features like forms and lists. This article describes how to develop backend controllers and how to configure controller behaviors. -Each controller consists of a PHP file which resides in the the **/controllers** subdirectory of a Plugin directory. Controller views are `.php` 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: +Each controller consists of a PHP file which resides in the **/controllers** subdirectory of a Plugin directory. Controller views are `.php` 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: ```treeview plugins/ @@ -44,7 +44,7 @@ The backend controller base class defines a number of properties that allow to c Property | Description ------------- | ------------- `$fatalError` | allows to store a fatal exception generated in an action method in order to display it in the view. -`$user` | contains a reference to the the backend user object. +`$user` | contains a reference to the backend user object. `$suppressView` | allows to prevent the view display. Can be updated in the action method or in the controller constructor. `$params` | an array of the routed parameters. `$action` | a name of the action method being executed in the current request. diff --git a/backend/forms.md b/backend/forms.md index adc4ab63..9f4b9ef8 100644 --- a/backend/forms.md +++ b/backend/forms.md @@ -1846,7 +1846,7 @@ Sometimes you may wish to modify the default form behavior and there are several Several controller methods can called at various points during the lifecycle of the `FormController` to provide injection points for custom logic. See the [API docs](/docs/v1.2/api/Backend/Behaviors/FormController#method-formbeforesave) for a full reference of what they are. Generally speaking any method in the API docs prefixed with `form` can be overridden in your controller to change the default behaviour or act as an injection point for custom logic. -> **NOTE:** It may be more desirable to use [model events](/docs/v1.2/api/events/model/beforeSave) to implement your logic instead as those are always run when applicable if the model is being affected, no matter where the interaction with the model is occuring. +> **NOTE:** It may be more desirable to use [model events](/docs/v1.2/api/events/model/beforeSave) to implement your logic instead as those are always run when applicable if the model is being affected, no matter where the interaction with the model is occurring. ### Overriding controller action diff --git a/snowboard/extras.md b/snowboard/extras.md index c95b7ad0..39c5f24a 100644 --- a/snowboard/extras.md +++ b/snowboard/extras.md @@ -413,7 +413,7 @@ class Gallery extends Snowboard.PluginBase { } ``` -In the example above, even if the gallery element defines a `data-num-images` data attribute, this will be overriden by the `userNumImages` parameter that is used in constructing the gallery. This `userNumImages` parameter could be populated by a user configuration source. +In the example above, even if the gallery element defines a `data-num-images` data attribute, this will be overridden by the `userNumImages` parameter that is used in constructing the gallery. This `userNumImages` parameter could be populated by a user configuration source. ### Methods @@ -429,7 +429,7 @@ this.config.get(); // Returns an object of all configuration options and their v #### `get(configName: string)` -Gets the configuration value for the given configuration name. This will be retrieved from the local configuration first, then the data attribute of the element providing the configuration then finally from the the defaults if not specified on the element. +Gets the configuration value for the given configuration name. This will be retrieved from the local configuration first, then the data attribute of the element providing the configuration then finally from the defaults if not specified on the element. If the configuration has been provided a local configuration value for the config name, it will be returned over all other sources. diff --git a/snowboard/request.md b/snowboard/request.md index bdca0dc9..25de3fd0 100644 --- a/snowboard/request.md +++ b/snowboard/request.md @@ -71,7 +71,7 @@ Finally, the following option parameters define override functionality for vario Option | Parameters | Description ------ | ---------- | ----------- `handleConfirmMessage` | `(string) confirmationMessage` | Handles any confirmations requested of the user. -`handleErrorMessage` | `(string) errorMessage` | Handles any errors occuring during the request +`handleErrorMessage` | `(string) errorMessage` | Handles any errors occurring during the request `handleValidationMessage` | `(string) message, (Object) fieldMessages` | Handles validation errors occurring during the request. `fieldMessages` has field names as the key and messages as the value. `handleFlashMessage` | `(string) message, (string) type` | Handles flash messages. `handleRedirectResponse` | `(string) redirectUrl` | Handles redirect responses.