Access denied errors happening a lot with 5.5.x?
Permalink 1 user found helpful
Hi all,
just a bit of a question. In the past I remember occasionally getting random 'access denied' messages when editing areas. After editing or adding a block, it would display 'access denied' in the space where the block should be. Doing a page refresh would fix things (without losing changes), but it would be a bit confusing.
With 5.5.x, and in particular the introduction of global areas, my partner and I are coming across them a lot more, across a range of different hosts, as well as our local environment. They seem to appear on fresh systems as well as upgraded ones. The only pattern we've seen is that it happens a lot of global areas. It's harmless, but could be quite confusing for clients.
Is anyone else coming across the same issue?
I had a look in the bug tracker, but didn't spot anything.
Cheers
-Ryan
just a bit of a question. In the past I remember occasionally getting random 'access denied' messages when editing areas. After editing or adding a block, it would display 'access denied' in the space where the block should be. Doing a page refresh would fix things (without losing changes), but it would be a bit confusing.
With 5.5.x, and in particular the introduction of global areas, my partner and I are coming across them a lot more, across a range of different hosts, as well as our local environment. They seem to appear on fresh systems as well as upgraded ones. The only pattern we've seen is that it happens a lot of global areas. It's harmless, but could be quite confusing for clients.
Is anyone else coming across the same issue?
I had a look in the bug tracker, but didn't spot anything.
Cheers
-Ryan
It's a real funny one... I thought it might be caching too, but it happens for me on some sites with caching turned off completely.
The pattern I've got it to repeatedly throw this error is when:
- I first start editing a page (so not after other edits)
- I add a new block (say Content), to a Sitewide area. The area may or may not have existing blocks... OR.. I edit an existing block in a Sitewide area.
As you've said, if I just refresh the page, the correct content appears and nothing is lost as such. After this, I don't get it to error with subsequent edits or block adds, anywhere on a page.
It's something to do with when the first edit/add to a page is made to a Sitewide area. Interestingly, if I first edit a normal area, then try and edit the sitewide area, I have no problems.
When the error occurs, through the web inspector I can see that /index.php/tools/required/edit_block_popup simply returns the text 'Access denied'. So I'd suggest that this is something server side and not a javascript bug. I might dig around myself.
The pattern I've got it to repeatedly throw this error is when:
- I first start editing a page (so not after other edits)
- I add a new block (say Content), to a Sitewide area. The area may or may not have existing blocks... OR.. I edit an existing block in a Sitewide area.
As you've said, if I just refresh the page, the correct content appears and nothing is lost as such. After this, I don't get it to error with subsequent edits or block adds, anywhere on a page.
It's something to do with when the first edit/add to a page is made to a Sitewide area. Interestingly, if I first edit a normal area, then try and edit the sitewide area, I have no problems.
When the error occurs, through the web inspector I can see that /index.php/tools/required/edit_block_popup simply returns the text 'Access denied'. So I'd suggest that this is something server side and not a javascript bug. I might dig around myself.
In case it helps anyone who might be able to look at this, I tried in edit_block_popup.php commenting out the lines that check for permissions and spits out the Access Denied error... so,
Instead of access denied, I get:
Fatal error: Call to a member function isAliasOfMasterCollection() on a non-object in /Users/ryan/Sites/alpheys/site/concrete/tools/edit_block_popup.php on line 39
So it sort of seems like it's not correctly setting up the block object on the first page edit, if the block comes from a stack (how global areas are handled I believe).
$bp = new Permissions($b); //if (!$bp->canWrite()) { // die(t("Access Denied.")); //}
Instead of access denied, I get:
Fatal error: Call to a member function isAliasOfMasterCollection() on a non-object in /Users/ryan/Sites/alpheys/site/concrete/tools/edit_block_popup.php on line 39
So it sort of seems like it's not correctly setting up the block object on the first page edit, if the block comes from a stack (how global areas are handled I believe).
This issue is being definitely being caused by stacks.
When an editable area is defined as a global area it automatically creates a stack.
You see this issue most of the time when an editable area is changed to a global editable area after a theme has already been installed.
To fix this issue
1) First you will need to temporarily activate another theme such as greek yogurt.
2) Next uninstall the theme you are using.
3) Now delete the stack or stacks from the dashboard that use the editable area name or names that have the permission denied problem.
4) Last re-install and activate your theme.
Now you should no longer have any permission denied messages.
When an editable area is defined as a global area it automatically creates a stack.
You see this issue most of the time when an editable area is changed to a global editable area after a theme has already been installed.
To fix this issue
1) First you will need to temporarily activate another theme such as greek yogurt.
2) Next uninstall the theme you are using.
3) Now delete the stack or stacks from the dashboard that use the editable area name or names that have the permission denied problem.
4) Last re-install and activate your theme.
Now you should no longer have any permission denied messages.
Cheers for this, I appreciate the steps.
Although I have no doubt this fixes the issue, I still think this is a bug of sorts. Concrete5 is correctly picking up the newly added added global area and creating a stack for it, and editing that stack works correctly otherwise. It's particularly interesting that I have no trouble editing blocks in a Sitewide area AFTER i've edited another block on the page in a non-global area.
I don't think it' unrealistic to change a editable area to global one after theme install, as that's a pretty common thing to do as part of development. I don't think I should need to uninstall a theme and clear stacks to avoid this (and it might not come up as a problem until a site is pretty much complete).
I'll investigate further I think.
Although I have no doubt this fixes the issue, I still think this is a bug of sorts. Concrete5 is correctly picking up the newly added added global area and creating a stack for it, and editing that stack works correctly otherwise. It's particularly interesting that I have no trouble editing blocks in a Sitewide area AFTER i've edited another block on the page in a non-global area.
I don't think it' unrealistic to change a editable area to global one after theme install, as that's a pretty common thing to do as part of development. I don't think I should need to uninstall a theme and clear stacks to avoid this (and it might not come up as a problem until a site is pretty much complete).
I'll investigate further I think.
We agree it would be nice if global areas did not act this way.
Unfortunately as of now they do and this is the only fix we know of.
Unfortunately as of now they do and this is the only fix we know of.
Ok, I think I've half tracked this down.
Yes, it comes from when you have a non-global area, and you change it into a GlobalArea. The Areas table ends up with records with the same arHandle (the area name), but with some records with arIsGlobal set as 0 and some as 1.
So in edit_block_popup.php, it creates a new Area object. Where it breaks is that in some cases it will fetch area records where arIsGlobal is set is 0, so when $a->isGlobalArea() gets called, it returns the now wrong result.. then the rest of it breaks down as it tries to create a block object the wrong way.
I thought I'd worked out that if I simply changed the conflicting 0 to a 1, it would remove the error.. but something changes it back to a 0 automatically.. still tracking that down.
Yes, it comes from when you have a non-global area, and you change it into a GlobalArea. The Areas table ends up with records with the same arHandle (the area name), but with some records with arIsGlobal set as 0 and some as 1.
So in edit_block_popup.php, it creates a new Area object. Where it breaks is that in some cases it will fetch area records where arIsGlobal is set is 0, so when $a->isGlobalArea() gets called, it returns the now wrong result.. then the rest of it breaks down as it tries to create a block object the wrong way.
I thought I'd worked out that if I simply changed the conflicting 0 to a 1, it would remove the error.. but something changes it back to a 0 automatically.. still tracking that down.
More info:
It seems to be something that only happens editing global blocks on the home page.
I think it's something to do with the getOrCreate() function of /concrete/models/area.php, writing to the Areas table via $db->Replace.
I get the impression that this function is sometimes not being passed the right value for $arIsGlobal, so it overwrites the Area record with the wrong arlsGlobal value.
I've been playing around and watching that database flag flick back and forth. If you watch it when you first load the page, and make an edit, then refresh the page, it will explain why things work after a page refresh and why you also get some other access denied issues.
It seems to be something that only happens editing global blocks on the home page.
I think it's something to do with the getOrCreate() function of /concrete/models/area.php, writing to the Areas table via $db->Replace.
I get the impression that this function is sometimes not being passed the right value for $arIsGlobal, so it overwrites the Area record with the wrong arlsGlobal value.
I've been playing around and watching that database flag flick back and forth. If you watch it when you first load the page, and make an edit, then refresh the page, it will explain why things work after a page refresh and why you also get some other access denied issues.
Ok, I think I've solved this.
The access denied errors disappear, and with no apparent side effects, if line 59 of /concrete/models/block.php is comment out.. the line is:
I can't actually work out why that line is needed. With this line commented out, I tested adding and editing blocks to both sitewide and non-sitewide areas, as well as the Stacks area of the dashboard.. didn't have any issues or errors. I tried with both caching on and off.
Even if that line is needed for some feature I'm not aware of, I'm pretty certain it's the culprit, as it's being triggered for Sitewide areas, but not considering in the global flag.
It would be great if someone else could test this. I'd love Mr Embler's insight!
The access denied errors disappear, and with no apparent side effects, if line 59 of /concrete/models/block.php is comment out.. the line is:
$a = Area::getOrCreate($c, $a);
I can't actually work out why that line is needed. With this line commented out, I tested adding and editing blocks to both sitewide and non-sitewide areas, as well as the Stacks area of the dashboard.. didn't have any issues or errors. I tried with both caching on and off.
Even if that line is needed for some feature I'm not aware of, I'm pretty certain it's the culprit, as it's being triggered for Sitewide areas, but not considering in the global flag.
It would be great if someone else could test this. I'd love Mr Embler's insight!
I believe I've found another 'safe' way to fix this issue if anyone comes across it.
To repeat, it comes from when you've had an an editable area in a template, then you've changed it to be GlobalArea, without changing the handle.
So you've changed:
$a = new Area('Footer');
to
$a = new GlobalArea('Footer');
So if you're having this problem, a solution is to create a new GlobalArea, with a different handle, re-create your blocks in the new area and then remove the old one.
So you would first have:
Then you would create a new GlobalArea with a different handle
You'd then recreate your blocks in 'Footer Area' and comment out/remove the old GlobalArea
Then you could go into Stacks in the Dashboard and delete the Footer area to tidy things up. I stress that it's important to re-create your blocks as opposed to using the clipboard, as copying them then deleting the stack will lose reference to them.
I'm still think it's worth investigating /concrete/models/block.php though, as that did seem to fix things without juggling content. I just don't know the ramifications of that edit.
To repeat, it comes from when you've had an an editable area in a template, then you've changed it to be GlobalArea, without changing the handle.
So you've changed:
$a = new Area('Footer');
to
$a = new GlobalArea('Footer');
So if you're having this problem, a solution is to create a new GlobalArea, with a different handle, re-create your blocks in the new area and then remove the old one.
So you would first have:
$a = new GlobalArea('Footer'); // area creating access denied areas $a->display($c);
Then you would create a new GlobalArea with a different handle
$a = new GlobalArea('Footer'); // area creating access denied areas $a->display($c); $a = new GlobalArea('Footer Area'); // new area $a->display($c);
You'd then recreate your blocks in 'Footer Area' and comment out/remove the old GlobalArea
//$a = new GlobalArea('Footer'); (or simply remove these lines) //$a->display($c); $a = new GlobalArea('Footer Area'); // new area $a->display($c);
Then you could go into Stacks in the Dashboard and delete the Footer area to tidy things up. I stress that it's important to re-create your blocks as opposed to using the clipboard, as copying them then deleting the stack will lose reference to them.
I'm still think it's worth investigating /concrete/models/block.php though, as that did seem to fix things without juggling content. I just don't know the ramifications of that edit.
This is for sure a good work around as well.
If you decide to use this method and are using a theme from the concrete5 marketplace, keep in mind that the next time you update your theme these changes will be lost.
You will need to rename these areas back to their new names after the update is applied.
If you decide to use this method and are using a theme from the concrete5 marketplace, keep in mind that the next time you update your theme these changes will be lost.
You will need to rename these areas back to their new names after the update is applied.
That's an important consideration, but think this error won't happen with themes from the marketplace, as they're not being edited in the first place. This bug is more to do when you're creating themes yourself and you change things.
(correct me if I'm wrong though, I don't use themes from the marketplace)
(correct me if I'm wrong though, I don't use themes from the marketplace)
While a lot of themes in the marketplace offer global areas, a good portion do not.
If a user realizes they can have a global area and decides to change the name of the editable area after they have already installed the theme they can end up with the same problem.
If a user realizes they can have a global area and decides to change the name of the editable area after they have already installed the theme they can end up with the same problem.
Any idea if this will be fixed in the next 5.6 version of Concrete5? Anyhow I'm still experiencing this problem.
I'm speculating here, but I am guessing that the cause of this may be server-related. Could be that the data hasn't finished caching and / or saving to the server.