Make WordPress Core

Opened 9 years ago

Closed 17 months ago

#33165 closed enhancement (wontfix)

Remove option to not show toolbar when viewing site

Reported by: celloexpressions's profile celloexpressions Owned by: morganestes's profile morganestes
Milestone: Priority: normal
Severity: normal Version: 3.0.5
Component: Toolbar Keywords: has-patch close
Focuses: ui Cc:

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 9 years ago.
Remove the 'Show Toolbar when viewing site' option from the user admin screen

Download all attachments as: .zip

Change History (32)

#1 follow-up: @knutsp
9 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
9 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.


9 years ago

#4 in reply to: ↑ 1 @samuelsidler
9 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
9 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
9 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
9 years ago

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

#7 @morganestes
9 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
9 years ago

  • Keywords has-patch added; needs-patch removed

#9 @SergeyBiryukov
9 years ago

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

#10 follow-up: @wonderboymusic
9 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
9 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
9 years ago

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

#13 follow-up: @celloexpressions
9 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
8 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
8 years ago

  • Keywords commit added; 2nd-opinion removed

#16 @DrewAPicture
8 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 8 years ago by DrewAPicture (previous) (diff)

#17 @netweb
8 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
8 years ago

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

#19 @DrewAPicture
8 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
8 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
8 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
5 years 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.

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


4 years ago

#26 @pixeldevs
4 years ago

I would hate to see this go away. Or at least have an option somewhere to hide it. The toolbar is so invasive when trying to design a site. I immediately turn it off on every site.

#27 @pixeldevs
4 years ago

My other take on it is that there are so many quick functions / plugins that can hide the toolbar that we might not need this option baked in. Also, would the current user choices still apply if removed?

#28 @estelaris
4 years ago

There may be some changes to the toolbar after G2 is implemented. Design team recommends revisiting after G2 changes are in place.

#29 follow-up: @joyously
4 years ago

This remains a desirable change from a simplicity and consistency standpoint.

I don't agree that it is desirable to remove an option that's been there forever. It's not broken, so why mess with it? It doesn't hurt anything to remain, as useful as we variously find it. We all have different ways to use WP. For a site that is a community, it doesn't make sense for logged in users with no capabilities to have to see the admin bar. But users should still be able to choose it, if they need it.

I have not seen themes that require the toolbar to be disabled for several years.

There is still a requirement for themes in the WP repository that the theme does not hide or change the admin bar. But most themes now do adjust their styles to work with it both on or off (or they are encourage to during their review).

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


3 years ago

#31 @hedgefield
3 years ago

  • Keywords needs-design-feedback removed

It seems best to remove the design feedback label on this for now as there's not really a design to give feedback on in the traditional sense. It'll come down to discussing the arguments for or against, not so much a matter of how it looks. (FWIW, I always turn off the admin bar because I've never had a use for it).

Can we clarify what sort of timeframe we are talking about for 'after G2'? So there's some idea of when a good time is to bring this up again.

#32 in reply to: ↑ 29 @sabernhardt
3 years ago

  • Keywords close added

Replying to joyously:

We all have different ways to use WP. For a site that is a community, it doesn't make sense for logged in users with no capabilities to have to see the admin bar. But users should still be able to choose it, if they need it.

Exactly. The people who can benefit the most from removing the toolbar are users who have lower access levels/permissions, especially if login/logout links are included on the page. So installing a plugin to re-affirm their previous decision to uncheck the box would add an unnecessary burden both on those users and on the admins who receive their complaints.

With Gutenberg's fullscreen mode, the editor hides the toolbar (and side menu) there. If that was considered so much better for user experience that fullscreen was made default, surely some people will find value in choosing to hide the toolbar when viewing their site(s).

I do think the option should have less prominence. In fact, probably all of the profile page's personal options belong after the account details (or in a side column or maybe in a separate tab). The most fitting ticket for that discussion could be #37934.

I recommend closing this ticket as "won't fix" and keeping this one option in a list of options.

#33 @JeffPaul
17 months ago

  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from assigned to closed

I concur, closing as wontfix.

Note: See TracTickets for help on using tickets.