Public pages in the backend?

[matjazp]

4 hours ago, Robin S said:

The HTML for these elements is not rendered at all - in AdminThemeUikit at least.

I see, in AdminiThemeUikit it's ok, no header, in AdminThemeDefault the header is there.

4 hours ago, Robin S said:

It's a way of calling protected class methods from hooks. See here.

Thanks for the info. 

[bernhard]

Hey @Robin S ,

just found a problem when using this technique for handling shopping cart content: The user can select products (choose colours in your module) and those colors are stored in the users session. But when the user visits a different page, the user gets logged out and therefore loses all his session data (including the cart products, here colours).

12 hours ago, Robin S said:

This is for the sake of logged-out users of other roles, so that when they go to log into the PW admin they don't find themselves already logged in as the "frontend-only" user.

Another problem would be ProCache as it would not be usable when users are logged in ? 

Quote

ProCache runs for non logged-in guest users. ProCache is never running when you are logged-in, so you'll want to test the results from another browser. We like to use Chrome's "Incognito Mode" for this purpose.

Happy to hear your thoughts.

[dragan]

17 hours ago, bernhard said:

Everything is centered - where does this styling come from?

.ProcessLogin #pw-content-body {
	text-align: center;
}

 

[Robin S]

@bernhard, thanks for the pull request. I've merged parts of that along with a few more of my own changes. But probably not necessary to do much more with this particular repo though because it really only exists to serve as a quick demo for people like yourself who might like to take the idea further. I'm not feeling possessive of this idea/code at all so anyone is very welcome to take it and use it for their own purposes in any way they like - further developments don't need to happen via my repo.

To go further into something that would be more widely useful to the community, shared in the modules directory, etc, would require a new module that doesn't bundle any particular Process module like my demo does. I'm imagining something that would work with any custom Process module. And maybe focuses on the iframe approach because that seems the most promising (I was also playing around last night with the same JS library you mentioned). I might tinker around with something later but anyone is welcome to have at it and beat me to it. ?

To respond to some of your points...

14 hours ago, bernhard said:

I implemented a hookable method to modify the HTML, here to remove the admin url that is exposed in the pw config js object

Great, we don't want that exposed. I wish there was a better way than string replacement on the whole HTML output but there isn't any way I can see to set that part of the JS config object directly and I fear setting $config->urls->admin before the page render could have other unwanted consequences.

 

14 hours ago, bernhard said:

I removed the $session->redirect in the processmodule. I guess the reason why you did that was to get rid of the ?modal=1 parameter in the url?

The redirect isn't really about the ?modal=1 (although that is unwanted) - it's the Post/Redirect/Get pattern. If you look at the core Process modules you'll see that they all redirect after form POST submissions. In any case the specific code within the demo Process module is not something that anyone needs to use, it's just so the demo module renders something visible. What a person puts in their execute methods will depend on what they want their module to do.

Incidentally, setting $this->wire('input')->get->modal = 0 unfortunately doesn't solve the problem for redirects as these still have the modal parameter forced onto them. I think the simplest solution for that is just to make sure any redirect URLs include "//" (e.g. use http URLs).

 

14 hours ago, bernhard said:

Do you know how/if we could throw a regular 404 on a Unrecognized path exception in the backend?

I think it is too late within any Process module to throw a 404 exception. The best I could come up with is to check that any URL segment is valid and if not redirect to the 404 page. Maybe someone will discover a better way.

 

9 hours ago, bernhard said:

But when the user visits a different page, the user gets logged out and therefore loses all his session data (including the cart products, here colours).

Thanks to this post I think I have a solution for this, added in the recent commit.

 

9 hours ago, bernhard said:

Another problem would be ProCache as it would not be usable when users are logged in

ProCache can run on any page where the user isn't logged in, which for guests will be all pages besides the ones executing a front-end Process module.