Panel for /user/login,/user/password,/user/register,/user/123/edit

Currently there is not.

The user/login and user/password pages are probably not difficult, as they are simple embedded forms.

The user/register and user/%/edit ones are difficult because Drupal does strange things with that form and Panelizing it properly is not easy.

Changing to a task -- this is something we definitely want at some time.

subscribing

Subscribe

tracking

I have found a decent work-around for this, at least as far as login, register and password pages are concerned.

First, get all of your panels set up the way you would like. There is a nice guide on this here: http://proofgroup.com/blog/2008/sep/drupal_combining_login_registration_...

Now while that works fine, what about when Drupal creates login links? These will all be to the standard user/login link. To redirect these within Drupal in a nice, reliable way, I created a template hierarchy page for each link.

So go ahead and create:

page-user-login.tpl.php
page-user-register.tpl.php
page-user-password.tpl.php

Now inside of each of these use the Drupal goto function and redirect to your newly created panels pages. For example,

drupal_goto('test/register')

Now, whenever the regular links are used such as user/login they will load the template file then redirect to your panel page.

I've started developing these as new page-manager tasks (for D6).

If we override user/login, it'd be nice to have a login-form appear on that page, however the core user-login block won't appear, because of a quirk in the block's implementation:

  // From hook_block() in user.module
  // For usability's sake, avoid showing two login forms on one page.
  if (!$user->uid && !(arg(0) == 'user' && !is_numeric(arg(1)))) {

    $block['subject'] = t('User login');
    $block['content'] = drupal_get_form('user_login_block');
  }
  return $block;

Would it be better to:
1. Add a second ctools content-type plugin for the user-login form, which does the same thing.
2. Add a new ctools content-type plugin for the user-login form, and hide the core user-login block from page-manager/panels (so administrators aren't confused about which user-login block to add to their panel).

I'm leaning towards the second option, because choosing from 2 identical user-login widgets would seem confusing, but I'm also wary about breaking backward compatibility for users who already have the current (core) user-login block on a panel.

I agree that the later is cleaner and makes sense. Do you see an implementation path that would allow for backwards compatibility or an automatic migration path?

If it's not already possible we need to make it possible to remove the UI for old content types. That way they can still exist but not show up to be added as new content. That would make this more or less possible.

Another possibility is that there's a pretty significant ability to alter core blocks. We may be able to just alter the existing content type to use a different render and settings stuff. I use this to good effect with the Views exposed filter blocks.

(moving from panels to ctools because the features described are implemented/patched within ctools).

Here's a patch to handle:

• /user (and therefore /user/login)
• /user/password
• /user/register

This adds 3 page-manager tasks, 2 new ctools content-types (for the user-registration form and the reset-password form), and adds a custom render function for the core user-login block so it will render on the /user and /user/login URLs.

User-edit

A patch for user/nnn/edit will take a little longer (and in any case, it'll probably be easier to review that if it's a separate patch). One of the issues for providing panels for user/nnn/edit is that the user module also provides the url user/nnn/edit/xxx for each category provided by other modules via hook_user($op == 'categories').

One possible solution might be to:

• add a checkbox to the page-manager task, to select if the page-manager task should override those URLs too
• add the categories as selection criteria
• provide the account (user-object) and the category as contexts.

add the categories as selection criteria

The possibility I like: Add it as an optional context -- that the task can have this as a string context from the URL and easily pass it to the page.

We've been using this patch and it seems to work well. Just wanted to vote for a commit.

subscribe

manarth's patch works great for me. Voting for a commit

Faced this problem while trying to override local tasks (user/%user/edit, node/%node/track) with page manager page. Here's my initial (and quite a bit hackish) stab at creating general solution for solving MENU_LOCAL_TASK problem, it allows you to assign rendering of local tasks to a custom panel through a pane (see pictures). From what i can see it could be made into a task plugin as they have ability to act upon hook_menu_alter(), but due to time constaints it's done as a standalone module for now. It also supports secondary tasks.

Some cleanup and bugfix. To register panel for /user/register use path /user/tasks/%register.

Bugfix.

Oh boy!! I so wanted this to work (panel_tasks_proxy-3.zip)! I imported the page into Panels 3, Saved, but the content for the 'Local tasks proxy' pane always shows up 'Deleted/missing content'. And, there is no 'Local tasks proxy' selection in the 'Page elements' window.

Perhaps I'm doing something wrong? I installed the module in my sites/all/custom/panel_tasks_proxy folder and commented out the project = panel_tasks_proxy line to keep the Update report from showing Panels at version 6.x-0.1.

Thanks for posting this, even though I couldn't get it working.

I have it at sites/all/modules/panel_tasks_proxy with Panels 6.x-3.9 and Ctools 6.x-1.8 (PHP 5.3.5). Try clearing the cache, if that doesn't work try creating the panel page according to guidlines in README.txt. Pane not showing might suggest some problem with arguments configuration as the pane requires String context to exist (even though it's no longer used by the pane - it's left as a safety measure). Attached screenshot of the important part of panel page configuration.

The problem with current approach is that when you overwrite path registered by some other module, you need to create custom page manager task executing the same code that original handler did, so you can either expect each module author to do this (unlikely) or make ctools handle it for them (unfeasible for anything more than core). The other part of the problem is that some 'page callback' functions are able to live only at their original paths by relying on arg() in callback code, so you cannot simply register panel with other path and call it back.

How proposed solution works:
1. 'Local tasks proxy' pane tries to figure out path of the panel it was placed on by examining $form_state['display']->did in its panel_tasks_proxy_tasks_proxy_content_type_edit_form() callback (that's the reason panel has to be saved before this pane is placed on it). It chops off last two arguments ('/tasks/%tasks') and queries 'menu_router' table for all tasks living there. The important thing is that 'tasks' (not %tasks) should be at the same depth as the task you are trying to overwrite.
2. On submit it calls menu_rebuild().
3. panel_tasks_proxy_menu_alter() gets called, it enumerates all page manager panels containing 'Local tasks proxy' pane, when found it extracts from its configuration which tasks/paths should be overriden. For each of those it substitutes original 'page callback' with panel_tasks_proxy_callback_proxy() and prepends to 'page arguments' original and panel's menu item info for use in proxy function. This way it assures original 'page arguments' get resolved properly (eg. node_load called). Because it also needs panel's menu item information it has to be called after page_manager.module, that's why module adjusts its weight in system table on install to 100 (page_manager.module has 99).
4. When user visits one of the overriden menu items panel_tasks_proxy_callback_proxy() gets called and it substitutes in place of '%tasks' arguments from current call (including task name so 'user/1/devel/render' becomes 'user/1/tasks/devel/render') next it uses menu_get_item() on that path so panels arguments get properly mapped into ctools_contexts and executes panel's 'page callback'
5. 'Local tasks proxy' pane's render function gets called and it in turn calls menu_execute_active_handler() to get original page content.
6. panel_tasks_proxy_callback_proxy() gets called again and this time it executes original 'page callback' passing resolved arguments to it, content rendered is returned to pane.
7. You should get page content inside of the pane with all other benefits of Panels.

Currently it doesn't allow you to overwrite MENU_DEFAULT_LOCAL_TASK, but that can be fixed by removing dependency on %tasks from the code (it was used in initial version as an argument to menu_execute_active_handler() but it turned out it would get it from $_GET['q'] when called without parameters). Also pane's config callback can be made more liberal and also handle items with MENU_CALLBACK so for example you could overwrite (admin/content/taxonomy/edit/term/%tid).

Fixed .info file and added some safety checks.

subscribe

subscribe

subsribe

about the edit part.

well i actually could not use your solution, mean while you guys get to a user friendly solution i suggest less experienced users to see this

http://drupal.org/node/368048

adding this

global $user;
// if the user is logged in
if ($user->uid > 0) {
  include_once drupal_get_path('module', 'user') . '/user.pages.inc';
  print user_edit($user);
}
else {
// do something else
}

to a custom node will do the trick of bringing the edit form, hope to help someone

For those having problems with previous versions, menu needs to be rebuilt after import or changing pane's settings, so do one of those:
- enter 'Local tasks proxy' pane's configuration again and press 'Finish'
- disable and enable panel
- rebuild menu with devel module

New version fixes that, also:
- allows to overwrite MENU_DEFAULT_LOCAL_TASK, MENU_CALLBACK (eg. 'user/%user/delete')
- adds new argument/context type 'Tasks split' which acts as a delimiter, it will behave almost exactly as a 'String' context and receive the name of hooked task as a string so you can use it in visibility/access rules, this also allows you to configure any other contexts after it (eg. !node for comments)
- passes page title back to pane
- exports for /comment and /user/login, /user/password, /user/register

I found "panel_tasks_proxy" really works in drupal 6,really good but I need to build website using drupal 7......

Do you have for drupal 7 ?? I really need !!

I don't plan on using Drupal 7 in near future (at least 6 months) so simple answer would be no.
If it will be assesed that this approach is sound and there will be indication from the maintainer that a patch incorporating this functionality into ctools would be accepted I'd be willing to work on it, if the 6.x branch will no longer accept new features or they would need to be submitted to 7.x first and then backported I'll consider doing D7 version.

I only get this error here
Warning: call_user_func_array() expects parameter 1 to be a valid callback, function 'user_page' not found or invalid function name in panel_tasks_proxy_callback_proxy() (line 119 of /.../sites/all/modules/panel_tasks_proxy/panel_tasks_proxy.module).

and the url is /user/login?destination=comment%2Freply%2F155%23comment-form

Is this a bug or a configuration problem of me?

the other thing is that I see on this page /users/admin as an anonymous user the login page followed by a part of a diffrent page with the hint access denied.Take a look at the screenshot.

It's a bug, latest version attached. Attached screenshot is broken.

Thanks you very much! only use drupal_goto is ok!

Will this be ported to D7?

In Drupal 7 you can also use templates like page--user--edit.tpl.php

+1

subscribe

+ (we really need a subscribe/unsubscribe feature in these forums)

@Manarths Patch in #12 worked for me.
Does additional code posted as zip in #31 build on the initial patch or is it another feature (e.g. would it be best as a separate issue and allow patch in #12 to get in while work continues)?

#31 is independent of the #12 and it was meant more as a proof of concept for solving some of the problems raised in #12. It's much more generic solution allowing to force pretty much any page/path/task into a panel, at the cost of flexibility (e.g. you can't pick which fields will show on edit page), it also needs an update to handle exported panels/features. It turned out to be a bit of a de-railer for which I'm sorry. Should definitively be in separate issue, and not as a standalone module but converted to a patch.

user/%user/edit is not supported yet, right?

Subscribing

subscribing

I think that D7 has saner ability to embed forms

The user/$uid/edit pages work allready. Im just wondering how to get the categories in a panel. For example user/$uid/notifications

The following is a display suite solution, that integrates with panels. I believe theming these forms could be accomplished using this module http://drupal.org/project/rel

animelion: could you suppy us with more info?

I haven't used the module I linked to, but I'm planning on it. Checkout this screencast and you'll know everything I do. http://bit.ly/pk04uC

Great module, can't really see the link with this issue tough.

I made the assumption that the Renderable Elements module offered all the same functionality as Display Suite, but that doesn't look to be the case just yet. In Display Suite you can substitute a panels interface for fields UI. Sorry for the confusion.

Subscribing and votig for D7

I'm doing the trick from #6, and it's working well. However, I did have to unset the destination in order for it to work properly. My code in the template files is:

  unset($_REQUEST['destination']);
  drupal_goto('login-register')

If you follow the guide on ProofGroup cited in #6 above, please note the change in syntax for D7 with respect to displaying a form in a block. The proper D7 syntax is:

<?php print drupal_render(drupal_get_form('user_register_form')); ?>

Please also note that the format for template suggestions has changed in D7 so that the proper file names would use double dashes, not single dashes (e.g., page--user--login.tpl.php instead of page-user-login.tpl.php).

subscribe

and in D7 it's $_GET['destination'] instead of $_REQUEST['destination']. anyway, if we have to unset the destination, this is a major showstopper for using this workaround at all

It means right now Page manager can not override or edit pages like /user/login or /user/register?

http://drupal.org/project/pm_existing_pages already can do this.

Confirm, pm_existing_pages works well. Thanks rogical.

We are using drupal 6 on this project.
The module in #31 did the trick for our user/register page.
Thanks for the work, tacituseu.

peace,
michael

Updating patch for user/login, user/password, user/register and user pages.

Added Patch file.

Fixed user/login enable issue with the above patch.

#64: ctools--page-manager-user-tasks-807754-3792682.patch queued for re-testing.

Is this patch for D7?

Yes. This is for D7.

Hi all, this patch will be great once i get my head on straight and am able to install it properly.

i uploaded it to the /var/www/html/sites/all/modules/ctools

then i executed:

patch -pl ctools--page-manager-user-tasks-807754-3792682.patch

i received an error - patch: **** strip count l is not a number

i'm sure that i am doing something completely stupid. can anyone assist a newbie?

thanks!

@pjmcghee the syntax is patch -p1 < ctools--page-manager-user-tasks-807754-3792682.patch - the command you're providing in your message is missing the < arrow, and appears to be using the letter L -pl instead of the number one -p1.

The -p1 parameter tells patch to remove the first part of the path from the filenames in the path (so references to a/foo.php tell the patch program that foo.php is the filename). The < arrow is the file redirector, it takes the contents of the patch file and sends it to the patch program.

haha! i knew that i was simply doing something dunderheaded...

thanks so much manarth, for the explanation as well. I hope that you have a great day!

#62: ctools--page-manager-user-tasks-807754-3792682.patch queued for re-testing.

#64: ctools--page-manager-user-tasks-807754-3792682.patch queued for re-testing.

Patch in #64 worked like a charm. Have a freemium content site, was able to easily drop in recurring license product display node alongside login form.

I applied #64.
I can now override the user/register page however there is no ' create new account block' to add in the page. (that is username, emailadress, create account button)

Go to category "Form" while adding content to page, you will find there "User Register Page".

tnx for your swift reply.

'Form' however is not available...

Available are:
-Activity
-Menus
-Minipanel
-Miscellanious
-View panes
-Views
-Widgits

All good now.
I forgot to add the user_register_form.inc

64: ctools--page-manager-user-tasks-807754-3792682.patch queued for re-testing.

Let's close this if patch is working fine ?

I only tried the new user login task for page manager and the user login form that goes with it, and it works great so far.

Small remarks: all new ctools content type forms set $block->content twice in a row, ie.:

  $block->content = t('User Login');
  $block->content = drupal_get_form('user_login');

My guess is that the first should set the blocks title:

  $block->title = t('User Login');
  $block->content = drupal_get_form('user_login');

And the titles do not match the titles used by the user module, this way they are not automatically translated since the source strings are unknown to Drupal.

1. User Register -> Create new account
2. User Login -> Log in
3. User Password -> Request new password

(sorry I can't make patches!)

@Imeurs: Good catch. I have updated the patch.

@abhishek.kumar: Great! But the titles still do not match the titles used by the user module which I strongly recommend for uniformity. When using the same titles, they are automatically being translated on non-English sites.

1. User Register -> Create new account
2. User Login -> Log in
3. User Password -> Request new password

@Imeurs: No need for that. It can be overridden by user while adding this plugin to page.

If you add the user login form to a page and access that as an authenticated user you get redirected to /user/UID. Obviously you can add a visibility rule to the pane but ideally it should just not display, I think...

I've applied the patch successfully and update panels and ctools to the latest versions, also cleared the cache but i don't see the new templates appearing in the page manager. Do i need to do anything else to make them available to be overiden?

Thanks

Did you update to the latest version before or after applying the patch? If you patched before updating then the patch would have been overwritten.

Yes I did. I re-applied it after performing the update.

Ok, i reapplied it again but did it within netbeans on the root of the ctools module rather than on the page_manager folder. The pages have appeared. Thanks

Thanks! Work for me.
(ctools 7.x-1.4)

@abhishek.kumar Thanks a bunch. The patch works perfectly. +1 for a commit. Also, I had to heed to advice in #89. It is a little confusing because the patch will apply successfully in the page_manager directory.

I've been successfully running the patch from #82 as well for a couple of months now. Also on a live site and nothing has gone boom so far. I've glanced through the patch as well and it looks good from my limited look. As it does not seem to touch any existing code paths of ctools I think its fairly safe to commit imho.

I have converted this patch in a module (https://www.drupal.org/project/user_pages). Please test it and report your bugs.

Putting back to RTBC. It's technically not fixed because a maintainer has not weighed in on this.

Still I highly recommend applying the same titles as used by the User module for:

1. uniformity and
2. automatic translation on non-English sites.

Titles used by the patch and User modules are:

• User Register -> Create new account
• User Login -> Log in
• User Password -> Request new password

See comment at #807754-83: Panel for /user/login,/user/password,/user/register,/user/123/edit.

+1 for commit

+1 for commit

I would like to show all three forms in a single panel. I've done this on the user/login page as per the image below.

Is there a way I can remove the menu from displaying here?

I've also tried using the original 'user' page with a selection rule of anonymous user, but that doesn't show. I assume because user/login overrides it.

+1 for commit

Looks good, nice idea.

The menu is probably showing because it is in your page or layout template. If you need further help with that, try the Drupal community forums or Drupal Answers (Stack Exchange), the issue queue for this module is not the place to ask for help about menus.

Yes, /user/login overrides /user for anonymous users.

Per #93 I think this really belongs in that module, and not ctools. If you're interested in using user pages, please use and submit issues to that module:

https://www.drupal.org/project/user_pages