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

Navigation: Allow additional CSS classes #18466

Merged
merged 6 commits into from
Nov 15, 2019
Merged

Conversation

obenland
Copy link
Member

Fixes a bug where additional CSS classes were not passed to the front-end.

How has this been tested?

When creating a navigation menu, add a CSS class in block settings.
Preview the block and make sure the class gets applied to the nav element.

Types of changes

Bug fix (non-breaking change which fixes an issue)

Checklist:

  • My code is tested.
  • My code follows the WordPress code style.

@obenland obenland added [Type] Bug An existing feature does not function as intended [Feature] List View Menu item in the top toolbar to select blocks from a list of links. [Block] Navigation Affects the Navigation Block labels Nov 12, 2019
@obenland obenland self-assigned this Nov 12, 2019
Copy link
Contributor

@draganescu draganescu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! This is great, since adding the classname was there in the editor but not rendering it made it useless /o\

In my testing adding a css class now results in it being rendered, but it also adds an empty style attribute to the nav root element.

Screenshot 2019-11-13 at 12 32 07

@obenland
Copy link
Member Author

It'll be empty if there are no custom colors selected and shouldn't have any detrimental effect on display or performance of the block.

@draganescu
Copy link
Contributor

Can't we not have it? Other blocks seem to manage this very well and avoid empty attributes at all times in what I have seen so far :)

@karmatosed
Copy link
Member

Glad to see this being fixed. I was adding in some style variations and found this issue.

$colors = build_css_colors( $attributes );
$class_attribute = sprintf( ' class="%s"', esc_attr( $colors['css_classes'] ? 'wp-block-navigation-menu ' . $colors['css_classes'] : 'wp-block-navigation-menu' ) );
$style_attribute = $colors['inline_styles'] ? sprintf( ' style="%s"', esc_attr( $colors['inline_styles'] ) ) : '';
$colors = build_css_colors( $attributes );
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this function build_css_colors not intended to be namespaced / prefixed specific to the plugin / block / WordPress? (i.e. is it meant to be for general usage?)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a namespacing standard for PHP functions in Gutenberg?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a namespacing standard for PHP functions in Gutenberg?

Now that you mention it, not explicitly.

For most functions, we follow best practices in using a gutenberg_ prefix for plugin-specific functions.

It's a little trickier for these blocks though, since they're copied verbatim into core. So the concern is in considering that, should this be merged to core, these become new global WordPress functions.

Most other dynamic blocks follow some convention of render_block_foo and register_block_foo, but there's definitely some (unfortunate) ad hoc naming for similar utility functions (example).

It's definitely not a blocker for merging this pull request, since it wasn't introduced here, but we should see about establishing a convention here that makes sense.

Copy link
Member Author

@obenland obenland Nov 15, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

namespace Gutenberg; 😱

@obenland obenland merged commit 5d4a752 into master Nov 15, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Block] Navigation Affects the Navigation Block [Feature] List View Menu item in the top toolbar to select blocks from a list of links. [Type] Bug An existing feature does not function as intended
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants