This PR fixed unable to create subsite problm.
I was unable to create a subsite, because of no themes been shown in Theme dropdown menu.
How to test:
1> Use composer to install a fresh copy of Silverstripe 3.2
2> Use composer to install subsite module.
3> Try to create a subsite.
4> No themes loaded into Theme dropdown menu.
5> Apply this PR.
6> fresh page / or dev/build, now, themes loaded into The dropdown menu.
When trying to switch to a different subsite from a page's editing view, it wouldn't switch. This was partly due to a $record always existing due to the homepage fallback on currentPageID : https://github.com/silverstripe/silverstripe-cms/blob/3.1/code/controllers/CMSMain.php#L816
So as currentPage() couldn't actually be used to test for the existance of a current page, I've added in a check for isset($this->owner->urlParams['ID']).
I've also moved the check for $_GET['SubsiteID’] which indicated a forced subsite switch (eg. via the dropdown switcher) above the check for a current page, as it should take precedence, and it wasn't being run when both conditions matched causing the subsite not to change.
Tested changing subsites from /admin/pages, from page edit view, from a page edit URL, and from other CMS sections such as Files and Security, and all seems to be working perfectly now.
This isn't used, according to the description it would limit the list
of subsites you can choose to apply a File/Folder to. However, this
dropdown is shown to the user based on whether they have access to
that subsite, so this unused permission code isn't needed.
PWC identified an issue with the subsites module that would allow someone with authenticated access to attack other CMS users, such as "stealing the session ID and hijacking an authenticated user's session".
I can't imagine a case where HTML would ever be allowed in the subdomain of a website, so it's a good practice to strip it out anyway.
Steps to reproduce the original issue:
1. Enter a subsite name and mark as the default site.
2. Add a new domain named <script>alert(2)</script> and mark it as primary
3. Switch to the new subsite.
4. Make a new Page. This will execute a javascript alert containing "2".
MINOR update documentation for onBeforeWrite()
MINOR add @property attributes into docblock
When trying to switch to a different subsite from a page's editing view, it wouldn't switch. This was partly due to a $record always existing due to the homepage fallback on currentPageID : https://github.com/silverstripe/silverstripe-cms/blob/3.1/code/controllers/CMSMain.php#L816
So as currentPage() couldn't actually be used to test for the existance of a current page, I've added in a check for isset($this->owner->urlParams['ID']).
I've also moved the check for $_GET['SubsiteID’] which indicated a forced subsite switch (eg. via the dropdown switcher) above the check for a current page, as it should take precedence, and it wasn't being run when both conditions matched causing the subsite not to change.
Tested changing subsites from /admin/pages, from page edit view, from a page edit URL, and from other CMS sections such as Files and Security, and all seems to be working perfectly now.
This problem manifests when a GridField-managed relationship tries to
create an object that references the container from canEdit - the
container in this case has empty fields.
An example of that is a HomePage with CarouselItem - if the
CarouselItem::canEdit tries to call $this->Page()->canEdit(), the "Page"
will be a dummy object, not the actual instance of the HomePage that's
doing the manipulation.
This is similar to the behaviour of SiteTree::canEdit, which solves
this situation by falling back to "return
$this->getSiteConfig()->canEdit($member);"
‘CMS_ACCESS_LeftAndMain’ is used by the PermissionCheckboxSetField to allow
applicable Members to access all CMS sections. There are then further
permissions to restrict the Members (e.g. ‘CMS_ACCESS_LeftAndMain’ will give you
access to the ‘Pages’ section, but you still need the ‘Edit any page’ permission
to actually edit anything).
This patch ensures that the subsites module follows those permissions, and
doesn’t unnecessarily deny permission to legitimate users.
Previously, only the global ‘ADMIN’ permission was allowing users to bypass the
stricter Permission check. We also need to allow the ‘CMS_ACCESS_LeftAndMain’
permission to bypass this check, as otherwise a user who is in a Group with the
‘Access to all CMS sections’ permission set (which only sets the
CMS_ACCESS_LeftAndMain permission code and no others) would be denied access to
the CMS for that sub site.
