dsds
October 7, 2026, 1:16am
1
Thank you for your continued guidance.
Is this a bug?
I apologize if this topic has already been discussed.
I would appreciate your advice.
dsds
October 7, 2026, 4:27am
2
The issue persisted even after updating to the latest version, Concrete CMS 9.5.5.
This has been verified as a bug in Github
opened 08:54PM - 15 Sep 26 UTC
Type:Bug
Bug:Reproduceable:Yes
### Affected Version of Concrete CMS
9.x
### Description
Editing a block that… was pasted from the clipboard/scrapbook (i.e. a core_scrapbook_display proxy block whose original block still exists) throws an uncaught fatal error and returns the dreaded 500 error instead of opening the edit dialog.
**Stack trace error:**
Error: Call to a member function isMasterCollection() on null
in /concrete/src/Permission/Response/BlockResponse.php (line 35)
BlockResponse->validate() in concrete/src/Permission/Response/BlockResponse.php (line 17)
BlockResponse->canWrite() in concrete/src/Permission/Checker.php (line 52)
Checker->__call() in concrete/blocks/core_scrapbook_display/edit.php (line 14)
### How to reproduce
1.) Add any block (e.g. a Content block) to a page.
2.) Copy it to the clipboard/scrapbook and paste it into a different area (creating a core_scrapbook_display proxy block pointing at the original via bOriginalID).
3.) Attempt to edit the pasted block (open its edit dialog).
### Possible Solution
concrete/blocks/core_scrapbook_display/edit.php loads the original block via Block::getByID($bOriginalID) and immediately runs a permission check against it, but never associates that block object with a collection:
```
$bo = \Concrete\Core\Block\Block::getByID($bOriginalID);
$bp = new \Concrete\Core\Permission\Checker($bo);
$bo->setProxyBlock($b);
if ($bp->canWrite()) {
```
BlockResponse::validate() calls $this->object->getBlockCollectionObject(), which returns null because the block was never given a collection context, causing the subsequent ->isMasterCollection() call to be fatal.
By contrast, core_scrapbook_display/view.php (which works correctly) does associate a collection before use:
```
$_bx = \Concrete\Core\Block\Block::getByID($bOriginalID);
if (is_object($_bx)) {
$_bx->setBlockAreaObject($area);
$c = \Concrete\Core\Page\Page::getCurrentPage();
$_bx->setProxyBlock($b);
$_bx->loadNewCollection($c);
...
```
edit.php is missing the equivalent setBlockAreaObject() / loadNewCollection() calls (and the is_object($bo) null guard that view.php also has).
**Proposed fix:**
Bring edit.php in line with view.php:
```
<?php
use Concrete\Core\Block\View\BlockView;
defined('C5_EXECUTE') or die('Access Denied.');
/** @var \Concrete\Core\Block\Block $bo */
/** @var int $bOriginalID */
/** @var \Concrete\Core\Block\Block $b */
/** @var BlockView $view */
$bo = \Concrete\Core\Block\Block::getByID($bOriginalID);
if (is_object($bo)) {
$c = \Concrete\Core\Page\Page::getCurrentPage();
$bo->setBlockAreaObject($view->getAreaObject());
$bo->setProxyBlock($b);
$bo->loadNewCollection($c);
$bp = new \Concrete\Core\Permission\Checker($bo);
if ($bp->canWrite()) {
$bv = new BlockView($bo);
?>
<div class="ccm-ui">
<div class="alert alert-info">
<?= t('This block was copied from another location. Editing it will create a new instance of it.') ?>
</div>
</div>
<?php
$bv->setAreaObject($view->getAreaObject());
$bv->addScopeItems($view->getScopeItems());
$bv->render('edit');
}
}
```
I verified this fix on a live install of 9.5.4, this resolves the fatal error and the block edits correctly.
(Note for anyone else trying this as an override: if "Override Caching" is enabled (Dashboard → System & Settings → Optimization → Cache & Speed Settings), it needs to be disabled or cleared for the override to actually take effect.)
### Additional Context
_No response_
dsds
October 7, 2026, 5:23am
4
Thank you.
dsds
October 7, 2026, 1:30pm
6
I will attempt to override the file.
