Editable area on Login page

Permalink
I'm working on a site that is members-only. Anyone who is not logged in will see the Login page no matter what URL they try to access. What I'd like to do is have an editable area on the page, but I can't get it to work.

I know about site_theme_paths.php and have this working successfully.

I tried putting an Area in view.php, but it only shows if actually on /login (the address bar shows the URL of the page that the viewer tried to access unsuccessfully, it doesn't redirect to /login). So I tried making it a GlobalArea and that didn't work either. Any added blocks only show up on /login, not another page that is showing the login form.

Separate but probably related: the GlobalArea I'm using for the footer of the site doesn't show up on the login screen no matter what the URL is if the viewer is not logged in.

I'm using the simple permissions model.

Anyone have any ideas how to make this work?

kirkroberts
 
Blenderite replied on at Permalink Reply
Blenderite
If you can only see the area if you are logged on, most likely the permissions are set to block that type of block you have there from guests. You would need to figure out how to make that one block visible to guests as well.

Unfortunately there is not a per block permissions settings that will do that. We are trying to drum up enough about this very issue so that the developers decide it is important enough.
kirkroberts replied on at Permalink Reply
kirkroberts
Thanks for your reply.

I can see the blocks in the area if I'm NOT logged in and on the /login page. But if I try to access another page (so am on another URL but seeing the login form) I can't see any blocks, even if I used a Global Area.
Blenderite replied on at Permalink Reply
Blenderite
After a re-read of your question, it sounds like you are trying to figure out how to redirect a person to a completely separate page, if they are not logged in, right?
kirkroberts replied on at Permalink Reply
kirkroberts
I guess a redirect would solve the issue, because the viewer could be sent to the /login page. I suspect that would break the auto-redirect after login to whatever page they were trying to access in the first place, though.

I'd like to know why it doesn't seem possible to have an editable area that appears anywhere the login form appears. And why Global Areas (e.g. a footer) don't appear on the login page when it appears at a URL other than /login.

Since I didn't find answers in forum searches I was hoping someone might read this thread and have insight.

That said, a redirect might be the pragmatic solution but I'm not sure how to go about doing that. An event hook?
Blenderite replied on at Permalink Reply
Blenderite
I wonder if there are any addons there are that can do this for you.
kirkroberts replied on at Permalink Reply
kirkroberts
I looked in the Marketplace, but add-ons seem to either redirect *after* login or allow you to put login blocks on any page. Don't think either of those will be helpful in this situation. I'd rather use core functionality anyway, if possible.

What I'd love is if someone could chime in with exactly what happens when a viewer gets to a page and they don't have permission to view it. The URL does not change, but the login form is shown. How is the login form loaded? Why don't Global Areas show up on that view?
kirkroberts replied on at Permalink Best Answer Reply
kirkroberts
Found a workable solution to this. Not great, but it will do for now.

Based on this thread that had no resolution/answer:http://www.concrete5.org/community/forums/customizing_c5/editable-a...

You can make a Stack with named blocks (in your Stack click on the block you want to show up everywhere, choose Custom Template, and enter your block name there). Then use this code on your login.php single page, in your footer include file (if you have one), or anywhere else content needs to appear on a permissions-induced login page.
$b = Block::getByName('Login Message'); // change the name to what you entered as the Block name in the Custom Template dialog
$b->display();


Totally works. For some reason I couldn't get a Stack to work programmatically, but adding a block from a Stack programmatically DOES work. Odd.

I'm still hoping for a front-end solution using a GlobalArea or something like that rather than resorting to a named block.
enlil replied on at Permalink Reply
enlil
Interesting solution!! I've been poking around at this in a similar fashion lately. Although, in my mind I'm trying to figure out how to "page type" all the single pages. It doesn't make sense to me why it's so difficult to do so. put some "areas" into a global view.php somewhere, display the single page content within one of those areas. Go to edit your page, add some content and EASILY add background design to the single page content to integrate with your site...
kirkroberts replied on at Permalink Reply
kirkroberts
@enlil: that may work with other single pages, but /login is an example of "single page" content that actually appears at multiple URLs which I think is what creates the issues with content not appearing. An example is if trying to access a /private-page when not logged in you'll see the login form on /private-page.
monkeyArms replied on at Permalink Reply
monkeyArms
This is hacky but works:

At the top of my /single_pages/login.php file I put the following:

<?php
if (!preg_match( '#^/login/do_login/#', $_SERVER['REQUEST_URI'] )) {
   header( 'Location: /login/do_login/?rcID='.$rcID );
   die();
}
?>


The appropriate place to do this redirect would be in /concrete/core/controllers/single_pages/page_forbidden.php, but AFAIK you can't override a core controller.
kirkroberts replied on at Permalink Reply
kirkroberts
Nice one, monkeyArms.
Does that approach continue you on past login to the originally forbidden page? (assuming No, but I've been wrong before)

Overall this is probably a better way to do it for site editors (edit content right on the /login page instead of in a Stack), but maybe not for site visitors who then have to find the page they were originally trying to access.

Nice to have the option. Would be even better to not have to hack it, of course!
enlil replied on at Permalink Reply
enlil
Long after first replying to this thread I came across this how-to:

http://www.concrete5.org/documentation/how-tos/developers/overridin...

worked out GREAT for me!! You will need to also make sure you set proper paths in your config/site_theme_paths.php file before all of the pages, such as login, will take effect. But at that point you are able to "add areas" to the files to create custom editable areas on EVERY page of your site!!
kirkroberts replied on at Permalink Reply
kirkroberts
enlil, thanks for sharing your find.

Were you able to create an editable area on login.php AND have that editable area show up when accessing a non-permissioned page (and being shown the login screen on a URL that is not /login or /index.php/login) ? That's what this thread is about, not just overriding system single pages and adding areas to pages that only show up at one URL.
enlil replied on at Permalink Reply
enlil
I was able to add areas to some pages, yes!! As far as digging deep like you're asking, I cant say I've tried that yet. I've also PM'd you...
monkeyArms replied on at Permalink Reply
monkeyArms
Hi Kirk - it does redirect after the login to the originally forbidden page -- the $rcID variable is still set in the controller and passed to the template, so it works in my tests.

I haven't done extensive testing on it though....
monkeyArms replied on at Permalink Reply
monkeyArms
Agreed - would be nice for this to be built into C5 :)
mkly replied on at Permalink Reply
mkly
Hello,
This does make some sense. We were just looking at kind of the opposite with page forbidden where we were seeing the originally requested area in the page_forbidden page if it had the same Area name.

If you want to go over and open a bug on the bugtrackerhttp://www.concrete5.org/developers/bugs/... someone will check it out and see what the situation is.

Best Wishes,
Mike