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
content instructions
- Adding documentation on using the ‘Disallow page types’ feature.
- Fix links
- Re-word documentation to clarify important points.
- Add new content from Sig, tidy up existing content.
- MINOR: Formatting update & draw attention to links at the bottom.
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.
From @hafriedlander:
Hi. Sorry, I was going to have a look at this on the back of that issue @chillu raised but you beat me to it. There's a couple of edge cases that aren't obvious that come from ChangeTrackerOptions being an object, and might need an Entwine API extension to fix nicely.
Objects in entwine properties are a bit dangerous, because javascript always passes them by reference instead of cloning them. Entwine also doesn't clone them when using them as default values.
The result is that this patch will repeatedly add that selector to the result every time getChangeTrackerOptions is called, so it'll be there once the first time it's called, twice the second, etc.
The right fix at the moment would look like:
```php
$('.cms-edit-form').entwine({
getChangeTrackerOptions: function() {
// Figure out if we're still returning the default value
var isDefault = (this.entwineData('ChangeTrackerOptions') === undefined);
// Get the current options
var opts = this._super();
if (isDefault) {
// If it is the default then...
// clone the object (so we don't modify the original),
var opts = $.extend({}, opts);
// modify it,
opts.ignoreFieldSelector +=', input[name=IsSubsite]';
// then set the clone as the value on this element
// (so next call to this method gets this same clone)
this.setChangeTrackerOptions(opts);
}
return opts;
});
```
This is super ugly though, non-obvious, and could maybe be handled better in the entwine layer.
See https://github.com/silverstripe/silverstripe-subsites/pull/125
