Custom Responsive Settings in Gutenberg Blocks

Рет қаралды 6,370

Күн бұрын

Add custom settings fields to any Gutenberg block. In this tutorial, we add a responsive display setting to Gutenberg using 10up's Block Extension API, the WordPress Scripts build process, and the WordPress Base Styles Sass library.
🚨 Free Video Series: 7 Tools for Modern WordPress Development 🚨
👉 briancoords.com/7tools
👉 Full code: github.com/bacoords/example-b...
👉 10up Block Extension API - github.com/10up/block-compone...
👉 WordPress Scripts - github.com/WordPress/gutenber...
👉 WordPress Base Styles github.com/WordPress/gutenber...
👉 My WordPress Newsletter - www.briancoords.com/newsletter/
00:00:00 What is a block "setting"?
00:01:41 Our plugin's structure
00:02:51 WP Scripts and our build process
00:03:51 Asset PHP File from WP Scripts
00:04:09 Starting with registerBlockExtension
00:05:03 Attributes in blocks and block.ison
00:07:01 Our custom Edit component
00:07:58 Using InspectorControls in our Edit component
00:10:27 WordPress/Components Library
00:11:22 Handling attributes in our component
00:12:33 The Generate Class Names function
00:13:19 Enqueuing Block Editor Assets
00:15:23 Testing our ToggleControl
00:15:59 Adding the SelectControl Component
00:20:00 generating class names
00:22:07 Sass with WordPress Scripts
00:23:55 Enqueueing a block stylesheet
00:26:31 Using WordPress Base Styles
00:29:42 Gutenberg breakpoints and mixins
00:31:04 Testing our responsive styles
00:31:39 Frontend vs Editor Styles
00:35:37 Wrap up and final testing

Пікірлер: 29

@Shawn-Mosher Ай бұрын

Very informative! Would love more of these in-depth videos!

@BrianCoords Ай бұрын

Thanks! That's the plan.

@antonio.carreira 10 ай бұрын

Wow! Great video with such valuable information. I've binged watched all the videos in your channel and my morning went out the window. I wish there were a ton more videos. One of the greatest weaknesses of Gutenberg is the lack of up to date documentation and real life examples of how to proper use, create and extend blocks. FSE + custom blocks = ultimate framework for WordPress development. I spent the last few months trying to wrap my head around React. Coming from a self taught PHP background it was a real nightmare. I've tried a bunch of plugins that allow you to create custom blocks (ACF, Lazy Blocks, Block Studio), but soon realized I needed to learn how to create custom blocks from scratch if I wanted to have full control over everything. I hope you keep doing this type of videos, it really makes a difference! ;)

@BrianCoords 10 ай бұрын

Yeah I agree with all of this- WordPress had 20 years to build a ton of great community resources and now it feels like we're all starting from scratch. I didn't see Wicked Block Builder on your list but it's another one worth trying for anyone interesting. That said, I agree that it's just better to learn all of this stuff from the fundamentals. I'm self-taught everything too and I feel like I'm finally turning the corner with React and at least understanding it a bit better. It takes a while but we'll all get there.

@antonio.carreira 10 ай бұрын

@@BrianCoordsI didn't know Wicked Block Builder. Very interesting solution indeed! One of the great things about learning how to build custom blocks from scratch is that you can apply the knowledge to this kind of plugin as well. Things do make a lot more sense when you know what's going on under the hood. I agree that it feels like we're starting from scratch, and the lack of updated documentation and proper real life tutorials are the main culprits. At some point I gave up the official WordPress block documentation and switched to 10up's, because it's updated a lot more often. Sometimes I'm not sure if I'm stuck with some WordPress/Gutenberg problem or if it's just some React feature I'm not familiar with. It takes a lot of googling, and not that many results. But, once you can get past that initial inertia and wrap your head around FSE and custom blocks, there's really no turning back. Forget about page builders, dozens of 3rd party plugins, and code bloat. :)

@ljevarster 6 ай бұрын

Hi, great videos! Is there a way to kinda wrap existing core block options with our custom stuff? For example, I would like to add a dropdown with responsive options next to the padding and margin settings for some core blocks. Much appreciated

@BrianCoords 6 ай бұрын

You can definitely add your own responsive settings to core blocks. I cover that in this video: kzfaq.info/get/bejne/b5NmebKfnbunXWw.html But there are limitations to where in the sidebar you can add it.

@benbaker9931 Жыл бұрын

Hey Brian, great walkthrough on how to achieve customising standard WP Blocks. It's actually the first video I've come across that makes the process look easy, so well done. I wonder, what would be your approach to modifying an existing block attribute? For example,, on the Heading block to adapt the font size selector to accept an array of values for responsive settings? Mobile/Tablet/Desktop/Widescreen spring to mind, and then the standard select component to choose the native font-size. Is this something that's feasible? Considering the amount of development in the Block Editor space over the past years and the move toward FSE, it seems a glaring issue that WP suffers from such poor lack of RWD controls.

@BrianCoords 11 ай бұрын

The lack of responsive controls is definitely an issue, but it's pretty clear that it's never going to come to core. I know that OllieWP has done some mockups of what responsive controls would look like: olliewp.com/a-native-and-iterative-approach-to-responsive-control-in-wordress/ These mockups would require a major re-thinking of the block editor that I don't think would ever happen. That said there are also plenty of plugins that add these settings to the block editor: gutenbergmarket.com/news/making-the-gutenberg-block-editor-responsive Otherwise if you want to inject them manually, you'd probably need to add a LOT of custom settings fields and a lot of custom CSS. And you'd need to do a lot of pre-planning about what classnames you'd have to correspond to every media query and font size.

@benbaker9931 11 ай бұрын

Hey, thanks for the reply! Why is it clear that it's never going to happen? Has it been stated somewhere? As the block editor contains the ability to modify an element's padding, margins, font size etc., and by the very nature of how the web has been since RWD came along(all those years ago) and with the advent of container queries becoming stable, it feels like not having a native/in-built mechanism to handle adjustments in values at specific breakpoints is a real limitation for anyone wanting to create a flexible design system in the WP block editor. Has it been parked as it's a reasonably complex issue? I quite like OllieWP's approach where the end user can enable a more in-depth mode to edit responsive styles.

@BrianCoords 11 ай бұрын

@@benbaker9931 I've seen it mentioned in a few places, but this is probably the clearest explanation of what WordPress plans with intrinsic design vs responsive design: developer.wordpress.org/news/2023/02/intrinsic-design-theming-and-rethinking-how-to-design-with-wordpress/

@benbaker9931 11 ай бұрын

@BrianCoords Thanks for the link. It's for sure an interesting area of discussion in design. I am not convinced it can act as a replacement for RWD as it feels like it doesn't offer the control required, but will do further reading in the area, as this could be a mindset shift for me... I feel like the idea of IWD is a sound one and certainly presents a utopia of design for the web that just 'flows'. In reality, I can't help but think it's an over simplification of the design systems we're challenged to create. An example of IWD using font-size is a pretty straightforward one (using CSS clamp()), but if you were to delve into a nuanced design that has specific variations and layout logic for grid layouts etc., it feels as though it falls short. I can see why this is a challenge for any CMS, and for sure it's going to be an interesting space to watch, particularly in light of the strong decisions that the WP team are making in this area.

@BrianCoords 11 ай бұрын

I agree - it sounds like a great idea overall but if you're in the business of matching specific designs or dealing with picky clients it's definitely a little harder.

@mto88a 7 ай бұрын

Thanks! The wordpress base styles sounds like a great approach. Do you know what are the default brealkpoints in the editor? (Desktop, tablet and mobile) or how to customize in a block theme?

@mto88a 7 ай бұрын

Updating my comment, defaults responsive max-width are (the responsive buttons in the editor): desktop: 100%, tablet: 780px, mobile: 360px

@BrianCoords 7 ай бұрын

You can actually see ALL the breakpoints WordPress core uses (for the editor and for blocks) here: github.com/WordPress/gutenberg/blob/trunk/packages/base-styles/_breakpoints.scss

@spitsparrow 4 күн бұрын

Do you have a video that shows how to change stacking order of column block on mobile? Its annoying that the columns are stacking left to right no matter what. Almost always need to change the order. Is it as simple as adding css snippet to the a column block?

@BrianCoords 4 күн бұрын

I don't, but yes you can definitely do it with CSS, by registering a block style or just adding a class to your columns block and adding the CSS to your theme or in the "Additional CSS" panel.

@weristsam 5 ай бұрын

Hello Brian, i follow your tutorial but in my case the old classes still in the string which added to the block. How i can remove the old classes "has-responsive-large" before i add the new class "has-responsive-small" ?

@BrianCoords 5 ай бұрын

If the old classes aren't disappearing, you can select the block, open the sidebar and find the 'Advanced' tab. There you can manually delete the classes. When you switch the setting in the future it should be swapping out the classes, not just adding them.

@mto88a 7 ай бұрын

What docs are you using?

@BrianCoords 7 ай бұрын

The docs I reference should be in the video description- mostly everything about the block editor is documented somewhere in the Gutenberg repository, though it takes a while to find it. Anything you're looking for in particular?

@simbaclaws_youtube 11 ай бұрын

Suppose you want some blocks not to be displayed on mobile, or you want a different layout on mobile in it's entirety, then adding classes wouldn't help since writing display:none; will not help with screen readers and accessibility.

@BrianCoords 11 ай бұрын

Good point. It completely depends on how you're using it. Typically anything styled with display:none will be ignored by screen readers (which could be useful if you have the same content in multiple places). If you want the content to still be read, then there are great examples of "visually-hidden" style classes that remove content while still keeping it accessible to screen readers.

@simbaclaws_youtube 11 ай бұрын

@@BrianCoords I thought screenreaders would also read hidden elements. Must be something I haven't checked in a while. Anyhow, cluttering up the dom with elements that you don't use still is a bad idea IMO. I've solved my problem differently. I build a plugin that creates 3 blocks: desktop, tablet and mobile. Anything can be placed inside these blocks and get rendered conditionally using a php library called mobiledetect. It allows me to detect desktop, tablet or mobile viewports and helps in a render callback to conditionally display content that was placed inside the blocks. on top of that I added some flare to the gutenberg post editor and site editor to only display the inner blocks when you are in the correct preview mode. This has worked great for an adaptive approach to conditionally rendering content based on the viewport. It was my personal solution to fixing the missing responsive controls. I still think blocks should be made fully responsive, but now I can also adapt the content based on the viewport. Best of both worlds.

@BrianCoords 11 ай бұрын

@@simbaclaws_youtube Agree on cluttering up the dom, but unfortunately it's pretty standard practice with page builders and even frameworks like Bootstrap. The downside of using PHP like that is that you now need to run PHP on every page load- you can't as aggressively cache the front of your size and deliver it a little more statically. Just something to keep in mind. Though WordPress does have a similar function: developer.wordpress.org/reference/functions/wp_is_mobile/

@simbaclaws_youtube 11 ай бұрын

@@BrianCoords Ah so what you are saying is that the caches generated for these pages don't work correctly for different screen sizes? Hmmm I'm wondering how I should tackle that... Is there some sort of api where I can make sure that specific content gets cached for mobile or tablet? I also can not really deliver a static website because it automatically fetches information from a different service every hour, and has a lot of dynamic components. Not quite sure if I'm even able to do that statically....

@BrianCoords 11 ай бұрын

@@simbaclaws_youtubeYeah in that case then it might not matter.