Redirecting Users on Login III

Redirect users based on a User Setting


In the last article, we saw how to redirect users after login based on the time or season. In this one, we'll see how to do it on the basis of a user setting. Since we don't know who the user is until *after* they've logged in, we need to move the code to a plugin connected to the OnWebLogin System Event.


Redirecting Users Based on a User Setting

There are two logical places to put code for redirecting users after they login. One is in a snippet that you designate as a Login postHook in the Login tag. The other is in a plugin attached to the OnWebLogin System Event. Either one works, but I prefer doing it in a plugin because the $user object is immediately available to you, and you don't have to worry about potential interference from other Login hooks. The code would be essentially the same for this example.

In this article, we'll redirect the user after login based on a resource ID stored in a user setting for that user. The code is very simple, but first, lets look at creating the user setting.

Creating a User Setting

Follow these steps to create a user setting for each user:

  • Go to Manage -> Users on the Top menu
  • Right-click on a user and select "Update User"
  • Click on the the Settings tab, then on the "Create New" button
  • Enter LoginResource in both the Key and Name fields
  • In the Value field, put the ID of the resource you'd like to forward the user to on login
  • Click on the Save button at the upper right to save the user
  • Repeat for any other users you want to forward

The Plugin Code

This plugin code (we'll call it LoginRedirect) is quite simple. The Plugin is attached to the OnWebLogin event. As soon as a user has successfully logged on in the front end of the site, MODX invokes the OnWebLogin System Event and our plugin code executes. The code gets the user setting and forwards the user to the resource with that ID:

/* LoginRedirect plugin */

/* Get the user setting */
$docId = $modx->getOption('LoginResource', null);
if (empty($docId)) {
    return '';
}
/* Create the URL */
$url = $modx->makeUrl($docId, "", "", "full");

/* Forward the User */
$modx->sendRedirect($url);

The process of adding the user settings is tedious, so it only makes sense if there are not a lot of users. If there are a lot of users, you can make the process a little less annoying with a utility snippet to create the setting for all users. Create a temporary page with this tag (where the default value is the ID of the page you're most likely to send a user to). The default will also be used for user with no LoginResource setting:

[[CreateUserSetting? &default=`12`]]

Now create a snippet called CreateUserSetting with this code:

<?php
$default = $modx->getOption('default', $scriptProperties, 12);

/* Get all users */
$users = $modx->getCollection('modUser');

/* Add setting for each user */
foreach ($users as $user) {
    $setting = $modx->newObject('modUserSetting');
    $setting->fromArray(array(
        'key' => 'LoginResource',
        'value' => $default,
        'user' => $user->get('id'),
    ), false, true);
    $setting->save();
}

return 'Finished adding setting for ' . count($users) . ' users';

View the temporary page once, then delete it and the snippet. You definitely don't want to visit it again, because that will reset all the user settings to your default value.

Of course you still need to edit each user and set the value of the page ID you want to send them to. In many cases it will be much more convenient to forward the users based on their membership in various users groups with a user group setting. We'll look at how to do that in the next article.

 

Comments (2)

  1. Susan OttwellSep 23, 2015 at 10:21 PM

    This will be useful for a user blogging system. On registration a new user joining a given group ("bloggers") is given a new resource as his "home" page. As soon as that "home" page is created, its ID is known, so now the user's login landing page can be set, all as part of the registration process. I've also got vague notions of how your Notify snippet can be mixed in here.

  2. Bob RayOct 09, 2015 at 11:39 PM

    One possible catch is that any Register postHooks may not execute, so their code would have to be moved into the plugin.


Please login to comment.

  (Login)