[wp-hackers] modify or extend wp-login.php form within plugin
Alan J Castonguay
alan at verselogic.net
Sat Jun 24 22:19:40 GMT 2006
I'm working on an authentication extension for Wordpress to allow users
to register and comment via an OpenID identity. I intend to, upon
successful external authentication, create real Wordpress users via
wp_create_user(). However, the question I pose to you applies generally
to any authentication mechanism, not just OpenID.
I intend to place login boxes in a handful of natural places, such as
just above the comment field, and sidebar. This is subject to the
template author's wishes. As a catch-all scenario, I want to add OpenID
(or other authentication service) login field(s) and button to a form
inside wp-login.php. I see the following methods for accomplishing this
1. Add hooks in wp-login.php in and around the existing login form for
inserting more fields or another form. The new authentication process
can be done in wp_authenticate and ended with wp_redirect() and exit().
Otherwise return and let the normal wordpress code handle both the login
attempt and form drawing.
This option seems the cleanest. It tends to follow (my impression of)
the Wordpress way of doing things. It would be the most resilient to
future modifications of the core wp-login.php. It breaks backwards
compatibility with older revisions of Wordpress which lack the new
hooks. It requires someone to actually add and approve the new hooks.
Suggestions include some combination of pre_login_form, login_form,
2. Hook into wp_authenticate, handling both the new and old
authentication processes (normally done after that hook in
wp-login.php), wp_redirect()'ing if needed. If there was no
authentication attempt, echo() my own form (which looks just like the
one made by wp-login normally, plus a field or two), and exit().
This option fixes the backwards-compatibility problem. It might have
forwards-compatibility issues if the core Wordpress wp-login.php does
something different after wp_authenticate is called, or the form is changed.
3. Hook into wp_authenticate, handling both the new and old
authentication processes. If there was no authentication attempt, we
need to draw the form. Load the wp-login.php file into a string, use
regexes to grab just the form html, modify the string with additional
fields, and echo() it, and exit()
This tries to fix the forwards-compatibility problem by using whatever
form design and fields are present in the wp-login.php file. It still
fails if the code after wp_authenticate in wp-login.php changes.
4. On plugin load, misappropriate the /wp-login.php request, load the
wp-login.php file into a string, use regexen to drop new content into
the form, and eval() it. Hook into wp_authenticate to handle only the
new authentication and exit(), otherwise return().
This option would permit modification of the form, assuming it doesn't
change too drastically or unexpectedly. It uses the logic of
wp-login.php, so is immune to changes there. I hate using eval().
5. Do something completely off the wall, like subject the call
_e('Password Lost and Found') or its ilk to returning the original text,
plus the ending A tag, plus a whole form, textbox, submit button, ending
of form, and the beginning of a link to something to balance the
upcoming ending A tag in the original html. Handle new authentication in
Since the output values are escaped, I cannot, afaik, do this. It's also
a very Bad Idea. There has to be a better way.
Which of these options (or any other ideas) would be the preferred way
of inserting additional fields into the form generated by wp-login.php?
Alan J Castonguay
More information about the wp-hackers