From 30ac551639bc786e3e9bfdb39dc175fe65073dfd Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E2=80=9Cmlindenhofer=E2=80=9D?= Date: Tue, 7 Mar 2023 16:33:03 +0100 Subject: [PATCH 1/5] replace documentations fluent solution with another, as yml-config variable is not existing anymore --- README.md | 112 ++++++++++++++++++++++++++++-------------------------- 1 file changed, 58 insertions(+), 54 deletions(-) diff --git a/README.md b/README.md index 69d150fb..42c175f4 100644 --- a/README.md +++ b/README.md @@ -22,38 +22,38 @@ permissions" will imply that the person will likely be able to escalate his/her For user documentation please see: - 1. [Setting up subsites](docs/en/userguide/set_up.md) - 1. [Working with subsites](docs/en/userguide/working_with.md) +1. [Setting up subsites](docs/en/userguide/set_up.md) +1. [Working with subsites](docs/en/userguide/working_with.md) ## Features & limitations ### Features: - * Each subsite appears as a standalone website from a users prospective - * No need to duplicate existing code as all subsites use the same codebase as the main site - * You can set individual permissions on each subsite domain name - * Ability to copy a page and its content from the main site into a subsite - * Create translations of subsite pages - * Schedule the publishing of subsite pages - * The database is shared between subsites (meaning duplicating content is easy) - * When recovering from a disaster it's much easier to bring up a new copy of a single environment with 100 subsites than it is to bring up 100 environments. +* Each subsite appears as a standalone website from a users prospective +* No need to duplicate existing code as all subsites use the same codebase as the main site +* You can set individual permissions on each subsite domain name +* Ability to copy a page and its content from the main site into a subsite +* Create translations of subsite pages +* Schedule the publishing of subsite pages +* The database is shared between subsites (meaning duplicating content is easy) +* When recovering from a disaster it's much easier to bring up a new copy of a single environment with 100 subsites than it is to bring up 100 environments. ### Limitations: - * Subsites are usually accessed via their own separate domains. - In order to allow efficient cross-subsite CMS editing, - they can also be accessed via URL parameters rather than domain maps. - This can weaken domain-specific security controls in your environment - such as domain-specific IP whitelists, firewall rules or business logic. - * Each subsite domain name has to be set up on the server first, and DNS records need to be updated as appropriate. - * A subsite cannot use a different codebase as the main site, they are intrinsically tied - * However, you can remove page types from a subsite when creating the subsite - [see the setup documentation for further details](docs/en/userguide/set_up.md) - * The only code a developer can edit between subsites is the theme - * The separation between subsites in the CMS needs to be seen as cosmetic, and mostly applicable to the "Pages" and "Files" sections of the CMS. - * All subsites run in the same process space and data set. Therefore if an outage affects one subsite it will affect all subsites, and if bad code or hardware corrupts one subsite's data, it's very likely that it has corrupted all subsite data. - * This principle applies to application error, security vulnerabilities and high levels of traffic - * It is not currently possible to backup or restore the data from a single subsite. - * It is awkward (but not impossible) to have separate teams of developers working on different subsites - primarily because of the level of collaboration needed. It is more suited to the same group of developers being responsible for all of the subsites. +* Subsites are usually accessed via their own separate domains. + In order to allow efficient cross-subsite CMS editing, + they can also be accessed via URL parameters rather than domain maps. + This can weaken domain-specific security controls in your environment + such as domain-specific IP whitelists, firewall rules or business logic. +* Each subsite domain name has to be set up on the server first, and DNS records need to be updated as appropriate. +* A subsite cannot use a different codebase as the main site, they are intrinsically tied + * However, you can remove page types from a subsite when creating the subsite - [see the setup documentation for further details](docs/en/userguide/set_up.md) +* The only code a developer can edit between subsites is the theme +* The separation between subsites in the CMS needs to be seen as cosmetic, and mostly applicable to the "Pages" and "Files" sections of the CMS. +* All subsites run in the same process space and data set. Therefore if an outage affects one subsite it will affect all subsites, and if bad code or hardware corrupts one subsite's data, it's very likely that it has corrupted all subsite data. + * This principle applies to application error, security vulnerabilities and high levels of traffic +* It is not currently possible to backup or restore the data from a single subsite. +* It is awkward (but not impossible) to have separate teams of developers working on different subsites - primarily because of the level of collaboration needed. It is more suited to the same group of developers being responsible for all of the subsites. If more isolation of code, security, or performance is needed, then consider running multiple separate installations (e.g. on separate servers). @@ -101,54 +101,54 @@ In some Browsers the SubsiteID is visible if you hover over the "Edit" link in t ### Subsite-specific themes -Download a second theme from http://www.silverstripe.com/themes/ and put it in your themes folder. Open -admin/subsites?flush=1 and select one of your subsites from the menu on the bottom-left. You should see a -Theme dropdown in the subsite details, and it should list both your original theme and the new theme. Select the new +Download a second theme from http://www.silverstripe.com/themes/ and put it in your themes folder. Open +admin/subsites?flush=1 and select one of your subsites from the menu on the bottom-left. You should see a +Theme dropdown in the subsite details, and it should list both your original theme and the new theme. Select the new theme in the dropdown. Now, this subsite will use a different theme from the main site. #### Cascading themes -In Silverstripe 4 themes will resolve theme files by looking through a list of themes (see the documentation on +In Silverstripe 4 themes will resolve theme files by looking through a list of themes (see the documentation on [creating your own theme](https://docs.silverstripe.org/en/4/developer_guides/templates/themes/#developing-your-own-theme)). -Subsites will inherit this configuration for the order of themes. Choosing a theme for a Subsite will set the list of +Subsites will inherit this configuration for the order of themes. Choosing a theme for a Subsite will set the list of themes to that chosen theme, and all themes that are defined below the chosen theme in priority. For example, with a theme configuration as follows: ```yaml SilverStripe\View\SSViewer: - themes: - - '$public' - - 'my-theme' - - 'watea' - - 'starter' - - '$default' + themes: + - '$public' + - 'my-theme' + - 'watea' + - 'starter' + - '$default' ``` Choosing `watea` in your Subsite will create a cascading config as follows: ```yaml themes: - - 'watea' - - '$public' - - 'starter' - - '$default' + - 'watea' + - '$public' + - 'starter' + - '$default' ``` -You may also completely define your own cascading theme lists for CMS users to choose as theme options for their +You may also completely define your own cascading theme lists for CMS users to choose as theme options for their subsite: ```yaml SilverStripe\Subsites\Service\ThemeResolver: - theme_options: - normal: - - '$public' - - 'watea' - - 'starter' - - '$default' - special: - - 'my-theme' - - 'starter' - - '$default' + theme_options: + normal: + - '$public' + - 'watea' + - 'starter' + - '$default' + special: + - 'my-theme' + - 'starter' + - '$default' ``` ### Limit available themes for a subsite @@ -220,11 +220,15 @@ or by defining the subsiteCMSShowInMenu function in your admin: ### Using Subsites in combination with Fluent -When using Subsites in combination with Fluent module, the Subsites module sets the i18n locale to the language defined in the current Subsite. When this behaviour is not desired and you need to use the locale in FluentState use the following setting in your yml config file: +When using Subsites in combination with Fluent module, the Subsites module sets the i18n locale to the language defined in the current Subsite. When this behaviour is not desired and you need to use the locale in FluentState you can set the current Fluent locale in your PageController like this: -```yaml - SilverStripe\Subsites\Extensions\SiteTreeSubsites: - ignore_subsite_locale: true +``` +:::php + protected function init(){ + if ($this->dataRecord->SubsiteID !== 0){ + i18n::set_locale(FluentState::singleton()->getLocale()); + } + } ``` ### Public display of a subsite From 3882b01602256007e822444d4cba43d662d7d217 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E2=80=9Cmlindenhofer=E2=80=9D?= Date: Tue, 7 Mar 2023 16:35:31 +0100 Subject: [PATCH 2/5] modify adpated part --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index 42c175f4..beeafdb9 100644 --- a/README.md +++ b/README.md @@ -222,6 +222,7 @@ or by defining the subsiteCMSShowInMenu function in your admin: When using Subsites in combination with Fluent module, the Subsites module sets the i18n locale to the language defined in the current Subsite. When this behaviour is not desired and you need to use the locale in FluentState you can set the current Fluent locale in your PageController like this: +*PageController.php* ``` :::php protected function init(){ From 7017c1c6f8c5e879dbcac154549585553b4baa4a Mon Sep 17 00:00:00 2001 From: Martina Lindenhofer <68067510+MLindenhofer@users.noreply.github.com> Date: Fri, 6 Oct 2023 13:30:08 +0200 Subject: [PATCH 3/5] Update README.md revert changes as suggested --- README.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index beeafdb9..62f68f42 100644 --- a/README.md +++ b/README.md @@ -223,9 +223,9 @@ or by defining the subsiteCMSShowInMenu function in your admin: When using Subsites in combination with Fluent module, the Subsites module sets the i18n locale to the language defined in the current Subsite. When this behaviour is not desired and you need to use the locale in FluentState you can set the current Fluent locale in your PageController like this: *PageController.php* -``` -:::php - protected function init(){ +```php + protected function init() + { if ($this->dataRecord->SubsiteID !== 0){ i18n::set_locale(FluentState::singleton()->getLocale()); } From 60d75535c2331c002c142e4d8d1087d7e11e3042 Mon Sep 17 00:00:00 2001 From: Martina Lindenhofer <68067510+MLindenhofer@users.noreply.github.com> Date: Fri, 6 Oct 2023 13:39:56 +0200 Subject: [PATCH 4/5] Update README.md Revert part 2 --- README.md | 94 +++++++++++++++++++++++++++---------------------------- 1 file changed, 47 insertions(+), 47 deletions(-) diff --git a/README.md b/README.md index 62f68f42..37cf9a64 100644 --- a/README.md +++ b/README.md @@ -29,31 +29,31 @@ For user documentation please see: ### Features: -* Each subsite appears as a standalone website from a users prospective -* No need to duplicate existing code as all subsites use the same codebase as the main site -* You can set individual permissions on each subsite domain name -* Ability to copy a page and its content from the main site into a subsite -* Create translations of subsite pages -* Schedule the publishing of subsite pages -* The database is shared between subsites (meaning duplicating content is easy) -* When recovering from a disaster it's much easier to bring up a new copy of a single environment with 100 subsites than it is to bring up 100 environments. + * Each subsite appears as a standalone website from a users prospective + * No need to duplicate existing code as all subsites use the same codebase as the main site + * You can set individual permissions on each subsite domain name + * Ability to copy a page and its content from the main site into a subsite + * Create translations of subsite pages + * Schedule the publishing of subsite pages + * The database is shared between subsites (meaning duplicating content is easy) + * When recovering from a disaster it's much easier to bring up a new copy of a single environment with 100 subsites than it is to bring up 100 environments. ### Limitations: -* Subsites are usually accessed via their own separate domains. - In order to allow efficient cross-subsite CMS editing, - they can also be accessed via URL parameters rather than domain maps. - This can weaken domain-specific security controls in your environment - such as domain-specific IP whitelists, firewall rules or business logic. -* Each subsite domain name has to be set up on the server first, and DNS records need to be updated as appropriate. -* A subsite cannot use a different codebase as the main site, they are intrinsically tied - * However, you can remove page types from a subsite when creating the subsite - [see the setup documentation for further details](docs/en/userguide/set_up.md) -* The only code a developer can edit between subsites is the theme -* The separation between subsites in the CMS needs to be seen as cosmetic, and mostly applicable to the "Pages" and "Files" sections of the CMS. -* All subsites run in the same process space and data set. Therefore if an outage affects one subsite it will affect all subsites, and if bad code or hardware corrupts one subsite's data, it's very likely that it has corrupted all subsite data. - * This principle applies to application error, security vulnerabilities and high levels of traffic -* It is not currently possible to backup or restore the data from a single subsite. -* It is awkward (but not impossible) to have separate teams of developers working on different subsites - primarily because of the level of collaboration needed. It is more suited to the same group of developers being responsible for all of the subsites. + * Subsites are usually accessed via their own separate domains. + In order to allow efficient cross-subsite CMS editing, + they can also be accessed via URL parameters rather than domain maps. + This can weaken domain-specific security controls in your environment + such as domain-specific IP whitelists, firewall rules or business logic. + * Each subsite domain name has to be set up on the server first, and DNS records need to be updated as appropriate. + * A subsite cannot use a different codebase as the main site, they are intrinsically tied + * However, you can remove page types from a subsite when creating the subsite - [see the setup documentation for further details](docs/en/userguide/set_up.md) + * The only code a developer can edit between subsites is the theme + * The separation between subsites in the CMS needs to be seen as cosmetic, and mostly applicable to the "Pages" and "Files" sections of the CMS. + * All subsites run in the same process space and data set. Therefore if an outage affects one subsite it will affect all subsites, and if bad code or hardware corrupts one subsite's data, it's very likely that it has corrupted all subsite data. + * This principle applies to application error, security vulnerabilities and high levels of traffic + * It is not currently possible to backup or restore the data from a single subsite. + * It is awkward (but not impossible) to have separate teams of developers working on different subsites - primarily because of the level of collaboration needed. It is more suited to the same group of developers being responsible for all of the subsites. If more isolation of code, security, or performance is needed, then consider running multiple separate installations (e.g. on separate servers). @@ -101,37 +101,37 @@ In some Browsers the SubsiteID is visible if you hover over the "Edit" link in t ### Subsite-specific themes -Download a second theme from http://www.silverstripe.com/themes/ and put it in your themes folder. Open -admin/subsites?flush=1 and select one of your subsites from the menu on the bottom-left. You should see a -Theme dropdown in the subsite details, and it should list both your original theme and the new theme. Select the new +Download a second theme from http://www.silverstripe.com/themes/ and put it in your themes folder. Open +admin/subsites?flush=1 and select one of your subsites from the menu on the bottom-left. You should see a +Theme dropdown in the subsite details, and it should list both your original theme and the new theme. Select the new theme in the dropdown. Now, this subsite will use a different theme from the main site. #### Cascading themes -In Silverstripe 4 themes will resolve theme files by looking through a list of themes (see the documentation on +In Silverstripe 4 themes will resolve theme files by looking through a list of themes (see the documentation on [creating your own theme](https://docs.silverstripe.org/en/4/developer_guides/templates/themes/#developing-your-own-theme)). -Subsites will inherit this configuration for the order of themes. Choosing a theme for a Subsite will set the list of +Subsites will inherit this configuration for the order of themes. Choosing a theme for a Subsite will set the list of themes to that chosen theme, and all themes that are defined below the chosen theme in priority. For example, with a theme configuration as follows: ```yaml SilverStripe\View\SSViewer: - themes: - - '$public' - - 'my-theme' - - 'watea' - - 'starter' - - '$default' + themes: + - '$public' + - 'my-theme' + - 'watea' + - 'starter' + - '$default' ``` Choosing `watea` in your Subsite will create a cascading config as follows: ```yaml themes: - - 'watea' - - '$public' - - 'starter' - - '$default' + - 'watea' + - '$public' + - 'starter' + - '$default' ``` You may also completely define your own cascading theme lists for CMS users to choose as theme options for their @@ -139,16 +139,16 @@ subsite: ```yaml SilverStripe\Subsites\Service\ThemeResolver: - theme_options: - normal: - - '$public' - - 'watea' - - 'starter' - - '$default' - special: - - 'my-theme' - - 'starter' - - '$default' + theme_options: + normal: + - '$public' + - 'watea' + - 'starter' + - '$default' + special: + - 'my-theme' + - 'starter' + - '$default' ``` ### Limit available themes for a subsite From adfb9554cdb2ced873d56b8a6623905ce1cae36e Mon Sep 17 00:00:00 2001 From: Martina Lindenhofer <68067510+MLindenhofer@users.noreply.github.com> Date: Fri, 6 Oct 2023 13:41:30 +0200 Subject: [PATCH 5/5] Update README.md last revert --- README.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index 37cf9a64..cb21f621 100644 --- a/README.md +++ b/README.md @@ -22,8 +22,8 @@ permissions" will imply that the person will likely be able to escalate his/her For user documentation please see: -1. [Setting up subsites](docs/en/userguide/set_up.md) -1. [Working with subsites](docs/en/userguide/working_with.md) + 1. [Setting up subsites](docs/en/userguide/set_up.md) + 1. [Working with subsites](docs/en/userguide/working_with.md) ## Features & limitations @@ -134,7 +134,7 @@ themes: - '$default' ``` -You may also completely define your own cascading theme lists for CMS users to choose as theme options for their +You may also completely define your own cascading theme lists for CMS users to choose as theme options for their subsite: ```yaml