Make WordPress Core

Opened 7 years ago

Last modified 2 years ago

#43536 accepted defect (bug)

Network registration page

Reported by: sgr33n's profile SGr33n Owned by: sabernhardt's profile sabernhardt
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Login and Registration Keywords: has-patch
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.

Attachments (2)

43536.diff (1.9 KB) - added by sabernhardt 3 years ago.
43536.1.diff (1.2 KB) - added by sabernhardt 2 years ago.
only adding body classes

Download all attachments as: .zip

Change History (13)

#1 @SGr33n
7 years ago

*custom class

#2 @afercia
7 years ago

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

Related: #40361 and #23637.

#3 @jeremyfelt
7 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
7 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
4 years 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
4 years ago

Lol, thanks for upping :)

@sabernhardt
3 years ago

#7 @sabernhardt
3 years ago

  • Keywords has-patch added
  • Milestone changed from Awaiting Review to 5.9
  • Owner set to sabernhardt
  • Status changed from new to accepted

Related: #40338 (styling and JS errors in bundled themes)

Changes in 43536.diff:

  • Correcting the is_home value
  • Adding a body class to reflect each template
  • Centering the Activate form container (90% width, which probably should also include a max-width of about 600px)
Last edited 2 years ago by sabernhardt (previous) (diff)

#8 @sabernhardt
3 years ago

  • Milestone changed from 5.9 to Future Release

It's too late for this release, so I'll move it to Future consideration.

@sabernhardt
2 years ago

only adding body classes

#9 @sabernhardt
2 years ago

  • Milestone changed from Future Release to 6.1

Simply setting is_home to false in 43536.diff was inadequate, but #39703 should be a better ticket to fix the query (and possibly the page titles).

Adding a body class for each page could be helpful, even after the query is fixed.

#10 @sabernhardt
2 years ago

On #40361, @afercia suggested adding a class to distinguish each of the screens. The stage variable may not be good enough, but if it is, the signup body classes function could be like this:

function wpmu_signup_body_class( $classes ) {
	$stage_class = isset( $_POST['stage'] ) ? $_POST['stage'] : 'wp-signup-default';
	$classes[]   = 'wp-signup ' . $stage_class;

	return $classes;
}

#11 @sabernhardt
2 years ago

  • Milestone changed from 6.1 to Future Release
Note: See TracTickets for help on using tickets.