Opened 3 years ago
Last modified 2 months ago
#43536 new defect (bug)
Network registration page
Reported by: |
|
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)
#2
@
3 years ago
- Component changed from General to Login and Registration
- Focuses template removed
- Version 4.9.4 deleted
#3
@
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 inwp-signup.php
to always add awp-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
@
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
@
2 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.
*custom class