(similar issue for 6.x #807754: Panel for /user/login,/user/password,/user/register,/user/123/edit)

It would be great to have more user page tasks in addition to user/%user. In particular user/%user/edit.

Comments

entrigan’s picture

StatusFileSize
new0 bytes

Here is a patch to add a user_edit task plugin to page_manager and a user_edit (form) content type plugin to ctools.

This is basically just a copy - paste - modify of the plugins for the node edit pages. It works, but I have a hunch the user_edit form content type plugin is not ideal.

merlinofchaos’s picture

Yeah, one of the reasons I haven't done this is that I think it takes a lot of care and attention to get this right. I'm willing to entertain it, but I would like to feel confident that whomever spends time with this code puts in sufficient time to understand user edit and make sure that the edge cases -- i.e, profile and whatnot -- all do what they should do. Need to also think about the ramifications of modules like content_profile.

entrigan’s picture

Project: Panels » Chaos Tool Suite (ctools)
Version: 7.x-3.x-dev » 7.x-1.x-dev

woops wrong project

entrigan’s picture

Title: Override user/%user/edit (panels/ page manager) » Override user/%user/edit
entrigan’s picture

@merlinofchaos Indeed.

I just tried out adding a bunch of fields to the account entity, and it appears both file fields and unlimited item fields throw errors when trying to load new items. (presumably some include is missing?). Additional considerations include piggy backing on the user registration page like node/%node/edit does.

Also I tested it out with both the profile and profile2 modules. I did not find any conflicts, however the code as it is does not support overriding these profile edit pages. One common issue will likely be people wanting to use the same panel for their user/edit and user/profile(2)/edit pages.

Would this be better off starting its life as a contrib module then?

merlinofchaos’s picture

I'd be happy with it starting here as a patch if you're willing to invest the time in it. It's very valuable in core CTools.

entrigan’s picture

I can invest in it for the time being. After looking over the Node add/edit task plugin, I realize we are also going to need a user_edit_form context. Along those lines, I am trying to get the node_edit_form context working with panels everywhere (#1139918: Node add/edit-form fails to render when using Panels Everywhere) before writing the user_edit_form context.

entrigan’s picture

Status: Active » Needs review
StatusFileSize
new14.09 KB

Improved patch. Now includes three files:
1. a user_edit page manager task
2. a user_edit ctools argument
3. a user_edit ctools context

It is basically a direct modification of the code that runs the node_edit_form.

Also I am not sure how to get the individual entity form fields to be turned into separate content types like happens for the node_edit context.

scotthooker’s picture

Looking at this patch - sounds very interesting. From this it looks like it would be possible to do something similar to allow panels to manage the layout of custom entity forms. Panels can already manage the layout of custom entity pages but cannot override their edit forms.

merlinofchaos’s picture

Most of the individual form fields for node_edit are actually hardcoded, each having their own plugins. It's kind of a pain. There's also a plugin to handle entity fields.

In our brave new D7 world, most things should be the basics and/or entity fields, and the content types that render the form fields are pretty easy to write in D7, so you just need to identify them and create plugins for them.

paulgemini’s picture

I tried the patch from #8 and got the following parse error along with a white screen:

Parse error: syntax error, unexpected T_DNUMBER, expecting T_STRING or T_VARIABLE or '$' in /home/content/09/7651809/html/myavail/sites/all/modules/ctools/plugins/contexts/user_edit_form.inc on line 190

It displayed right after clicking "Continue" in the panel editing screen with this content:

Configure
Configure a newly created variant prior to actually adding it to the page.
Choose layout » Panel settings » Panel content
Administrative title
Administrative title of this variant.
Disable Drupal blocks/regions
Check this to have the page disable all regions displayed in the theme. Note that some themes support this setting better than others. If in doubt, try with stock themes to see.

UPDATE, 15 mins later: NEVERMIND! Found a typo that I accidentally created myself. testing now.

paulgemini’s picture

Works for me!

One question - this doesn't allow for replacement of the user registration form, does it?

entrigan’s picture

@paulgemini This does not take over the user registration form. To do that you will need to create a new task plugin and a new content type plugin. It is fairly simple, can explain more in a couple of days.

merlinofchaos’s picture

The difference between user edit and user register should be pretty minor. It would be nice to be able to have both. I would like to commit both at the same time.

ramlev’s picture

I have implemented the patch from #8 in the brad new 7.x-1.0-rc1, with no problems at all.

My user edit form is a bit more advanced than the normal user form.
First of all i have a few custom fields added. And i have some custom modules which invokes some hooks which can alter the user edit form as wanted, with custom validate and submit functions, and everything works perfectly.

Looking forward to see a ctools release with this patch implemented, but with the 1.0 is in rc1 state, we cannot hope for it to be added before the 1.0 final release?

ramlev’s picture

Status: Needs review » Reviewed & tested by the community

Have tested and found no issues with the patch #8, for more info please read #15

entrigan’s picture

Hi Ramlev, from my perspective this patch is missing two things before being complete.
1. Should be able to access individual form items as you can with the node forms.
2. Needs to include the user register page.

Also this suffers from the same issues as #1139918: Node add/edit-form fails to render when using Panels Everywhere so that will need to be resolved as well.

ramlev’s picture

StatusFileSize
new14.07 KB

This is almost just a clone of the patch in #8.

The reason for this patch is (http://drupal.org/node/1110430) and the fact that some people are using this fix in a makefile, and it could not implement the patch, since drush_make don't understand the -p1 patch format, but the -p0.

sw3b’s picture

Subscribe ! This is exactly what i'm looking for !

Sylense’s picture

+1. This would be a GREAT addition to Ctools/Panels

MaxWesten’s picture

+1. Subscribing.

merlinofchaos’s picture

Status: Reviewed & tested by the community » Fixed

I went ahead and committed this, and then learned that entrigan went ahead and did the other stuff I asked for, but put it in a module rather than submitting the patch like I asked for in #14 back in July. :/

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

ozsi’s picture

In the file plugins/context/user_edit.form.inc are some $node variables, which must be changed to $user. Also in the queries are {user} placeholders, but it seems that {users} are the correct. I correct it every time by updates, but it would be nice when somebody (who is able to do it) commits it in the branch. Thanks!

entrigan’s picture

StatusFileSize
new4.83 KB

I renamed the words 'node' to 'user'. (based on 7.x-1.x-dev)

trogels’s picture

The form is printed nested two times

<form><form>

</form></form>

And wraps all my panel regions. So if I desire to include another form in a content pane, the submission of the form fails. In my scenario the validate and submit handlers are not even called.

The panel page looks like this

<panel content>
<form>
<form>
<panel left>the actual form elements</panel left>
<panel right><form>signup</form></panel right>
</form>
</form>
</panel content>