Hooks in user-new.php

Isn't that already possible by hooking to user_register and checking is_admin() if needed?

It looks like the user_register hook is called AFTER the form is filled out, making it unsuitable for requested user metadata during the account creation process.

I'd like to add fields to the new user form (in the admin interface only). the form appears to be statically defined in user-new.php.

Diff to add a "new_user_profile" action to user-new.php

I think the OP meant to add form fields and other code to the actual form in user-new.php... similar to "edit_user_profile" and "show_user_profile" in user-edit.php.

I'd like to do something similar, and wonder why this hook isn't in place already.

Attached is a patch which just adds a "new_user_profile" action above the roles. (FYI, I created the diff against 3.3-beta2-19067)

A hack to work around not having this hook is to use the "show_password_fields" hook/filter. That hook seems to only be used on the user-new.php and user-edit.php page. It's meant to check if the password field should be shown, but you can output code at that point to add things to the form. You can check FILE or $_SERVERPHP_SELF? to distinguish between the new/edit user pages.

Replying to strangerstudios:

I think the OP meant to add form fields and other code to the actual form in user-new.php... similar to "edit_user_profile" and "show_user_profile" in user-edit.php.

I'd like to do something similar, and wonder why this hook isn't in place already.

+1 for this. A lot of us have had to work around tacking fields on using the show_password_fields hook before.

I just recently had to hack fields into the user-new form using the 'show_password_fields' filter. It's hacky and not an ideal place for the fields. I'd love to see something like this make it in. I'd probably add it to the end of the form, just above the submit button, but where it is in the patch isn't too bad either.

Currently we have to use JavaScript or output buffering to add custom fields. A real hook would be very useful. The patch looks fine for me.

Please can we have a hook here? WordPress has my my life more difficult due to the lack of hook at that point.

Related/duplicate: #13548

Necessary for a bbPress enhancement. ​#BB2223

This hook is different from edit_user_profile and show_user_profile, as it actually takes place between table rows, rather than between tables.

Ideally, the hook would be placed in such a way that it does not rely on a table being there. One of these days, all of these tables will go away, and a hook like new-user-profile.diff​ will make that difficult if not impossible.

I was just talking through this in IRC and was voicing the same concerns. I like the idea of having a hook here, but I'd prefer it be moved outside the table to just before the submit button.

Refresh, use existing naming conventions, and add actions before and after

18709.patch also adds actions to the network admin page.

I like @johnjamesjacoby's patch. Let's get it pushed.

For those wondering how you would process the POST data of any fields added using the new hooks, you can use the user_register and added_existing_user hooks to check $_POST, nonces, and update user meta, etc.

FYI, JJJ's patch might be outdated. I will get an updated one posted tomorrow.

user_new_form_before and user_new_form_after hooks

18709.2 attached. This patch changes the names of the hooks added in the previous patch. The two hooks added now are:

• user_new_form_before
• user_new_form_after

First, I made both the network version and non-network version use the same set of hooks. The previous patch added new_user_form_before/after and add_user_form_before/after. I think this may have been a typo, but might have been intentional. If intentional, I think that it makes sense to use one set of hooks and let the plugin authors decide if they want to do something different for network sites and non-network sites. This is similar to the edit_user_profile hook which appears in the network and non-network version of user-edit.php.

I also switched the order from new_user to user_new to match the filename and another hook already in place there (user_new_form_tag).

I tested 18709.2 on the latest codebase (as of posting) and it works great. I'm open to double checks and ideas around the hook naming/etc.

Version field indicates when the enhancement was initially suggested.

Replying to ocean90:

Version field indicates when the enhancement was initially suggested.

Thanks.

Used the last patch for this ​http://bbpress.trac.wordpress.org/ticket/2223 and works great.

It'd be great to have this into 3.7

Need to doc these filters - see #25229 and ​http://make.wordpress.org/core/handbook/inline-documentation-standards/php-documentation-standards/#4-hooks-actions-and-filters

Since we're using the same two hooks in three different places, we should pass a context string with the actions to make targeting an 'Add Existing User' vs an 'Add New User' form a lot easier.

This is done + hook docs in 18709.3.patch​.

hooks + passed context + hook docs

typo

Semantics...both actions fire inside the form, not before or after. Not sure if we have a pattern around that.

Seems ok to go in as it shouldn't have too much of an impact on any future revamps of the table structure in new/edit user. The latest patches don't add table rows. The only restricting aspect is that the actions both fire inside <form>, and before <submit>, but those shouldn't be a big deal.

ignore the double submit

Looking at ​#BB2223, only the after hook is used. I wonder if that alone would be useful enough to enable plugins to introduce extra fields before the <submit>.

I'm pretty wary of a hook firing before, given that all these forms are pretty normalized with username at top. One at the bottom, outside the table, seems okay, if maybe a little less than ideal. Can probably just be user_new_form in that case.

Okay, let's add a single hook after the table, inside the form, before the submit button. Needs patch.

18709.diff​ introduces one action, user_new_form.

In 25629:

I'm reverting this from the network admin. It was modeled after the profile editing hooks, but the profile editor in the network admin is a direct inclusion of wp-admin/user-edit.php.

In this case, wp-admin/network/user-new.php is *not* the same as wp-admin/user-new.php. The function edit_user() is not used. We could rename the hook to network_user_new_form, but there is no obvious hook to manipulate the data that is coming in. wpmu_create_user() is used directly in this context.

wp-admin/user-new.php and wp-admin/network/user-new.php need a bit of an overhaul to clean up the supremely hacky multisite handling in both contexts. The network form is also a skeleton — user and email only. The context is significantly different, and while it can be handled with an is_network_admin() check, it's more likely that someone will attach a callback to user_new_form and end up creating a non-working field in the network admin.

In 25631:

Related #13339, which requests a hook for the network admin new user form.