Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OpenLab Theme- Subsites with a sticky header leaves gap #324

Open
beckej13820 opened this issue Dec 13, 2020 · 6 comments
Open

OpenLab Theme- Subsites with a sticky header leaves gap #324

beckej13820 opened this issue Dec 13, 2020 · 6 comments

Comments

@beckej13820
Copy link

When using a theme that has a Sticky Header, OpenLab pushes the sticky header down the page in a way that is a little awkward, creating a gap between the top of the page and the floating menu.

Some examples from oneonta.sunycreate.cloud:

Twenty Seventeen theme:
Screen Shot 2020-12-13 at 6 19 48 AM

Fluida theme:
Screen Shot 2020-12-13 at 6 25 51 AM

I'm pretty sure that this is affecting every theme, including core WP themes and contributed community themes.

@boonebgorges
Copy link
Member

Thanks for the report. We have noticed this on the City Tech OpenLab project in the past (internal link: http://redmine.citytech.cuny.edu/issues/2710)

The underlying problem is that WP's toolbar is fixed, so that it always remains at the top of the viewport when scrolling. Themes are then developed to expect this behavior. The CBOX-OL toolbar is not fixed (and if it were, it would be a slightly different height). Unfortunately, there is no great fix for this, aside from a rebuild of the CBOX-OL toolbar that gives it the same dimensions and behavior as WP's toolbar. This may be something we pursue in the future, as our customizations lead to other problems; see eg #321.

For now, the best I can suggest is theme-specific fixes. For example, in the case of twentyseventeen:

@media screen and (min-width: 48em) {
       .admin-bar .site-navigation-fixed.navigation-top {
               top: 0;
       }
}

@boonebgorges boonebgorges added this to the Future Release milestone Dec 14, 2020
@beckej13820
Copy link
Author

Thank you for your reply. I didn't realize that it was related to the collapsing issue I reported recently. I would be supportive of a variety of solutions, including making the openlab toolbar behave more like core WordPress. It is simultaneously a small issue and yet, pretty prominent of an issue if our goal is good looking portfolios for students.

@ajeannette
Copy link

Hello OpenLab team! I've also run into an issue with the OpenLab header on my students' portfolio sites, although it is slightly different than Ed's.
I've noticed that the OpenLab header has a tendency to overlap content if it (the header) ever needs to expand, like when a site's name is particularly long, or a new plugin shows up in admin view.
See the screenshot below for a visual example:
Screen Shot 2021-02-25 at 2 17 50 PM
The students I'm currently working with have reported that this overlap has caused visibility issues when they're editing their sites when text at the top of the site is cut off.
Would it be possible to make the header avoid overlap in general and simply bump body content down when it needs to expand?
Thank you so much for all of your work on this truly awesome platform!

@boonebgorges
Copy link
Member

Thanks for the report @ajeannette. I think that what's happening here is that there are too many elements in the toolbar, and it's causing the 'Hi, Amanda...' section to pop down to a second line. To confirm this, I recommend either (a) disabling WPForms temporarily (which should remove the WPForms button, which should in turn allow the toolbar items to fit in the allocated horizontal space), or (b) use your browser's console tool to hide one or more items on the toolbar (such as the WPForms button)

If my hunch is correct, then there aren't a lot of clear ways for CBOX itself to address the issue, especially when the buttons are added by non-CBOX plugins like WPForms. If this plugin in particular is posing problems across your network, it might be possible to write a bit of code that will specifically target it, by removing that button whenever the plugin is activated.

@beckej13820
Copy link
Author

Hi Boone,

In Vanilla Wordpress, the Black toolbar doesn't expand to become multiline if there is an overflow.

Screen Shot 2021-02-25 at 4 06 32 PM

So in the image above, although it is not ideal that the text has overflowed the container, it visually doesn't stop the site from working or cover headers or controls.

I'm going to say something that might sound a little hyperbolic, because a little gap in the header or header misbehaving doesn't seem like a big deal, but I actually believe that the header right now is one of the biggest issues in OpenLab. Other features are nice, but at its core, what we want students to be able to do is making really great-looking websites, and any issue with the header, however small sticks out like a sore thumb.

Amanda and I have really enjoyed collaborating with the OpenLab team, and we would love to talk about, brainstorm what some solutions might look like. I was thinking of possibilities, but in my head those all involve make the OpenLab Header more like the default Wordpress toolbar behavior:

Making it sticky so the offset required for the page is predictable.
Making it shorter so that Wordpress' core adjustments work for all of our sites.
Removing it completely for non-logged-in users or creating an option to remove it for non-logged-in users.

I know those students really work hard on the visual look of their pages, and I hate any little blemish that they can't control.

@boonebgorges
Copy link
Member

So in the image above, although it is not ideal that the text has overflowed the container, it visually doesn't stop the site from working or cover headers or controls.

True. But by the same token, many of the buttons that cause the overflow for logged-in admins will not appear for logged-in non admins, or for non-logged-in visitors.

An easy way to hide the toolbar for non-logged-in users feels like a fairly obvious win. Building an admin tool that will allow this involves a bunch of UX decisions, but in the meantime you can do it in an mu-plugin as follows:

add_filter(
	'show_admin_bar',
	function( $show ) {
		if ( ! cbox_is_main_site() && ! is_user_logged_in() ) {
			return false;
		}

		return $show;
	},
	1000000
);

This disables the toolbar for all logged-out users, except on the main site, where it's a more critical part of the layout.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants