Allow login form to be completely taken over

[Viper007Bond]

Right before any HTML is outputted, I think it'd be great to stick hooks. This way, if you wanted, you could output your own entire HTML and then die(); rather than just skinning the existing login form.

Brought about by seeing ​Playstation US's blog and realizing that they either had to edit the output buffer or the actual wp-login.php to accomplish their severe customization.

Flexibility for the win! :)

[markjaquith]

How about hooking on init, with a PHP_SELF comparison as the activating criterion?

[Viper007Bond]

Replying to markjaquith:

How about hooking on init, with a PHP_SELF comparison as the activating criterion?

That'd currently work, but then you would have to replicate all of the PHP that goes on in wp-login.php and keep it up to date as WP progresses with new versions.

I'm just talking about being able to have entirely custom HTML.

[richcon]

Why not make the login and registration screens completely template-based? So there would be a login.php in the default theme that other themes can override, or add 'login' and/or 'registration' forms to any page they want. This seems to me like the ultimate solution for bringing those pages in line with the rest of a site's design.

[Otto42]

I don't see why Playstation's blog would have needed more than a custom plugin to do what they did. wp-login.php is littered with hooks, and their customizations appear to be using those hooks, near as I can tell.

Reference Ticket #3123

[JeremyVisser]

I disagree that wp-login.php should be based on the frontend theme. It is part of the backend.

[foolswisdom]

Replying to JeremyVisser:

I disagree that wp-login.php should be based on the frontend theme.
It is part of the backend.

One person's backend is another person's frontend ;)

[cpoteet]

+1 for Richon's suggestion.

[DD32]

Possibly another method that could be used is a action before most of the wp-login.php code is run.

A plugin could hook the action and then die to prevent the main login page running. That can be done in the admin section already by hooking the load-page.php action, So maybe doing the same for the login form should be possible if its 'backend' and as such, not template styled.

[Viper007Bond]

Replying to Otto42:

I don't see why Playstation's blog would have needed more than a custom plugin to do what they did. wp-login.php is littered with hooks, and their customizations appear to be using those hooks, near as I can tell.

Reference Ticket #3123

Yes, the "date of birth" is easy as cake due to #3123 but the sidebar, header, etc. aren't unless I'm missing something obvious.

[oaoao]

+2 for Richon's suggestion.

[stealthdave]

The attached patch allows template designers to create a custom login_header() and/or login_footer() function in $templatedir/login.php. Attached sample login.php template shows implementation with standard template header, footer and sidebar.

[stealthdave]

Patch to allow custom login / registration templates from template. Updated patch works with 2.5.1.

[stealthdave]

Sample login.php file to demonstrate custom templated login pages. Updated sample works with 2.5.1.

[stealthdave]

Updated patch now works with 2.5.1. Also abstracts out the error messaging code from the login_header into its own function, allowing it to be reused in the custom login template.

[mrgreen]

Thanks for starting this, it's an important improvement!

[westi]

The current patch doesn't cut it for me.

What would be better would be to move as much as possible of the code in wp-login.php into a file in wp-includes and then use the normal wp-includes/template-loader.php code to load a login template if one exists and otherwise fallback to the current code - albeit in the more function based approach.

Pushing out to 2.7 for now until we have a bigger patch ;-)

[stevish]

+3 for Richon's suggestion!

It seems silly to have to use a plugin just to use a template on the login screen. Sure, it's been argued that the login screen is "Backend" but I have a family blog, and I have users that are most definitely "front end", who need to log in in order to see my website. It's very confusing to some of them if they type in my website, and are redirected to a funny looking page that has absolutely nothing to do with me or my site.

[stealthdave]

Make that +4

Logging in and Registration are often required of "normal users" for many things. Commenting and "members only" pages (such as stevish's family blog) often require being logged in. Good application design alone recommends that you separate business logic from your display logic. Once you've done that, you're only a step away from templated login / registration pages.

As for the existing patch, I'm told that it applies just fine to 2.6, although I haven't tried it myself, yet. I probably won't have time to attempt tackling westi's larger patch for some time.

[caesarsgrunt]

+5 for Richon's suggestion!

For all the reason's already discussed above.

[ShaneF]

+6 :)

[pampfelimetten]

+7, i would use that in three of my five blogs.

[here]

+8 , see previous at #1155 not resolved by #3123

Login link is often left somewhere in front-end user interface. Thus, this includes users and robots who cannot / should not login, but should see something other than a generic wordpress login page as their dead-end. Optionally theme-able is a huge feature, thanks.

[stealthdave]

I know you were looking for a bigger patch, but I've gone the other route and created a smaller one instead. :) This is essentially the same patch, but compatible with 2.7.1 (and probably 2.7, but I haven't checked). This really doesn't change much in the wp-login.php file. The major change is to separate the error messaging from the login_header() function and add a login_footer() function. The latter just dumps </body></html> to the page. The patch is about half the size, and the sample login.php file remains unchanged.

When I have time, I may look at doing a "bigger patch" as described above, but I would ask that you reconsider accepting the patch as-is. The changes are minimal, existing templates are completely unaffected, and it adds a feature that many users have been requesting for some time. The milestone on this has slipped at least 3 times since I submitted this patch, and I would *love* to see it included in 2.8, in some form or another.

[stealthdave]

2.7.1 compatible patch, moves login_error out of the template so that it is always displayed.

[stealthdave]

new sample login for updated patch removes login_header_error call

[stealthdave]

Okay, after looking over the patch, I made a change to remove the error messaging from the template altogether. This is something that, IMO, should always be displayed on the page regardless of whether the author included it in the template or not. This means that the patch is not smaller any more, but the sample login page is. Unfortunately, it does break compatibility with the previous patch, but all you need to modify to make it work is to remove any call you made to login_header_error() in your template. It is now automatically called immediately after the header in all cases.

[ryan]

Use locate_template() and fix login_error()

[Denis-de-Bernardy]

+1 too. but needs testing and probably too late for 2.8. moving to 2.9...

[Denis-de-Bernardy]

See also: #9682, which sorts this out differently.

[Denis-de-Bernardy]

see #9682