WordPress.org

Make WordPress Core

Opened 4 years ago

Last modified 5 months ago

#33165 assigned enhancement

Remove option to not show toolbar when viewing site

Reported by: celloexpressions Owned by: morganestes
Milestone: Future Release Priority: normal
Severity: normal Version: 3.0.5
Component: Toolbar Keywords: has-patch needs-design-feedback
Focuses: ui Cc:
PR Number:

Description

At least for new sites (and/or new users?), this option in the user profile screen can probably go away in core. The toolbar is essential to most modern workflows with WordPress, providing the ability to get between the front end and the admin contextually. While there are use cases where it's better if it's not there, those seem like plugin territory.

Should the average user be able to hide their navigation back to the admin when they're on the front end? Is the default behavior of showing the toolbar when viewing the front end best for most users? I think the answer for both is overwhelmingly yes. Also, should this be a per-user preference, as opposed to per-site? I'd say probably not, at least in core. Plugins could implement the option on a per-site or per-user basis as needed.

For consideration, I'd be interested in any stats that anyone may be able to pull regarding users that have the toolbar turned off.

Attachments (1)

33165.diff (1.2 KB) - added by morganestes 4 years ago.
Remove the 'Show Toolbar when viewing site' option from the user admin screen

Download all attachments as: .zip

Change History (23)

#1 follow-up: @knutsp
4 years ago

Agree.

But I would prefer a way to hide it temporarily, through a button on the bar itself. So make in a "per view" option, eventually.

#2 @morganestes
4 years ago

  • Keywords needs-patch ux-feedback added
  • Version set to 3.0.5

Since the toolbar is such an integral part of the administration of a site, removing the UI to change it seems like a good case of "decisions not options".

It's already set to show by default when a new user is created (see trunk/src/wp-includes/user.php#L2036). We can continue to honor the settings of the current users by removing the UI in trunk/src/wp-admin/user-edit.php@33450#L271 but leaving the rest of the code in so it can still be hooked into with a plugin.

This ticket was mentioned in Slack in #design by morganestes. View the logs.


4 years ago

#4 in reply to: ↑ 1 @samuelsidler
4 years ago

  • Keywords ux-feedback removed
  • Milestone changed from Awaiting Review to Future Release

This got a big "yea!" (see Slack logs linked to above), so let's do it. Targeting to Future Release for now, but if there's a patch, we should definitely get this in 4.4.

Replying to knutsp:

But I would prefer a way to hide it temporarily, through a button on the bar itself. So make in a "per view" option, eventually.

Better than that, Helen proposed that ti should hide when scrolling down and re-appear when scrolling up. Seems like a great idea. Is there already a ticket on file for that?

#5 follow-up: @jeremyfelt
4 years ago

A nice reason to disable the bar now is when the number of sites you belong to adds a significant chunk of data to each page request. Or when troubleshooting front end views as if you were authenticated without being stuck with page cache. Also, among our network users, hiding the admin bar is a pretty popular request. I personally like having that option available and flip back and forth often, though would like it more if it was in a smarter place.

That said, a plugin would work. :)

#6 in reply to: ↑ 5 @samuelsidler
4 years ago

Replying to jeremyfelt:

A nice reason to disable the bar now is when the number of sites you belong to adds a significant chunk of data to each page request.

That sounds like working around a problem that shouldn't exist. ;) We should fix that issue instead of keeping this preference.

But yeah, a plugin also works well. :)

@morganestes
4 years ago

Remove the 'Show Toolbar when viewing site' option from the user admin screen

#7 @morganestes
4 years ago

We can start by removing the UI from the user screen but leave the 'show_admin_bar' filter and associated code in place for plugins to use to hide the admin bar.

#8 @morganestes
4 years ago

  • Keywords has-patch added; needs-patch removed

#9 @SergeyBiryukov
4 years ago

  • Keywords commit added
  • Milestone changed from Future Release to 4.4

#10 follow-up: @wonderboymusic
4 years ago

  • Keywords needs-refresh added; commit removed

what happens if the user has toggled it off, we drop in this change, and then they want to activate the toolbar again?

#11 in reply to: ↑ 10 @morganestes
4 years ago

  • Owner set to morganestes
  • Status changed from new to assigned

Replying to wonderboymusic:

what happens if the user has toggled it off, we drop in this change, and then they want to activate the toolbar again?

Even though the UI is removed, the underlying functionality still exists. A couple of working options I came up with:

  1. re-activate for a specific user by updating the setting:
    update_user_option( $user_id, 'show_admin_bar_front', 'true' ); 
    
  2. Use a filter to show the admin bar for a user, regardless of the user's setting:
    add_action('init', function() {
        if ( get_current_user_id() === $user_id ) {
            add_filter( 'show_admin_bar', '__return_true' );
        }
    });
    

The first option is better for a single user, since it's only set once and is checked already by _get_admin_bar_pref(). The filter option is best if you don't know the user ID, if you want to show the toolbar based on a different conditional check, or if you want to skip conditionals and and force it on/off for all registered users.

#12 @morganestes
4 years ago

  • Keywords 2nd-opinion added; needs-refresh removed

#13 follow-up: @celloexpressions
4 years ago

I'd be inclined to force the toolbar to go back on for those that have turned it off, thereby requiring the addition of a plugin to use the non-standard (off) behavior. Such a plugin could reinstate the option and use existing on/off values, which we shouldn't manipulate when it goes on for everyone again.

#14 in reply to: ↑ 13 @morganestes
4 years ago

Replying to celloexpressions:

I'd be inclined to force the toolbar to go back on for those that have turned it off, thereby requiring the addition of a plugin to use the non-standard (off) behavior. Such a plugin could reinstate the option and use existing on/off values, which we shouldn't manipulate when it goes on for everyone again.

As a user, I'd be really frustrated that a decision I made (turning off the toolbar) was being reverted without asking me, as it would if we forced the toolbar on for everyone again.

I don't thinking forcing it on for everyone is the right move, but if that's the decision we make, we should let users know why we feel it's best to have it enabled and what they can do to disable it again if they really want it off.

#15 @morganestes
4 years ago

  • Keywords commit added; 2nd-opinion removed

#16 @DrewAPicture
4 years ago

  • Keywords commit removed

I think in removing the option, we're implicitly making a decision for the user by not allowing them to turn off the front-end Toolbar without the help of a plugin. And thus, changing the user setting back to 'on' for all users would be a reinforcement of that decision.

I also agree that it's going to be frustrating to users who use that feature. So we kind of have to make the decision about whether that's frustration we're willing to cause. I don't see selectively reenabling the UI for those users who have it enabled as a good solution either. I think it's going to have to be all on or what we have now to keep it simple.

Last edited 4 years ago by DrewAPicture (previous) (diff)

#17 @netweb
4 years ago

Take a look at https://bbpress.org/forums/, the grey bar under the green header is the WordPress admin toolbar, i.e the bar with my name "Stephen Edgar" on it, if you disable the admin toolbar as it currently is proposed in this ticket you are disabling the toolbar for ~8million w.org, bbPress.org, and BuddyPress.org users.

https://cldup.com/fDwe-UOzL4.png

The source for the above is on Meta Trac here.

I do like the premise of the ticket here and what it's trying to achieve though and I'm quite sure bbPress and BuddyPress are not the only sites who are repositioning/repurposing the admin toolbar, personally I'd like to be able to change our setup to move and resize with scroll actions like Helen has proposed above so some more considerations and backward compatibility will be needed in this ticket to proceed further.

#18 @netweb
4 years ago

Ignore my previous comment, it's late, my bad, and yes, only the "option" is being removed...

#19 @DrewAPicture
4 years ago

@morganestes I'd like to see a patch addressing feedback in comment:16. Either way, we're getting close to 4.4 Beta 1 (October 21), so we either to step up iteration or punt.

#20 follow-up: @helen
4 years ago

I seriously doubt that turning on the toolbar for everyone is realistic as we currently stand. There are any number of sites/themes out there that don't account for the toolbar (sticky headers, for instance) and leave it to users to turn it off. I don't like this, but we don't exactly make it easy to accommodate the toolbar, either.

Let's say we left the UI setting in place if the user has turned the toolbar off on front. Does that UI setting disappear if they turn it on? Do we warn them that that will happen? Are people toggling back and forth or are they setting this once?

Maybe what we need to do is come up with a better strategy for how the toolbar displays and is accommodated by themes if there are dreams of turning it on all the time.

#21 in reply to: ↑ 20 @DrewAPicture
4 years ago

  • Milestone changed from 4.4 to Future Release

Replying to helen:

Maybe what we need to do is come up with a better strategy for how the toolbar displays and is accommodated by themes if there are dreams of turning it on all the time.

I agree, in which case, let's punt to future release at which time we have a more solid plan for the outliers.

#24 @celloexpressions
7 months ago

  • Keywords needs-design-feedback added
  • Milestone set to Future Release

This remains a desirable change from a simplicity and consistency standpoint. I have not seen themes that require the toolbar to be disabled for several years. Does that concern still seem like an argument for keeping an option to disable frontend core UI in core as opposed to a plugin?

in the meantime, any usage data on this option may help inform a decision.

Note: See TracTickets for help on using tickets.