WordPress.org

Make WordPress Core

Opened 3 years ago

Last modified 7 months ago

#43536 new defect (bug)

Network registration page

Reported by: SGr33n Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Login and Registration Keywords:
Focuses: multisite Cc:

Description

Hi,
The registration page for the WordPress Multisite version, has, inside its body, the class page-id-xxx where xxx is the id of the page_on_front.

This is in my opinion a bug, and makes impossible to customize this page via CSS because every rule will be also referred to the page_on_front.

Then it should be useful to have a custom css on the body of the network registration page, something like network-registration-page.

Thanks.

Change History (6)

#1 @SGr33n
3 years ago

*custom class

#2 @afercia
3 years ago

  • Component changed from General to Login and Registration
  • Focuses template removed
  • Version 4.9.4 deleted

Related: #40361 and #23637.

#3 @jeremyfelt
3 years ago

Hi @SGr33n, thanks for the ticket.

I think this can be traced to an assumption where if a query isn't detected to be anything else, then we assume is_home() is true.

Lacking some kind of is_wp_signup() or a refactor of that area, there might not be a great way of avoiding the page ID being output.

A couple possibilities:

  • Add a body_class filter in wp-signup.php to always add a wp-signup or similar class.
  • Leave it to themes to check $_SERVER['REQUEST_URI'] or $wp->request and add their own body class filter.

My gut says that if we add a filter in wp-signup.php, we should do so after things have been refactored via a ticket like #31928 or #33500. It's entirely possible to add a filter at the theme level now and if we made changes to wp-signup.php, we add to the list of things to keep track of.

#4 @SGr33n
3 years ago

Tnx @jeremyfelt ! the check for $_SERVER['REQUEST_URI'] looks a good workaround.
Anyway I hope this can be fixed in one of upcoming updates.

#5 @markparnell
7 months ago

Ran into this today and figured someone else must have noticed. Sure enough, found this ticket. :-)

I agree with @jeremyfelt that it appears to be related to the assumptions around is_home() et. al. - in our case what we noticed was that the body had the home class, which meant that certain styles intended to be specific to the home page were being applied to both wp-signup.php and wp-activate.php. On further investigation we found that is_home() and is_front_page() both return true also.

It's certainly possible to work around it by detecting the URL (and that's what we've done for now), but it would be nice to get this fixed properly in core. Ideally these scripts should be identified as not being the home page and the relevant flags set accordingly.

#6 @SGr33n
7 months ago

Lol, thanks for upping :)

Note: See TracTickets for help on using tickets.