Vanishing GlobalArea content
Permalink
I am having trouble getting the contents of my global areas to be visible when logged out of editing mode.
I have tried adding the content to the global areas from both the contextual editor by dragging and dropping a content block. I can then see the content I have created in `Stacks & Blocks>View Global Areas>Stack Name`. I have also tried by editing the `Stack` from within the `Global Areas`. Again the content is visible in the dashboard page and on the site pages but only when logged in. I have also spotted the elusive 'Approve Changes' button in the `Stacks` view and have all caching turned off. Any idea why the live site wont show this content? Where am I going wrong?
I have tried adding the content to the global areas from both the contextual editor by dragging and dropping a content block. I can then see the content I have created in `Stacks & Blocks>View Global Areas>Stack Name`. I have also tried by editing the `Stack` from within the `Global Areas`. Again the content is visible in the dashboard page and on the site pages but only when logged in. I have also spotted the elusive 'Approve Changes' button in the `Stacks` view and have all caching turned off. Any idea why the live site wont show this content? Where am I going wrong?
Normally this problem is full-page caching within c5 but you say this is turned off. Perhaps it's as simple as your browser cache? Try opening the page in a different browser. So if you normally use Chrome then open the page in Firefox.
Thanks for the input. I have tried standard hard reloads / different browsers to no avail. I am encouraged though as I am sure its something simple that I am missing. Don't suppose you have any other go-to's to suggest? Its weird as it is only the global areas that are behaving like this. For a bit more info I am declaring the global area in my theme headers/footers like this eg;
And loading them into my theme views using $this->inc(); Also same on my localhost and on server (bitnami distro hosted on AWS in unlikely event that is relevant) making me more sure its my own inadequacies to blame..
$a= GlobalArea('copyright'); $a->display();
And loading them into my theme views using $this->inc(); Also same on my localhost and on server (bitnami distro hosted on AWS in unlikely event that is relevant) making me more sure its my own inadequacies to blame..
Try this:
Where did you see your syntax?
<?php $a = new GlobalArea('copyright'); $a->display(); ?>
Where did you see your syntax?
Apologies I am using the syntax as you have shown (was off the top of my head - I'm on my mobile). Didn't quite follow your question? The declaration is in my footer.php file. The area appears just fine and will show as expected as long as I am logged in. Is it possible I have permissions too tight on the GlobalArea object (is it possible to set perms like this at all?)
Please double check your code. You corrected your code in your post above but you forgot the 'new' part. Please just cut'n paste your actual code so we don't waste time chasing things that aren't there.
Certainly your permissions can be too tight but only if you have adjusted them. Out of the box, c5 displays Global Areas to guests.
What version of concrete5 are you building with?
Certainly your permissions can be too tight but only if you have adjusted them. Out of the box, c5 displays Global Areas to guests.
What version of concrete5 are you building with?
More apologies for the red herring. This is the exact code from my included footer.php view file
I have updated previous post as well for clarity.
<?php $a = new GlobalArea('Copyright'); $a->display(); ?>
I have updated previous post as well for clarity.
thanks for this :)
are you always logged in as the super user?
What do permissions show on the global area / blocks in it - have you somehow removed the guest user from the view permission?
What do permissions show on the global area / blocks in it - have you somehow removed the guest user from the view permission?
The guest user can see everything else on the page. I have tested with normal logged in account and also visible... only guests are unable to see. Where do I go to configure block/stack level permissions? Currently using the simple permissions model
Also thanks for input much appreciated
If you're using basic permissions then I was barking up the wrong tree.
How many blocks are in the stack/global area?
What do you see when you look at the version history?
How many blocks are in the stack/global area?
What do you see when you look at the version history?
1 simple text content block in my example although it is same for anything I drop in. The version history shows a number of versions created by me adding/editing/deleting the block/design/content in an increasingly frustrated (and probably pointless) attempt to trick it into working. I spotted need to refresh page to get the Approve button to show up and obviously I clicked approve.. I will sleep on it. Usually the best thing to do under these circs. Cheers again for the help
Is there a live URL we could look at? We might see something odd but I doubt it.
Is it only text you are entering there or also graphics?
I had a similar issue - not sure if it is what you are experiencing...
When in Edit Mode, I would add blocks to a Global Area, but when I saved/published the blocks would disappear.
Ended up being a name conflict thing with Editable Areas.
e.g. I previously had an editable Area called "Breadcrumbs" for putting my breadcrumbs auto nav into. I then realised that this should really be a Global Area, rather than editable Area, as I'd put the exact same auto nav stack in all the pages.
So I simply changed the code in my template to the Global Area code, name remained the same "Breadcrumbs". But after I did that - every time I'd add content to the Breadcrumbs Global Area it would disappear on save.
SOO I changed the name to "Bread Crumbs" and now it works.
Not sure if that is the issue you are having, but thought I'd put it out there anyway :)
When in Edit Mode, I would add blocks to a Global Area, but when I saved/published the blocks would disappear.
Ended up being a name conflict thing with Editable Areas.
e.g. I previously had an editable Area called "Breadcrumbs" for putting my breadcrumbs auto nav into. I then realised that this should really be a Global Area, rather than editable Area, as I'd put the exact same auto nav stack in all the pages.
So I simply changed the code in my template to the Global Area code, name remained the same "Breadcrumbs". But after I did that - every time I'd add content to the Breadcrumbs Global Area it would disappear on save.
SOO I changed the name to "Bread Crumbs" and now it works.
Not sure if that is the issue you are having, but thought I'd put it out there anyway :)
Thanks malkau
I was having an identical problem and never thought about the naming conventions as I haven't had a problem with them before!
I was having an identical problem and never thought about the naming conventions as I haven't had a problem with them before!
You are not the only one. See:
https://www.concrete5.org/community/forums/5-7-discussion/page-type-...
https://www.concrete5.org/community/forums/5-7-discussion/page-type-...
Thanks to everyone finally found what I was doing wrong. I assume something related to my own theme is incorrect so the permissions on the areas were allowing Admin only. So I changed to the complex permissions model to update permissions by area (by clicking the `Permissions` option in Stacks & Blocks>View Global Areas>My Global Area) and also by changing the permissions on the block in the same view by clicking the block held in the Global Area and updating the permissions there as well.
I'm glad you have it sorted out. I've never seen a theme do that. Can you let us know what theme it is so we can investigate how this can happen?
Its my own theme I am working on for a client. I am installing the theme in the package controller like this:
$pkg = parent::install(); try { // install blocks BlockTypeSet::add("client_blocks","Client Block Set Name", $pkg); BlockType::installBlockTypeFromPackage('oneblock', $pkg); BlockType::installBlockTypeFromPackage('another_block', $pkg); //add the single pages $sp = SinglePage::add('business',$pkg); $sp->setAttribute('exclude_nav', 1 ); $sp = SinglePage::add('app',$pkg); $sp->setAttribute('exclude_nav', 1 ); //add theme and apply it to the site PageTheme::add('client_theme', $pkg); $theme = PageTheme::getByHandle('client_theme'); $theme->applyToSite();
Viewing 15 lines of 28 lines. View entire code block.
I am finding issues where I declare new Global Areas as well - I am unable to assign any permissions - the various forms launch but if I select a group/user to give permissions to it does nothing (by which I mean I click the list element and literally nothing happens). I have read a couple of posts about this and it seems the hyperlink is not constructed properly. I presume this has something to do with how I am creating the new Global Areas. Currently as a work around I am hijacking GlobalAreas defined by the default themes and they work fine - this is also fine for me but it may be relevant to this issue.
Hijacking existing Global Areas is an unsustainable and unmaintainable solution. When you are trying to edit permissions, open your JavaScript Console to see if errors are happening in the creation of the dialog windows.
Can you enlighten me as to why you don't just build a theme and install it the 'regular' way rather than all that coding? I'm afraid of 'unintended consequences'.
Can you enlighten me as to why you don't just build a theme and install it the 'regular' way rather than all that coding? I'm afraid of 'unintended consequences'.
2 reasons, first because the API offers it as a function so I presumed it was safe to use and secondly to package up all the various custom assets I am producing for my client so they can install everything in one hit without any additional set up. There is a lot more to go in than just the theme I naively assumed that would be the easy bit..
Also as the theme will never be published on the market place so I am not sure the sustainable/maintainable issue is something to worry about unless you tell me otherwise (other than a good practice consideration - I would much prefer to do it properly but would rather not spend the time unless absolutely necessary)
Also as the theme will never be published on the market place so I am not sure the sustainable/maintainable issue is something to worry about unless you tell me otherwise (other than a good practice consideration - I would much prefer to do it properly but would rather not spend the time unless absolutely necessary)
I understand what you are trying to do and I applaud you for your adventurous spirit. Have you tried using the API to do anything with the creation of Global Areas?
Ha! Adventurous=reckless=daft.. I havent tried to create the global areas programmatically.. yet. I have read the docs and it was my next step (had the hijacking not worked). Dont suppose you have an example of creating a GlobalArea and setting its perms by any chance?
So no errors from the js console and if I inspect the db the entries in the areas table look the same. This is the html being generated by the Add Group permissions modal form.. I notice the li elements for Guest and Registered Users have no ' class="dynatree-lastsib"' attribute. Could this be related?
EDIT: Assume the lastsib class is for the last list element and therefore a red herring
EDIT: Assume the lastsib class is for the last list element and therefore a red herring
<li class="dynatree-lastsib"> <span class="dynatree-node dynatree-expanded dynatree-has-children dynatree-lastsib dynatree-exp-el dynatree-ico-e"><span class=" fa fa-users"></span><a class="dynatree-title" href="#">All Groups</a> </span> <ul style=""> <li class=""> <span class="dynatree-node dynatree-exp-c dynatree-ico-c"><span class="dynatree-connector"></span><span class=" fa fa-users"></span><a class="dynatree-title" href="#">Guest</a></span></li> <li class=""> <span class="dynatree-node dynatree-exp-c dynatree-ico-c dynatree-active"><span class="dynatree-connector"></span><span class=" fa fa-users"></span><a class="dynatree-title" href="#">Registered Users</a></span></li> <li class="dynatree-lastsib"> <span class="dynatree-node dynatree-lastsib dynatree-exp-cl dynatree-ico-c"><span class="dynatree-connector"></span><span class=" fa fa-users"></span><a class="dynatree-title" href="#">Administrators</a></span> </li> </ul> </li>
So you're building in 5.7? Where is the detailed API documentation for 5.7? I don't think anyone but the core team know enough about how 5.7 works right now to do what you want to do. IMHO, 5.7 is not mature enough yet to trust the API to dot all the i's and cross all the t's.
Yup I am getting that impression. Not to worry I am working around it fine and will hopefully unearth a fix/better approach as I progress. I am sub a week into C5 so some learning to be expected. Generally though it is delivering the goods just got to avoid these sort of gotcha's
And thanks once again for all your help its much appreciated. Hope I can return the favour sometime
Currently, there are 238 open issues on Github for version 5.7 and this number has steadily grown since 5.7 was introduced in the fall. There are less and less volunteer developers working on these issues because of the learning curve required to make a meaningful contribution to a new, unfamiliar code base. Perhaps you issue is one of the open issues:
https://github.com/concrete5/concrete5-5.7.0/issues...
Again, I applaud your adventurous spirit but I think very few community members can help you on your journey.
https://github.com/concrete5/concrete5-5.7.0/issues...
Again, I applaud your adventurous spirit but I think very few community members can help you on your journey.
Very possibly it is although I still feel my approach is probably wrong. The requirement to package everything up was my own desire for neatness so not essential at all. Thanks again.
