Opened 7 years ago
Last modified 2 years ago
#43536 accepted defect (bug)
Network registration page
Reported by: | SGr33n | Owned by: | 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)
Change History (13)
#2
@
7 years ago
- Component changed from General to Login and Registration
- Focuses template removed
- Version 4.9.4 deleted
#3
@
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 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
@
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
@
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.
#7
@
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 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)
#8
@
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.
#9
@
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
@
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; }
*custom class