Add trigger/action for custom after-register, after-login and after-logout events

This patch cleans up the wording and also the issue of <front> not showing up in the help text. Tested and working great, I'd say this is RTC!

This patch moves the new form items to their own fieldset, "User redirection settings", as they don't (all) belong in the registration settings fieldset.

Also converted the patch to use UNIX linebreaks, and removed unneeded blank lines from bottom of the file (this was causing the patch utility to give warnings).

Sounds good to me, updated against HEAD.

if you make destination a hidden form field, then you can remove the parameters to drupal_goto(). drupal_goto already checks the $_REQUEST for a field called destination and redirects accordingly. saves a few characters.

i do have some reservations though. these preferences will override any on the querystring. I might have a link like q=user/login?destination=taxonomy/term5 from a certain part of my site. but with this patch my specified destination would be ignored. would be good to smarten the patch to recognize this circumstance. just check for existence of $_REQUEST['destination']

Um, I'm pretty sure you can replace as follows:

- drupal_goto($_REQUEST['destination'] ? $_REQUEST['destination'] : ($form_values['destination'] ? $form_values['destination'] : NULL));
+ drupal_goto();

drupal_goto() already does what you seek. My only gripe is that you add a destination param to the form even when one has been supplied in the URL. Thats clobberring.

if you change the following to a hidden field, then you can simplify the drupal_goto() calls as I suggest: $form['destination'] = array('#type' => 'value', '#value' => variable_get('user_post_login_page', 'user'));

some modules change the 403 acces denied into a login page with the proper destination. in this case, we don't want the user going to the admin decided destination - he already had a destination in mind! thats what i mean by clobber. my suggestion is to not lay down the hidden field at all if isset($_REQUEST['destination'])

how about reviving this?

how about reviving this?

Moving to cvs.

Totally support this patch. Didn't apply anymore of course with all the filename changes and function moves. Reapplied it to cvs, untested, so please review!

This patch really does not need to check for $_REQUEST['destination'] since drupal_goto handles that automatically. If there is a $_REQUEST['destination'], the extract() in drupal_goto will overwrite the current path parameter.

Ugh. Found this issue too late.

Got a working patch for a custom logout path in #452462: Allow custom logout page - shall I move that patch over here?

I basically agree that admin/user/settings may be a more accurate location to place these settings. (I added to admin/settings/site-information, where front page, 403, and 404 are located already.)

Marked #452462: Allow custom logout page as duplicate of this issue. In there, people suggested to simply use triggers/actions for this purpose, which not only makes sense, but also allows further customizations.

Re-attaching my patch from the other issue (only for reference).

@merlinofchaos: Are you still up for working on this?

Without actually having tested it:
Custom redirect page after register is possible by using the "After a user account has been created" trigger and adding a redirect action, which is actually possible. I'm at least guessing that's what's the trigger is for, that would have to be validated.

Custom redirect on login is there with triggers and actions, even though it doesn't work as I recently noted in #451498: Redirect on login broken with action/triggers. As I noted there I assume this is due to some special-casing in user.module for the login process.
I don't know if #451498 should be marked "duplicate" if there is an approach here or if that should be handled seperately as it's really a bug report.

Custom redirect on logout would theoretically be possible...:
Well, there is the "After a user has logged out" trigger, but the problem is, you can't assign a redirection action to that trigger (as I noted in #452462: Allow custom logout page). I have no clue whether there is a reason for that or if that problem could simply be solved by making that action available.

Just some notes for now, I hope to play around with all this a little more in the next days.

And again, someone in IRC asked "How can I redirect users to a certain page after login?"

I just marked #451498: Redirect on login broken with action/triggers as a duplicate of #286668: Trigger "User logging in" doesn't work with Action "Forward to URL". Note that a solution for the after-login redirect is proposed there. The patch solves the problem for me in the latest head.

I agree that the idea that we should not duplicate (and conflict) with things already there in actions/triggers. We should simply make sure the options that are already there in actions/triggers work.

I tested the patch at #286668: Trigger "User logging in" doesn't work with Action "Forward to URL" and it works. I've rerolled it for D7. So we need to review and commit that. That gets us a third of the way.

Custom page upon registration: Is theoretically possible with actions/triggers.
I tried it, and upon registration you are redirected to the page, but you are not logged in, which isn't expected behaviour. Without the redirect action, you are logged in, after registration. I tried the patch, from #286668: Trigger "User logging in" doesn't work with Action "Forward to URL", but that didn't work either. So that needs to figured out.

Custom page on logout: Still the same as in #19

subscribe

Introducing a new tag for feature freeze: API clean-up.

It would really really be nice if someone would step up now to provide a patch for this.

Main problem for redirects is in conflict of drupal_goto() with drupal_get_destination

Patch #286668: Trigger "User logging in" doesn't work with Action "Forward to URL" is simple

 function system_goto_action($object, $context) {
+  unset($_GET['destination']);
   drupal_goto(token_replace($context['url'], $context));
 }

And this allows to proceed to a redirect page because user_login_block sets 'destination'

function drupal_goto($path = '', array $query = array(), $fragment = NULL, $http_response_code = 302) {
  if (isset($_GET['destination'])) {
    extract(drupal_parse_url(urldecode($_GET['destination'])));
  }

We have no ability to write good tests for triggers as explained #20 at #286668: Trigger "User logging in" doesn't work with Action "Forward to URL"

should wait till #601398: Simpletest does not allow assigning actions to triggers

Sadly, this didn't make it.

sub