diff --git a/docs/en/00_Getting_Started/00_Server_Requirements.md b/docs/en/00_Getting_Started/00_Server_Requirements.md index 3d3806d17..9a5780fb5 100644 --- a/docs/en/00_Getting_Started/00_Server_Requirements.md +++ b/docs/en/00_Getting_Started/00_Server_Requirements.md @@ -58,20 +58,20 @@ see `MySQLDatabase::$sql_mode` for more details.) This setting is only available ### Overview -Silverstripe needs to handle a variety of HTTP requests, and relies on the hosting environment to be configured securely +Silverstripe CMS needs to handle a variety of HTTP requests, and relies on the hosting environment to be configured securely to enforce restrictions. There are secure defaults in place for Apache, but you should be aware of the configuration regardless of your webserver setup. ### Public webroot -The webroot of your webserver should be configured to the `public/` subfolder. Projects created prior to Silverstripe +The webroot of your webserver should be configured to the `public/` subfolder. Projects created prior to Silverstripe CMS 4.1 might be using the main project folder as the webroot. In this case, you are responsible for ensuring access to system files such as configuration in `*.yml` is protected from public access. We strongly recommend switching to more secure hosting via the `public/`. See [4.1.0 upgrading guide](/changelogs/4.1.0). ### Filesystem permissions -During runtime, Silverstripe needs read access for the webserver user to your base path (including your webroot). It +During runtime, Silverstripe CMS needs read access for the webserver user to your base path (including your webroot). It also needs write access for the webserver user to the following locations: * `public/assets/`: Used by the CMS and other logic to [store uploads](/developer_guides/files/file_storage) @@ -81,20 +81,20 @@ also needs write access for the webserver user to the following locations: See [Environment Management](/getting_started/environment_management). If you aren't explicitly [packaging](#building-packaging-deployment) -your Silverstripe project during your deployment process, additional write access may be required to generate supporting +your Silverstripe CMS project during your deployment process, additional write access may be required to generate supporting files on the fly. This is not recommended, because it can lead to extended execution times as well as cause inconsistencies between multiple server environments when manifest and cache storage isn't shared between servers. ### Assets -Silverstripe allows CMS authors to upload files into the `public/assets/` folder, which should be served by your +Silverstripe CMS allows CMS authors to upload files into the `public/assets/` folder, which should be served by your webserver. **No PHP execution should be allowed in this folder**. This is configured for Apache by default via `public/assets/.htaccess`. The file is generated dynamically during the `dev/build` stage. Additionally, access is whitelisted by file extension through a dynamically generated whitelist based on the `File.allowed_extensions` setting (see [File Security](/developer_guides/files/file_security#file-types)). This whitelist uses the same defaults -configured through file upload through Silverstripe, so is considered a second line of defence. +configured through file upload through Silverstripe CMS, so is considered a second line of defence. ### Secure Assets {#secure-assets} @@ -134,9 +134,9 @@ Don't forget to include this additional folder in any syncing and backup process ### Building, Packaging and Deployment {#building-packaging-deployment} -It is common to build a Silverstripe application into a package on one environment (e.g. a CI server), and then deploy +It is common to build a Silverstripe CMS application into a package on one environment (e.g. a CI server), and then deploy the package to a (separate) webserver environment(s). This approach relies on all auto-generated files required by -Silverstripe to be included in the package, or generated on the fly on each webserver environment. +Silverstripe CMS to be included in the package, or generated on the fly on each webserver environment. The easiest way to ensure this is to commit auto generated files to source control. If those changes are considered too noisy, here's some pointers for auto-generated files to trigger and include in a deployment package: @@ -154,14 +154,14 @@ noisy, here's some pointers for auto-generated files to trigger and include in a ### Web Worker Concurrency -It's generally a good idea to run multiple workers to serve multiple HTTP requests to Silverstripe concurrently. The +It's generally a good idea to run multiple workers to serve multiple HTTP requests to Silverstripe CMS concurrently. The exact number depends on your website needs. The CMS attempts to request multiple views concurrently. It also routes [protected and draft files](/developer_guides/files/file_security) -through Silverstripe. This can increase your concurrency requirements, e.g. when authors batch upload and view dozens of +through Silverstripe CMS. This can increase your concurrency requirements, e.g. when authors batch upload and view dozens of draft files in the CMS. When allowing upload of large files through the CMS (through PHP settings), these files might be used -as [protected and draft files](/developer_guides/files/file_security). Files in this state get served by Silverstripe +as [protected and draft files](/developer_guides/files/file_security). Files in this state get served by Silverstripe CMS rather than your webserver. Since the framework uses [PHP streams](https://www.php.net/manual/en/ref.stream.php), this allows serving of files larger than your PHP memory limit. Please be aware that streaming operations don't count towards PHP's [max_execution_time](https://www.php.net/manual/en/function.set-time-limit.php), which can risk exhaustion of web @@ -169,34 +169,34 @@ worker pools for long-running downloads. ### URL Rewriting -Silverstripe expects URL paths to be rewritten to `public/index.php`. For Apache, this is preconfigured +Silverstripe CMS expects URL paths to be rewritten to `public/index.php`. For Apache, this is preconfigured through `.htaccess` files, and expects using the `mod_rewrite` module. By default, these files are located in `public/.htaccess` and `public/assets/.htaccess`. ### HTTP Headers -Silverstripe can add HTTP headers to responses it handles directly. These headers are often sensitive, for example +Silverstripe CMS can add HTTP headers to responses it handles directly. These headers are often sensitive, for example preventing HTTP caching for responses displaying data based on user sessions, or when serving protected assets. You need to ensure those headers are kept in place in your webserver. For example, Apache allows this through `Header setifempty` (see [docs](https://httpd.apache.org/docs/current/mod/mod_headers.html#header)). See [Developer Guide: Performance](/developer_guides/performance/) and [Developer Guides: File Security](/developer_guides/files/file_security) for more details. -Silverstripe relies on the `Host` header to construct URLs such as "reset password" links, so you'll need to ensure that +Silverstripe CMS relies on the `Host` header to construct URLs such as "reset password" links, so you'll need to ensure that the systems hosting it only allow valid values for this header. See [Developer Guide: Security - Request hostname forgery](/developer_guides/security/secure_coding#request-hostname-forgery) . ### CDNs and other Reverse Proxies -If your Silverstripe site is hosted behind multiple HTTP layers, you're in charge of controlling which forwarded headers +If your Silverstripe CMS site is hosted behind multiple HTTP layers, you're in charge of controlling which forwarded headers are considered valid, and which IPs can set them. See [Developer Guide: Security - Request hostname forgery](/developer_guides/security/secure_coding#request-hostname-forgery) . ### Symlinks -Silverstripe is a modular system, with modules installed and updated via the `composer` PHP dependency manager. These +Silverstripe CMS is a modular system, with modules installed and updated via the `composer` PHP dependency manager. These are usually stored in `vendor/`, outside of the `public/` webroot. Since many modules rely on serving frontend assets such as CSS files or images, these are mapped over to the `public/_resources/` folder automatically. If the filesystem supports it, this is achieved through symlinks. Depending on your hosting and deployment mechanisms, you may need to @@ -205,7 +205,7 @@ See [silverstripe/vendor-plugin](https://github.com/silverstripe/vendor-plugin) ### Caches -Silverstripe relies on various [caches](/developer_guides/performance/caching/) +Silverstripe CMS relies on various [caches](/developer_guides/performance/caching/) to achieve performant responses. By default, those caches are stored in a temporary filesystem folder, and are not shared between multiple server instances. Alternative cache backends such as Redis can be [configured](/developer_guides/performance/caching/). @@ -232,12 +232,12 @@ through the CMS. There are various community supported installation instructions for different environments. Nginx is a popular choice, see [Nginx webserver configuration](https://forum.silverstripe.org/t/nginx-webserver-configuration/2246). -Silverstripe is known to work with Microsoft IIS, and generates `web.config` files by default +Silverstripe CMS is known to work with Microsoft IIS, and generates `web.config` files by default ( see [Microsoft IIS and SQL Server configuration](https://forum.silverstripe.org/t/microsoft-iis-webserver-and-sql-server-support/2245)) . -Additionally, there are community supported guides for installing Silverstripe on various environments: +Additionally, there are community supported guides for installing Silverstripe CMS on various environments: * [Hosting via Bitnami](https://bitnami.com/stack/silverstripe/virtual-machine): In the cloud or as a locally hosted virtual machine @@ -248,12 +248,12 @@ Additionally, there are community supported guides for installing Silverstripe o * [Vagrant with silverstripe-australia/vagrant-environment](https://github.com/silverstripe-australia/vagrant-environment) * [Vagrant with BetterBrief/vagrant-skeleton](https://github.com/BetterBrief/vagrant-skeleton) -## PHP Requirements for older Silverstripe releases {#php-support} +## PHP Requirements for older Silverstripe CMS releases {#php-support} -Silverstripe's PHP support has changed over time and if you are looking to upgrade PHP on your Silverstripe site, this +Silverstripe CMS's PHP support has changed over time and if you are looking to upgrade PHP on your Silverstripe CMS site, this table may be of use: -| Silverstripe Version | PHP Version | More information | +| Silverstripe CMS Version | PHP Version | More information | | -------------------- | ----------- | ---------------- | | 3.0 - 3.5 | 5.3 - 5.6 | [requirements docs](https://docs.silverstripe.org/en/3.4/getting_started/server_requirements/) | 3.6 | 5.3 - 7.1 | | @@ -265,11 +265,6 @@ table may be of use: Silverstripe CMS supports the following web browsers: -* Google Chrome -* Internet Explorer 11 -* Microsoft Edge -* Mozilla Firefox - We aim to provide satisfactory experiences in Apple Safari. Silverstripe CMS works well across Windows, Linux, and Mac operating systems. diff --git a/docs/en/00_Getting_Started/02_Composer.md b/docs/en/00_Getting_Started/02_Composer.md index bb5ebba8f..8ffdceb2c 100644 --- a/docs/en/00_Getting_Started/02_Composer.md +++ b/docs/en/00_Getting_Started/02_Composer.md @@ -3,11 +3,11 @@ title: Composer summary: What is composer and how to use it with Silverstripe CMS --- -# Using Silverstripe with Composer +# Using Silverstripe CMS with Composer ## Requirements -[Composer](http://getcomposer.org/) is a package management tool for PHP that lets you install and upgrade Silverstripe +[Composer](http://getcomposer.org/) is a package management tool for PHP that lets you install and upgrade Silverstripe CMS and its modules. We also have separate instructions for [installing modules with Composer](/developer_guides/extending/modules). @@ -49,14 +49,14 @@ composer create-project silverstripe/installer ./my-project 4.3.3 ``` When `create-project` is used with a release version like above, it will try to get the code from archives instead of -creating git repositories. If you're planning to contribute to Silverstripe, +creating git repositories. If you're planning to contribute to Silverstripe CMS, see [Using development versions](#using-development-versions). ## Adding modules to your project -Composer isn't only used to download Silverstripe CMS, it is also used to manage all Silverstripe modules. You can find -thousands of modules on [https://addons.silverstripe.org](https://addons.silverstripe.org). Installing a module can be -done with the following command: +Composer isn't only used to download Silverstripe CMS, it is also used to manage all Silverstripe CMS modules. +You can find thousands of modules on [https://addons.silverstripe.org](https://addons.silverstripe.org). +Installing a module can be done with the following command: ``` composer require silverstripe/blog @@ -79,7 +79,7 @@ a little different. The version string for the `4` branch is `4.x-dev`. ## Updating dependencies Except for the control code of the Voyager space probe, every piece of code in the universe gets updated from time to -time. Silverstripe modules are no exception. +time. Silverstripe CMS modules are no exception. To get the latest updates of the modules in your project, run this command: @@ -111,14 +111,14 @@ So your deployment process, as it relates to Composer, should be as follows: ## Composer managed modules, Git and .gitignore -Modules and themes managed by Composer should not be committed with your projects source code. Silverstripe ships with +Modules and themes managed by Composer should not be committed with your projects source code. Silverstripe CMS ships with a [.gitignore](http://git-scm.com/docs/gitignore) file by default which prevents this. For more details read [Should I commit the dependencies in my vendor directory?](https://getcomposer.org/doc/faqs/should-i-commit-the-dependencies-in-my-vendor-directory.md) . ## Dev Environments for Contributing Code {#contributing} -So you want to contribute to Silverstripe? Fantastic! You can do this with composer too. You have to tell composer three +So you want to contribute to Silverstripe CMS? Fantastic! You can do this with composer too. You have to tell composer three things in order to be able to do this: - Keep the full git repository information @@ -138,11 +138,11 @@ on [composer version naming](http://getcomposer.org/doc/02-libraries.md#specifyi The `--keep-vcs` flag will make sure you have access to the git history of the installer and the requirements -The `--dev` flag is optional, and can be used to add a couple modules which are useful for Silverstripe development: +The `--dev` flag is optional, and can be used to add a couple modules which are useful for Silverstripe CMS development: * The `behat-extension` module allows running [Behat](http://behat.org) integration tests * The `docsviewer` module will let you preview changes to the project documentation -* The `buildtools` module which adds [phing](http://phing.info) tasks for creating Silverstripe releases +* The `buildtools` module which adds [phing](http://phing.info) tasks for creating Silverstripe CMS releases Once the `create-project` command completes, you need to edit the `composer.json` in the project root and remove the `@stable` markers from the `silverstripe/cms` and `silverstripe/framework` version entries. @@ -194,7 +194,7 @@ is to ensure that when developers are getting started, running `composer update` unstable version However it is relatively easy to tell composer to use development versions. Not only is this required if you want to -contribute back to the Silverstripe project, it also allows you to get fixes and API changes early. +contribute back to the Silverstripe CMS project, it also allows you to get fixes and API changes early. This is a two step process. First you get composer to start a project based on the latest unstable silverstripe/installer @@ -324,7 +324,7 @@ on [packagist.org](http://packagist.org). Follow the packagist.org advice on choosing a [unique name and vendor prefix](https://packagist.org/about). Please don't use the `silverstripe/` vendor prefix, since that's reserved for modules produced by Silverstripe Ltd. In -order to declare that your module is in fact a Silverstripe module, use the "silverstripe" tag in the composer.json +order to declare that your module is in fact a Silverstripe CMS module, use the "silverstripe" tag in the composer.json file, and set the "type" to "silverstripe-module". ### What about themes? diff --git a/docs/en/02_Developer_Guides/00_Model/01_Data_Model_and_ORM.md b/docs/en/02_Developer_Guides/00_Model/01_Data_Model_and_ORM.md index 4c14cf6fb..ec3caa048 100644 --- a/docs/en/02_Developer_Guides/00_Model/01_Data_Model_and_ORM.md +++ b/docs/en/02_Developer_Guides/00_Model/01_Data_Model_and_ORM.md @@ -13,7 +13,7 @@ information. * Each database row maps to a PHP object. * Each database column maps to a property on a PHP object. -All data tables in Silverstripe are defined as subclasses of [DataObject](api:SilverStripe\ORM\DataObject). The [DataObject](api:SilverStripe\ORM\DataObject) class represents a +All data tables in Silverstripe CMS are defined as subclasses of [DataObject](api:SilverStripe\ORM\DataObject). The [DataObject](api:SilverStripe\ORM\DataObject) class represents a single row in a database table, following the ["Active Record"](http://en.wikipedia.org/wiki/Active_record_pattern) design pattern. Database Columns are defined as [Data Types](/developer_guides/model/data_types_and_casting) in the static `$db` variable along with any [relationships](relations) defined as `$has_one`, `$has_many`, `$many_many` properties on the class. @@ -41,7 +41,7 @@ so on. After writing this class, we need to regenerate the database schema. ## Generating the Database Schema -After adding, modifying or removing `DataObject` subclasses, make sure to rebuild your Silverstripe database. The +After adding, modifying or removing `DataObject` subclasses, make sure to rebuild your Silverstripe CMS database. The database schema is generated automatically by visiting the URL http://www.yoursite.com/dev/build while authenticated as an administrator. This script will analyze the existing schema, compare it to what's required by your data classes, and alter the schema @@ -60,7 +60,7 @@ It **won't** do any of the following * Delete tables * Delete fields * Rename any tables that it doesn't recognize. This allows other applications to coexist in the same database, as long as - their table names don't match a Silverstripe data class. + their table names don't match a Silverstripe CMS data class. [notice] @@ -129,7 +129,7 @@ Using the `create()` method provides chainability, which can add elegance and br [/notice] -Database columns and properties can be set as class properties on the object. The Silverstripe ORM handles the saving +Database columns and properties can be set as class properties on the object. The Silverstripe CMS ORM handles the saving of the values through a custom `__set()` method. ```php @@ -692,7 +692,7 @@ Note: Alternatively you can set defaults directly in the database-schema (rather ## Subclasses Inheritance is supported in the data model: separate tables will be linked together, the data spread across these -tables. The mapping and saving logic is handled by Silverstripe, you don't need to worry about writing SQL most of the +tables. The mapping and saving logic is handled by Silverstripe CMS , you don't need to worry about writing SQL most of the time. For example, suppose we have the following set of classes: @@ -751,7 +751,7 @@ The way the ORM stores the data is this: * In all the tables, ID is the primary key. A matching ID number is used for all parts of a particular record: record #2 in Page refers to the same object as record #2 in [SiteTree](api:SilverStripe\CMS\Model\SiteTree). -To retrieve a news article, Silverstripe joins the [SiteTree](api:SilverStripe\CMS\Model\SiteTree), [Page](api:SilverStripe\CMS\Model\SiteTree\Page) and NewsPage tables by their ID fields. +To retrieve a news article, Silverstripe CMS joins the [SiteTree](api:SilverStripe\CMS\Model\SiteTree), [Page](api:SilverStripe\CMS\Model\SiteTree\Page) and NewsPage tables by their ID fields. ## Related Lessons * [Introduction to the ORM](https://www.silverstripe.org/learn/lessons/v4/introduction-to-the-orm-1) diff --git a/docs/en/02_Developer_Guides/00_Model/02_Relations.md b/docs/en/02_Developer_Guides/00_Model/02_Relations.md index e37b1a457..fc3ccd393 100644 --- a/docs/en/02_Developer_Guides/00_Model/02_Relations.md +++ b/docs/en/02_Developer_Guides/00_Model/02_Relations.md @@ -11,7 +11,7 @@ to one another. An example of this is a `Player` object may have a relationship and could take part in many `Games`. Relations are a key part of designing and building a good data model. Relations are built through static array definitions on a class, in the format ` => `. -SilverStripe supports a number of relationship types and each relationship type can have any number of relations. +Silverstripe CMS supports a number of relationship types and each relationship type can have any number of relations. ## has_one diff --git a/docs/en/02_Developer_Guides/00_Model/04_Data_Types_and_Casting.md b/docs/en/02_Developer_Guides/00_Model/04_Data_Types_and_Casting.md index 8e855468a..1f4eb1f28 100644 --- a/docs/en/02_Developer_Guides/00_Model/04_Data_Types_and_Casting.md +++ b/docs/en/02_Developer_Guides/00_Model/04_Data_Types_and_Casting.md @@ -6,10 +6,10 @@ icon: code # Data Types and Casting -Each model in a SilverStripe [DataObject](api:SilverStripe\ORM\DataObject) will handle data at some point. This includes database columns such as +Each model in a Silverstripe CMS [DataObject](api:SilverStripe\ORM\DataObject) will handle data at some point. This includes database columns such as the ones defined in a `$db` array or simply a method that returns data for the template. -A Data Type is represented in SilverStripe by a [DBField](api:SilverStripe\ORM\FieldType\DBField) subclass. The class is responsible for telling the ORM +A Data Type is represented in Silverstripe CMS by a [DBField](api:SilverStripe\ORM\FieldType\DBField) subclass. The class is responsible for telling the ORM about how to store its data in the database and how to format the information coming out of the database, i.e. on a template. In the `Player` example, we have four database columns each with a different data type (Int, Varchar). @@ -157,7 +157,7 @@ class Player extends DataObject } ``` -The properties on any SilverStripe object can be type casted automatically, by transforming its scalar value into an +The properties on any Silverstripe CMS object can be type casted automatically, by transforming its scalar value into an instance of the [DBField](api:SilverStripe\ORM\FieldType\DBField) class, providing additional helpers. For example, a string can be cast as a [DBText](api:SilverStripe\ORM\FieldType\DBText) type, which has a `FirstSentence()` method to retrieve the first sentence in a longer piece of text. @@ -179,7 +179,7 @@ DBField::create_field('Date', '1982-01-01')->TimeDiff(); // shows "30 years ago" ## Casting ViewableData -Most objects in SilverStripe extend from [ViewableData](api:SilverStripe\View\ViewableData), which means they know how to present themselves in a view +Most objects in Silverstripe CMS extend from [ViewableData](api:SilverStripe\View\ViewableData), which means they know how to present themselves in a view context. Through a `$casting` array, arbitrary properties and getters can be casted: ```php diff --git a/docs/en/02_Developer_Guides/00_Model/08_SQL_Select.md b/docs/en/02_Developer_Guides/00_Model/08_SQL_Select.md index 12c5aef29..bc0a53e62 100644 --- a/docs/en/02_Developer_Guides/00_Model/08_SQL_Select.md +++ b/docs/en/02_Developer_Guides/00_Model/08_SQL_Select.md @@ -10,11 +10,11 @@ iconBrand: searchengin An object representing a SQL select query, which can be serialized into a SQL statement. It is easier to deal with object-wrappers than string-parsing a raw SQL-query. -This object is used by the SilverStripe ORM internally. +This object is used by the Silverstripe CMS ORM internally. Dealing with low-level SQL is not encouraged, since the ORM provides powerful abstraction APIs (see [datamodel](/developer_guides/model/data_model_and_orm)). -Starting with SilverStripe 3, records in collections are lazy loaded, +Starting with Silverstripe CMS 3, records in collections are lazy loaded, and these collections have the ability to run efficient SQL such as counts or returning a single column. @@ -296,7 +296,7 @@ $map = $players->map('Name', 'NameWithBirthyear'); ### Data types -As of SilverStripe 4.4, the following PHP types will be used to return database content: +As of Silverstripe CMS 4.4, the following PHP types will be used to return database content: * booleans will be an integer 1 or 0, to ensure consistency with MySQL that doesn't have native booleans * integer types returned as integers @@ -304,7 +304,7 @@ As of SilverStripe 4.4, the following PHP types will be used to return database * strings returned as strings * dates / datetimes returned as strings -Up until SilverStripe 4.3, bugs meant that strings were used for every column type. +Up until Silverstripe CMS 4.3, bugs meant that strings were used for every column type. ## Related Lessons * [Building custom SQL](https://www.silverstripe.org/learn/lessons/v4/beyond-the-orm-building-custom-sql-1) diff --git a/docs/en/02_Developer_Guides/00_Model/09_Validation.md b/docs/en/02_Developer_Guides/00_Model/09_Validation.md index 96a4f9d32..6ac23e9bd 100644 --- a/docs/en/02_Developer_Guides/00_Model/09_Validation.md +++ b/docs/en/02_Developer_Guides/00_Model/09_Validation.md @@ -6,12 +6,12 @@ icon: check-square # Validation and Constraints -Traditionally, validation in SilverStripe has been mostly handled on the controller through [form validation](../forms). +Traditionally, validation in Silverstripe CMS has been mostly handled on the controller through [form validation](../forms). While this is a useful approach, it can lead to data inconsistencies if the record is modified outside of the controller and form context. -Most validation constraints are actually data constraints which belong on the model. SilverStripe provides the +Most validation constraints are actually data constraints which belong on the model. Silverstripe CMS provides the [DataObject::validate()](api:SilverStripe\ORM\DataObject::validate()) method for this purpose. By default, there is no validation - objects are always valid! However, you can overload this method in your DataObject diff --git a/docs/en/02_Developer_Guides/00_Model/10_Versioning.md b/docs/en/02_Developer_Guides/00_Model/10_Versioning.md index c849ea2bc..cd330bca1 100644 --- a/docs/en/02_Developer_Guides/00_Model/10_Versioning.md +++ b/docs/en/02_Developer_Guides/00_Model/10_Versioning.md @@ -5,13 +5,13 @@ summary: Add versioning to your database content through the Versioned extension # Versioning -Database content in SilverStripe can be "staged" before its publication, as well as track all changes through the +Database content in Silverstripe CMS can be "staged" before its publication, as well as track all changes through the lifetime of a database record. It is most commonly applied to pages in the CMS (the `SiteTree` class). Draft content edited in the CMS can be different from published content shown to your website visitors. -Versioning in SilverStripe is handled through the [Versioned](api:SilverStripe\Versioned\Versioned) class. As a [DataExtension](api:SilverStripe\ORM\DataExtension) it is possible to be applied to any [DataObject](api:SilverStripe\ORM\DataObject) subclass. The extension class will automatically update read and write operations done via the ORM via the `augmentSQL` database hook. +Versioning in Silverstripe CMS is handled through the [Versioned](api:SilverStripe\Versioned\Versioned) class. As a [DataExtension](api:SilverStripe\ORM\DataExtension) it is possible to be applied to any [DataObject](api:SilverStripe\ORM\DataObject) subclass. The extension class will automatically update read and write operations done via the ORM via the `augmentSQL` database hook. [notice] There are two complementary modules that improve content editor experience around "owned" nested objects (e.g. elemental blocks). @@ -31,11 +31,11 @@ The second module extends CMS History UI adding control over nested objects. ## Understanding versioning concepts -This section discusses how SilverStripe implements versioning and related high level concepts without digging into technical details. +This section discusses how Silverstripe CMS implements versioning and related high level concepts without digging into technical details. ### Stages -In most cases, you'll want to have one polished version of a `Page` visible to the general public while your editors might be working off a draft version. SilverStripe handles this through the concept of _stage_. +In most cases, you'll want to have one polished version of a `Page` visible to the general public while your editors might be working off a draft version. Silverstripe CMS handles this through the concept of _stage_. By default, adding the `Versioned` extension to a DataObject will create 2 stages: * "Stage" for tracking draft content @@ -61,7 +61,7 @@ and has_one/has_many, however it relies on a pre-existing relationship to functi If an object "owns" other objects, you'll usually want to publish the child objects when the parent object gets published. If those child objects themselves own other objects, you'll want the grand-children to be published along with the parent. -SilverStripe makes this possible by using the concept of _cascade publishing_. You can choose to recursively publish an object. When an object is recursively published – either through a user action or through code – all other records it owns that implement the Versioned extension will automatically be published. Publication will also cascade to children of children and so on. +Silverstripe CMS makes this possible by using the concept of _cascade publishing_. You can choose to recursively publish an object. When an object is recursively published – either through a user action or through code – all other records it owns that implement the Versioned extension will automatically be published. Publication will also cascade to children of children and so on. A non-recursive publish operation is also available if you want to publish a new version of a object without cascade publishing all its children. @@ -79,7 +79,7 @@ An unversioned object can also be owned by a versioned object. This can be used #### Ownership through media insertion in content -Images and other files are tracked as versioned objects. If a file is referenced through an HTML text field, it needs to be published for it to be accessible to the public. SilverStripe will automatically pick up when an object references files through an HTML text field and recursively publish those files. +Images and other files are tracked as versioned objects. If a file is referenced through an HTML text field, it needs to be published for it to be accessible to the public. Silverstripe CMS will automatically pick up when an object references files through an HTML text field and recursively publish those files. This behavior works both for versioned and unversioned objects. @@ -201,7 +201,7 @@ Note that ownership cannot be used with polymorphic relations. E.g. has_one to n #### Unversioned DataObject ownership -*Requires SilverStripe 4.1 or newer* +*Requires Silverstripe CMS 4.1 or newer* Ownership can be used with non-versioned DataObjects, as the necessary functionality is included by default by the versioned object through the [`RecursivePublishable`](api:SilverStripe\Versioned\RecursivePublishable) extension which is @@ -591,7 +591,7 @@ The current stage for each request is determined by `VersionedHTTPMiddleware` be `Versioned::choose_site_stage()`. It checks for a `stage` GET parameter, so you can force a draft stage by appending `?stage=Stage` to your request. -Since SilverStripe 4.2, the current stage setting is no longer "sticky" in the session. +Since Silverstripe CMS 4.2, the current stage setting is no longer "sticky" in the session. Any links presented on the view produced with `?stage=Stage` need to have the same GET parameters in order to retain the stage. If you are using the `SiteTree->Link()` and `Controller->Link()` methods, this is automatically the case for `DataObject` links, controller links and form actions. @@ -842,7 +842,7 @@ public function init() ### Low level write and publication methods -SilverStripe will usually call these low level methods for you. However if you have specialised needs, you may call them directly. +Silverstripe CMS will usually call these low level methods for you. However if you have specialised needs, you may call them directly. To move a saved version from one stage to another, call [writeToStage(stage)](api:SilverStripe\Versioned\Versioned::writeToStage()) on the object. This is used internally to publish DataObjects. @@ -861,7 +861,7 @@ Versioned::set_reading_mode($origMode); // reset current mode ## Using the history viewer -Since SilverStripe 4.3 you can use the React and GraphQL driven history viewer UI to display historic changes and +Since Silverstripe CMS 4.3 you can use the React and GraphQL driven history viewer UI to display historic changes and comparisons for a versioned DataObject. This is automatically enabled for SiteTree objects and content blocks in [dnadesign/silverstripe-elemental](https://github.com/dnadesign/silverstripe-elemental). @@ -873,7 +873,7 @@ If you want to enable the history viewer for a custom versioned DataObject, you * Add a HistoryViewerField to the DataObject's `getCMSFields` **Please note:** these examples are given in the context of project-level customisation. You may need to adjust -the webpack configuration slightly for use in a module. They are also designed to be used on SilverStripe 4.3 or +the webpack configuration slightly for use in a module. They are also designed to be used on Silverstripe CMS 4.3 or later. For these examples, you can use this simple DataObject and create a ModelAdmin for it: diff --git a/docs/en/02_Developer_Guides/00_Model/11_Scaffolding.md b/docs/en/02_Developer_Guides/00_Model/11_Scaffolding.md index 5ce8f5f0f..cfa6b1ead 100644 --- a/docs/en/02_Developer_Guides/00_Model/11_Scaffolding.md +++ b/docs/en/02_Developer_Guides/00_Model/11_Scaffolding.md @@ -7,13 +7,13 @@ icon: hammer # Scaffolding The ORM already has a lot of information about the data represented by a `DataObject` through its `$db` property, so -SilverStripe will use that information to scaffold some interfaces. This is done though [FormScaffolder](api:SilverStripe\Forms\FormScaffolder) +Silverstripe CMS will use that information to scaffold some interfaces. This is done though [FormScaffolder](api:SilverStripe\Forms\FormScaffolder) to provide reasonable defaults based on the property type (e.g. a checkbox field for booleans). You can then further customise those fields as required. ## Form Fields -An example is `DataObject`, SilverStripe will automatically create your CMS interface so you can modify what you need. +An example is `DataObject`, Silverstripe CMS will automatically create your CMS interface so you can modify what you need. ```php use SilverStripe\ORM\DataObject; diff --git a/docs/en/02_Developer_Guides/00_Model/12_Indexes.md b/docs/en/02_Developer_Guides/00_Model/12_Indexes.md index 3cb6b7ae9..6c21b2b54 100644 --- a/docs/en/02_Developer_Guides/00_Model/12_Indexes.md +++ b/docs/en/02_Developer_Guides/00_Model/12_Indexes.md @@ -12,12 +12,12 @@ The addition of an indexes should be carefully evaluated as they can also increa `UPDATE`/`INSERT` and `DELETE`. An index on a column whose data is non unique will actually cost you performance. E.g. In most cases an index on `boolean` status flag, or `ENUM` state will not increase query performance. -It's important to find the right balance to achieve fast queries using the optimal set of indexes; For SilverStripe +It's important to find the right balance to achieve fast queries using the optimal set of indexes; For Silverstripe CMS applications it's a good practice to: - add indexes on columns which are frequently used in `filter`, `where` or `orderBy` statements - for these, only include indexes for columns which are the most restrictive (return the least number of rows) -The SilverStripe framework already places certain indexes for you by default: +The Silverstripe CMS framework already places certain indexes for you by default: - The primary key for each model has a `PRIMARY KEY` unique index - The `ClassName` column if your model inherits from `DataObject` - All relationships defined in the model have indexes for their `has_one` entity (for `many_many` relationships @@ -73,7 +73,7 @@ class MyTestObject extends DataObject ``` [alert] -Please note that if you have previously used the removed `value` key to define an index's contents, SilverStripe will +Please note that if you have previously used the removed `value` key to define an index's contents, Silverstripe CMS will now throw an error. Use `columns` instead. [/alert] diff --git a/docs/en/02_Developer_Guides/00_Model/How_Tos/Grouping_DataObject_Sets.md b/docs/en/02_Developer_Guides/00_Model/How_Tos/Grouping_DataObject_Sets.md index 5609cde74..b47dbb0ad 100644 --- a/docs/en/02_Developer_Guides/00_Model/How_Tos/Grouping_DataObject_Sets.md +++ b/docs/en/02_Developer_Guides/00_Model/How_Tos/Grouping_DataObject_Sets.md @@ -23,7 +23,7 @@ Similarly, the `GroupedBy()` method builds on this and returns the same data in This example deals with breaking up a [SS_List](api:SilverStripe\ORM\SS_List) into sub-headings by the first letter. -Let's say you have a set of Module objects, each representing a SilverStripe module, and you want to output a list of +Let's say you have a set of Module objects, each representing a Silverstripe CMS module, and you want to output a list of these in alphabetical order, with each letter as a heading; something like the following list: * B diff --git a/docs/en/02_Developer_Guides/00_Model/index.md b/docs/en/02_Developer_Guides/00_Model/index.md index 1d17da604..e828140f8 100644 --- a/docs/en/02_Developer_Guides/00_Model/index.md +++ b/docs/en/02_Developer_Guides/00_Model/index.md @@ -1,11 +1,11 @@ --- title: Model and Databases -summary: Learn how SilverStripe manages database tables, ways to query your database and how to publish data. -introduction: This guide will cover how to create and manipulate data within SilverStripe and how to use the ORM (Object Relational Model) to query data. +summary: Learn how Silverstripe CMS manages database tables, ways to query your database and how to publish data. +introduction: This guide will cover how to create and manipulate data within Silverstripe CMS and how to use the ORM (Object Relational Model) to query data. icon: database --- -In SilverStripe, application data will be represented by a [DataObject](api:SilverStripe\ORM\DataObject) class. A `DataObject` subclass defines the +In Silverstripe CMS, application data will be represented by a [DataObject](api:SilverStripe\ORM\DataObject) class. A `DataObject` subclass defines the data columns, relationships and properties of a particular data record. For example, [Member](api:SilverStripe\Security\Member) is a `DataObject` which stores information about a person, CMS user or mail subscriber. @@ -13,4 +13,4 @@ which stores information about a person, CMS user or mail subscriber. ## How to's -[CHILDREN Folder="How_Tos"] \ No newline at end of file +[CHILDREN Folder="How_Tos"] diff --git a/docs/en/02_Developer_Guides/01_Templates/01_Syntax.md b/docs/en/02_Developer_Guides/01_Templates/01_Syntax.md index 7e7557f27..41d8eb101 100644 --- a/docs/en/02_Developer_Guides/01_Templates/01_Syntax.md +++ b/docs/en/02_Developer_Guides/01_Templates/01_Syntax.md @@ -10,7 +10,7 @@ A template can contain any markup language (e.g HTML, CSV, JSON..) and before be processed through [SSViewer](api:SilverStripe\View\SSViewer). This process replaces placeholders such as `$Var` with real content from your [model](../model) and allows you to define logic controls like `<% if $Var %>`. -An example of a SilverStripe template is below: +An example of a Silverstripe CMS template is below: **app/templates/Page.ss** @@ -50,7 +50,7 @@ text-based format. ## Template file location -SilverStripe templates are plain text files that have an `.ss` extension and are located within the `templates` directory of +Silverstripe CMS templates are plain text files that have an `.ss` extension and are located within the `templates` directory of a module, theme, or your `app/` folder. By default, templates will have the same name as the class they are used to render. So, your `Page` class will @@ -236,7 +236,7 @@ You can use inequalities like `<`, `<=`, `>`, `>=` to compare numbers. ## Includes -Within SilverStripe templates we have the ability to include other templates using the `<% include %>` tag. The includes +Within Silverstripe CMS templates we have the ability to include other templates using the `<% include %>` tag. The includes will be searched for using the same filename look-up rules as a regular template. However in the case of the include tag an additional `Includes` directory will be inserted into the resolved path just prior to the filename. @@ -564,7 +564,7 @@ Using standard HTML comments is supported. These comments will be included in th $EditForm ``` -However you can also use special SilverStripe comments which will be stripped out of the published site. This is useful +However you can also use special Silverstripe CMS comments which will be stripped out of the published site. This is useful for adding notes for other developers but for things you don't want published in the public html. ```ss diff --git a/docs/en/02_Developer_Guides/01_Templates/02_Common_Variables.md b/docs/en/02_Developer_Guides/01_Templates/02_Common_Variables.md index 36bfea77b..2a1a20fa8 100644 --- a/docs/en/02_Developer_Guides/01_Templates/02_Common_Variables.md +++ b/docs/en/02_Developer_Guides/01_Templates/02_Common_Variables.md @@ -5,7 +5,7 @@ summary: Some of the common variables and methods your templates can use, includ # Common Variables -The page below describes a few of common variables and methods you'll see in a SilverStripe template. This is not an +The page below describes a few of common variables and methods you'll see in a Silverstripe CMS template. This is not an exhaustive list. From your template you can call any method, database field, or relation on the object which is currently in scope as well as its subclasses or extensions. @@ -47,7 +47,7 @@ to locate your site’s images and css files. It renders in the template as `` [alert] -A `<% base_tag %>;` is nearly always required or assumed by SilverStripe to exist. +A `<% base_tag %>;` is nearly always required or assumed by Silverstripe CMS to exist. [/alert] ## CurrentMember @@ -67,7 +67,7 @@ $Title $MenuTitle ``` -Most objects within SilverStripe will respond to `$Title` (i.e they should have a `Title` database field or at least a +Most objects within Silverstripe CMS will respond to `$Title` (i.e they should have a `Title` database field or at least a `getTitle()` method). The CMS module in particular provides two fields to label a page: `Title` and `MenuTitle`. `Title` is the title @@ -127,14 +127,14 @@ By default `$MetaTags` renders: ```ss Title of the Page - + ``` `$MetaTags(false)` will render ```ss - + ``` @@ -172,7 +172,7 @@ public function MetaComponents() .. ``` -All objects that could be accessible in SilverStripe should define a `Link` method and an `AbsoluteLink` method. Link +All objects that could be accessible in Silverstripe CMS should define a `Link` method and an `AbsoluteLink` method. Link returns the relative URL for the object and `AbsoluteLink` outputs your full website address along with the relative link. @@ -382,7 +382,7 @@ $Form ``` A page will normally contain some content and potentially a form of some kind. For example, the log-in page has a -SilverStripe log-in form. If you are on such a page, the `$Form` variable will contain the HTML content of the form. +Silverstripe CMS log-in form. If you are on such a page, the `$Form` variable will contain the HTML content of the form. Placing it just below `$Content` is a good default. diff --git a/docs/en/02_Developer_Guides/01_Templates/03_Requirements.md b/docs/en/02_Developer_Guides/01_Templates/03_Requirements.md index fa26426e9..b6b69b71b 100644 --- a/docs/en/02_Developer_Guides/01_Templates/03_Requirements.md +++ b/docs/en/02_Developer_Guides/01_Templates/03_Requirements.md @@ -11,20 +11,20 @@ coding any references in the `` tag of your template, as it enables a more [Requirements](api:SilverStripe\View\Requirements) class. The examples below are using certain folder naming conventions (CSS files in `css/`, JavaScript files in `javascript/`). -SilverStripe core modules like `cms` use a different naming convention (CSS and JavaScript files in `client/src/`). +Silverstripe CMS core modules like `cms` use a different naming convention (CSS and JavaScript files in `client/src/`). The `Requirements` class can work with arbitrary file paths. ## Exposing static assets -Before requiring static asset files in PHP code or in a template, those assets need to be "exposed". This process allows SilverStripe projects and SilverStripe modules to make static asset files available via the web server from locations that would otherwise be blocked from web server access, such as the `vendor` folder. +Before requiring static asset files in PHP code or in a template, those assets need to be "exposed". This process allows Silverstripe CMS projects and Silverstripe CMS modules to make static asset files available via the web server from locations that would otherwise be blocked from web server access, such as the `vendor` folder. ### Configuring your project "exposed" folders -Exposed assets are made available in your web root in a dedicated "resources" directory. Prior to SilverStripe 4.4, the name of this directory was hardcoded to `resources`. In SilverStripe 4.4 and above, the name of the resources directory can be configured by defining the `extra.resources-dir` key in your `composer.json`. SilverStripe projects created from `silverstripe/installer` 4.4 and above will automatically be configured to use `_resources` as their resource directory. +Exposed assets are made available in your web root in a dedicated "resources" directory. Prior to Silverstripe CMS 4.4, the name of this directory was hardcoded to `resources`. In Silverstripe CMS 4.4 and above, the name of the resources directory can be configured by defining the `extra.resources-dir` key in your `composer.json`. Silverstripe CMS projects created from `silverstripe/installer` 4.4 and above will automatically be configured to use `_resources` as their resource directory. Each folder that needs to be exposed must be entered under the `extra.expose` key in your `composer.json` file. Module developers should use a path relative to the root of their module (don't include the "vendor/package-developer/package-name" path). -This is a sample SilverStripe project `composer.json` file configured to expose some assets. +This is a sample Silverstripe CMS project `composer.json` file configured to expose some assets. ```json { @@ -45,11 +45,11 @@ This is a sample SilverStripe project `composer.json` file configured to expose Files contained inside the `app/client/dist` and `app/images` will be made publicly available under the `_resources` directory. -SilverStripe projects should not track the "resources" directory in their source control system. +Silverstripe CMS projects should not track the "resources" directory in their source control system. ### Exposing assets in the web root {#exposing-assets-webroot} -SilverStripe projects ship with [silverstripe/vendor-plugin](https://github.com/silverstripe/vendor-plugin). +Silverstripe CMS projects ship with [silverstripe/vendor-plugin](https://github.com/silverstripe/vendor-plugin). This Composer plugin automatically tries to expose assets from your project and installed modules after installation, or after an update. Developers can explicitly expose static assets by calling `composer vendor-expose`. This is necessary after updating your `resources-dir` or `expose` configuration in your `composer.json` file. @@ -421,14 +421,14 @@ careful when messing with the order of requirements. ## Javascript placement -By default, SilverStripe includes all Javascript files at the bottom of the page body, unless there's another script +By default, Silverstripe CMS includes all Javascript files at the bottom of the page body, unless there's another script already loaded, then, it's inserted before the first `