WordPress.org

Make WordPress Core

Opened 2 years ago

Last modified 9 months ago

#22139 new enhancement

Hooks for wp-login customization

Reported by: borkweb Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 3.4
Component: Login and Registration Keywords: has-patch
Focuses: Cc:

Description

I have an application that leverages wp-login.php as the login page (of course), however, the HTML on the wp-login.php doesn't have a way for my application to insert its navigational elements, branding, etc.

I propose the addition of two new action hooks: login_before_container and login_after_container which would come before and after the login div, respectively.

Attachments (1)

wp-login.diff (665 bytes) - added by borkweb 2 years ago.
Addition of two new hooks

Download all attachments as: .zip

Change History (12)

@borkweb2 years ago

Addition of two new hooks

comment:1 @DrewAPicture2 years ago

Related (sort of?): #21506 - Standard Theme Hooks

comment:2 @borkweb2 years ago

The concept behind #21506 is similar to this, I suppose, in that it proposes some standardized hooks in twenty ten that can be leveraged to do what I want to do with wp-login.php...to a degree. Because this diff addresses wp-login.php, I'd say it is a different beast.

The hook names that I used may definitely be worth debating, though. The attached diff was my (lame?) attempt at picking a suitable name :)

comment:4 @SergeyBiryukov2 years ago

  • Version changed from trunk to 3.4

comment:5 follow-up: @misterbisson2 years ago

+1 for this. The diff is just two do_action calls that make it possible to significantly redesign the login page. Combined with some .htaccess rules you can do this: https://accounts.gigaom.com/subscription/sign-in/

Last edited 13 months ago by misterbisson (previous) (diff)

comment:6 @jeremyfelt14 months ago

  • Component changed from Administration to Login and Registration

comment:7 @ArdathkSheyna12 months ago

+2, but add additional filters for changing the login form header text (or even allow for eliminating the link entirely, leaving just the H1 tag), also for adding classes or other attributes to the form tags. For the login form itself, could even bring in the filters used in the wp_login_form() function.

comment:8 follow-up: @stgoos9 months ago

+2 as I'm currently working on tweaking the wp-login page layout heavily for a website for a small group of users only (family and friends) so the front page will be the login page.

For me the bare minimum would be the "login_before_container" hook but the "login_after_container" hook just in front of the "login_footer" hook also makes sense to me for better customization of the wp-login page.

Please include this ticket in the next WP release.

Btw [offtopic] - isn't it weird that the version field in the change properties ranges from 0.71 up to only 3.4 while the WP version is already at 3.9.1?!

Last edited 9 months ago by stgoos (previous) (diff)

comment:9 in reply to: ↑ 5 @stgoos9 months ago

Replying to misterbisson:

+1 for this. The diff is just two do_action calls that make it possible to significantly redesign the login page. Combined with some .htaccess rules you can do this: https://accounts.gigaom.com/subscription/sign-in/

What are .htaccess rules you have used for getting such a url for the wp-login.php page?

comment:10 in reply to: ↑ 8 ; follow-up: @helen9 months ago

Replying to stgoos:

Btw [offtopic] - isn't it weird that the version field in the change properties ranges from 0.71 up to only 3.4 while the WP version is already at 3.9.1?!

It's not weird; the version field is to keep track of when enhancements were requested. When it is already set, you cannot change it to something newer - it can be set to something older in the case of bugs, which may have been introduced earlier than the original reported version.

comment:11 in reply to: ↑ 10 @stgoos9 months ago

Replying to helen:

Replying to stgoos:

Btw [offtopic] - isn't it weird that the version field in the change properties ranges from 0.71 up to only 3.4 while the WP version is already at 3.9.1?!

It's not weird; the version field is to keep track of when enhancements were requested. When it is already set, you cannot change it to something newer - it can be set to something older in the case of bugs, which may have been introduced earlier than the original reported version.

Thanks for the explaination Helen - that actually makes a lot of sense :)

Note: See TracTickets for help on using tickets.