User Edit Template

I'm moving this issue over to the ctools queue, as the task-handlers such as user_edit are provided by Ctools, not Panels.

@auroraenterprise, please, re-phrase your question, and keep them one per issue unless they are very closely related. Afterwards, set the issue status to active.

This support request has not been active for over two months. In an effort to clean-up the issue queue this item has been closed. If all modules are up-dated and the request is still a concern please feel free to change the Status back to active.

Overriding the user edit page without being able to add the submit button doesn't make much sense.

Here's a patch for a new ctools content type plugin based on the same functionality for the node edit forms, it's pretty straightforward. The binary part of the patch adds the icon for the plugin (it's reusing the "user" icon, just like the node_form_buttons plugin reuses the "node" icon).

Thanks to @jens.churchill for the collaboration on this functionality.

Patch still applies on latest DEV and it would be great to roll this in -- we place the save buttons on every other edit form we override in the upper right so it makes sense to do so here also (and was confusing to users).

Edit to initial post.

Same problem here.
When I try to override the user edit form with page manager and I add some form fields from the user object I get the value "Entity info.", instead of the form field. Moreover, I cannot add the Submit button to the form.

Hey, don't know if this is too late, but I had been wrecking my head for weeks over trying to get data input 'forms' on my custom Panel Pages.
They seemed to show as available on some of the 'incode' templates but when I did my own 'custom' it never happened. UNTIL, I added a 'context' Node add form, then after saving and then back to the add 'Content' from the left page editor, a 'Form' option appeared was there, made my day!

Wished I had seen a tutorial on this weeks ago, I mean it's so easy, but not that obvious that you had to add 'Node add form' as a context.

Hope any future readers find this.

BTW, Submit Buttons are 'Actions' as a content (under Page Elements).
Good luck (-:

This is unusable until the user edit form context is available which can take placeholders.

Here is a patch to enable users to add individual user edit form fields to the user profile edit page. I have added quite a few as individual components, but I have also added a general one: "User form: add a specific component" which allows adding fields that are placed on the default user form by a contrib module (ckeditor, password policy, ...).

The form actions / buttons pane also adds the hidden fields necessary for the form to properly submit (form_build_id, form_token, and form_id.

Hopefully this will help. It seems to work well for my purposes.

The patch file is incomplete.

As per #13

Sorry everyone. Leaving --name-only on the diff is no good :).

Here is the actual file.

Thanks @tnathanjames, glad you had it still on hand.

Updated an invalid comment after a peer review.

I have reviewed the functionality of the patch and have 2 small comments:

1) It uses an icon that should be located in: ctools/plugins/content_types/user_form/icon_user_form.png which is not obviously part of the patch and generates a "broken image" view in the selection of the different form elements (I know it's minor but if it should be considered as a patch in ctools this should be solved)

2) In order to generate the "Current Password" field in the form (so that the user would have to fill in his current password in order to change his email or/and password) you need to select "User form: add a specific component" and then in the User form field select box select the account option. This is not a problem of the patch's implementation per se but a bit of documentation on how to generate it.

Other than these 2 small notes everything seems to be working perfectly (thanks so much for this patch btw).

I will keep testing it and after I have verified that all parts of the form work properly I will mark it as reviewed.

Assuming that the above-mentioned .png file that is missing is replaced somehow, the core functionality of the patch seems absolutely fine.

Confirming the patch in #18 is working fine. Tested all default fields, added some custom fields.

I just found one more issue with this. The password update or email update for the current user requires the user to re-enter their password, but the current password form element was not being provided to the change password and change email plugin content types. The patch that I am attaching fixes that.

I am also including the binary for the icon in the new patch / interdiff. I just used --binary when creating the patch to get the icon in the patch. I hope that is the correct way to do that. If not, I am happy to update it and submit it again.

Fabulous. Thank you @tnathanjames for this. I am using the patch in #22.

However, the "User form: add a specific component" field does not seem to be working for me. For example, I have the Location module installed, which does add address fields to the default user form. But neither that field group nor the individual fields show up in the "user form field" dropdown in the "Configure new User form: add a specific component" popup window. The only fields that do show are the three hidden fields you list in #12.

Is there additional config that maybe I missed?

This patch is hugely helpful, thanks @tnathanjames!

We're setting up a custom user edit page with tabs - a page at user/%user/edit/addresses, another at user/%user/edit/orders, etc. The user edit forms provided by this patch are accessible on the default user/%user/edit page, but we can't access them with any of the other user edit pages we're creating. The forms aren't listed in the Add Content dialogue box.

Anybody have suggestions?

Found the solution. We added the relationship: "User category edit form from user". Then on the field form settings where we had the choice between "User being edited" and "User category edit form from user" we changed it to the latter.

The current password form was still missing, like unto comment #22, until we selected "Account settings" (instead of "Default") as the category on the relationship (kind of like comment #19).

To recap/clarify, with this patch installed, we're able to add all of the form fields on the default User Edit page. On our custom pages, we set the path to user/%user/edit/[tab name] and defined the context of the %user argument as User:ID (and renamed it "User being edited"). Then we added the "User category edit form from user" relationship with the "Account settings" category selected. Then we could accesses all of the form fields, including "User form: add a specific component." On the form field settings, we selected "User category edit form from user" (instead of "User being edited"). The forms are working correctly.

The 3 year old patch in #22 applied cleanly to the latest ctools 7.x-1.x-dev, but may need another review for RTBC status.

The 3 year old patch in #22 applied cleanly to the latest ctools 7.x-1.x-dev, but may need another review for RTBC status.

We've been using this patch for several years now on production w/o issue.

We've been using this patch for several years now on production w/o issue.

+1

This needs to - finally - get into the stable.

Patch at #22 still applies cleanly in: 7.x-1.17 (released 23 October 2020) and works as expected.

Thanks for your patience everyone, here's #22 committed to the dev release.