Link to a Custom Admin Process Containing URL Parameters

[jor]

Hi there,

I followed this helpful tutorial to create a custom admin process:
https://processwire.com/blog/posts/building-custom-admin-pages-with-process-modules/

We use this to perform certain tasks on our website and the site owner gets emails containing a link to the custom admin page including some URL parameters. This works fine if the site owner is already logged in to the backend. But if he has to re-login then all URL parameters are lost. I.e. we send him links like this:
https://www.domain.com/processwire/tools/ourmodule/?Param1=Lorem&Param2=Ipsum

I've seen the URL params are preserved when linking a regular page (...?id=123), but what to we need to do to have this for our custom Process as well?

Thanks in advance!
jor

[bernhard]

You need to create endpoints via ID-only parameters:

public function executeRedirect() {
  $id = $this->wire->input->get('id', 'int');
  $url = "/your/default/landingpage";
  if($id===1) $url = '/foo/bar/?foo=foo&bar=bar';
  elseif($id===2) $url = '/what/so/ever/?bar=foo&foo=bar';
  return $this->wire->session->redirect($url);
}

Then send a link like /your/module/redirect/?id=2

Alternatively you can create one method - executeFoo() and executeBar() - for each endpoint, then you can link to /your/module/foo and /your/module/bar

[jor]

Hallo Bernhard, danke für die Antwort! ?

Unfortunately our URL params are dynamic, not the keys but the values. Any idea how to do that?

[bernhard]

Hallo Jor ? 

it depends on where/how the dynamic links are created. Eg. if they where created on page creation (eg of a ticket), then you could save the link as meta-data of that page and just provide the ID of that page in the link and then the redirect function could get the real URL from meta-data of that page again.

[jor]

I see, yes we thought of this as well but wanted to avoid it because the site owner gets these emails in order to decide whether he wants to perform a given task. If so he can click on the link and has a prefilled "action form" in the backend. In case not we'd have a leftover "ticket" which he'd have to manually delete (instead of just deleting the email).

But how comes that the "id" parameter is preserved? Whitelisting I suppose, so wouldn't it be possible to add more keys to whitelist?

[bernhard]

Thx for pushing me to learn something new ? 

https://github.com/processwire/processwire/blob/d8945198f4a6a60dab23bd0462e8a6285369dcb9/wire/modules/Process/ProcessLogin/ProcessLogin.module#L848-L864

[jor]

This is getting into the right direction ? But how can this be used to add specific parameters? Does this only work for modules inheriting ProcessLogin?

[bernhard]

Untested:

$wire->addHookAfter("ProcessLogin::getBeforeLoginVars", function(HookEvent $event) {
	$vars = $event->return;
	$foo = $this->wire->input->get('foo');
	$bar = $this->wire->input->get('bar');
	if($foo !== null) $vars['foo'] = $this->wire->sanitizer->text($foo);
	if($bar !== null) $vars['bar'] = $this->wire->sanitizer->text($bar);
	$event->return = $vars;
});

Make sure to sanitize input properly!

[jor]

Vielen Dank, Bernhard!

Now I've put that into my ready.php and it works great. Just one thing occurred that is Umlauts are html-encoded. I.e. when having this URL:
https://domain.com/processwire/tools/ourmodule?Param1=Fünf
after the login it is transformed to:
https://domain.com/processwire/tools/ourmodule?Param1=Fünf
which essentially looses part of the value because & of course is the URL param separator. I've tracked this down into the ProcessLogin module and it seems that this line should NOT be:

if(!is_int($value)) $value = $this->wire('sanitizer')->entities($value);

but rather:

if(!is_int($value)) $value = rawurlencode($value);

because the URL string is manually built by concatenation. After fixing this in the Core our links now work great.

Thanks again for your help, Bernhard. What do we do about this bug (?) in the Core module?
 

[jor]

I've created an issue on this in the processwire-issues repo:
https://github.com/processwire/processwire-issues/issues/1330