Please note that the purpose of this video is to explain how to address mobile issues when using the WordPress block editor. Every use case is subjective, and the approach should be tailored to the specific project. My example focuses on dynamic blocks, and if your content changes frequently, I wouldn’t recommend using this technique, as you may need to revisit any issues on smaller devices. In that case, it’s better to use the more advanced example, which involves adding custom CSS classes for targeting. However, if your content is more of a "set and forget" type, targeting dynamic classes should generally work fine.
@cholo26053 ай бұрын
Thanks Elliot, that's a lot valuable info🙏
@jamiewp3 ай бұрын
Great stuff !
@elliottrichmondwp3 ай бұрын
Thanks Jamie 👍
@ICodeForALiving3 ай бұрын
Hey Elliott sorry for the noob question but if my client makes a modification in the layout via his user account ( which would be role -> editor ) where would those changes be saved? Won't the database get affected here? Also in any case how can that change be made permanent ie. as a change in the .php files? Thanks Great video as always!!! ♥
@elliottrichmondwp3 ай бұрын
That's a good question. In the new block theme era, the Editor's changes are saved to the database as content. Every use case is unique (see my pinned comment). One example to make changes more permanent is by targeting the generic class, but remember that will affect all instances of that class site-wide. Another option, as shown in the last example in the video, is adding custom CSS classes to the block in the Settings under the Advanced tab > Additional CSS class(es). However, this approach has its own challenges. For instance, if the block is removed, you may end up with an unused class, which can lead to bloat over time. So, there is no perfect solution when doing this via the Block Editor. A better approach might be to handle this in code, perhaps by registering a new style, but that wasn't the focus of this video. I've covered this topic before, but I may create another video on it, which would be more developer-centric.
@stevo47752 ай бұрын
I'm having trouble locating the padding setting in Wordpress. Under my block settings I see Typography settings, but the Dimensions setting aren't there. Any suggestions? Do I need to somehow activate the dimension settings? Is it an issue with my template?
@elliottrichmondwp2 ай бұрын
Each theme comes with its own unique set of features. In the early days, some blocks didn’t include dimensions, but I’m fairly certain that’s now more consistent. The best way to check if your theme has disabled dimensions on certain blocks is to switch to a core theme like TT4 or TT5. If the dimensions appear, it’s likely an issue with your theme. Which theme are you using, and what block have you inserted?
@patsymutiso3 ай бұрын
I'm wondering how you came up with the width value you used for mobile when that can vary between all the different types of mobile devices.🤔 Im really struggling with how to know if my layouts are responsive or responsive enough 😊.
@elliottrichmondwp3 ай бұрын
480 is a standard WP breakpoint 😉
@floyd14113 ай бұрын
Thank you for these tutorial. May I ask if there is there a way to remove all default styles. that top margin is really pointless. Also even though in the theme json I try to disable the default palette, which has the effect in the editor, in the browser I can see tons of default colors in the css file.
@elliottrichmondwp3 ай бұрын
It's not really feasible to remove all default styling, as there needs to be a baseline structure in place, which is why certain decisions are made regarding default settings and styles. When you mention "top margin," are you referring to something specific in my video or something set by default? You might be referring to the Block Gap setting in the Global Styles, perhaps? Also, all those colors are set as CSS variables at the root level. While they might seem annoying, they shouldn't negatively impact performance.
@timnashcouk3 ай бұрын
So just to make sure I'm following you, saved the media queries into the global styles used for FSE and they effect the entire site, rather then styles specific to the post? I'm showing my ignorance but arn't the styles you targetted column 6 etc div class IDs generated per page so you can have 2 pages with two colums with same class names with different layouts? So is there benefits to always adding custom class names, to be sure you are targetting the thing you are targetting?
@elliottrichmondwp3 ай бұрын
Absolutely, the premise of this video is to show the process. The approach is subjective and should be tailored to your project's needs. For clarity, see my pinned comment.
@timnashcouk3 ай бұрын
@@elliottrichmondwp Absolutely to what, that targetting custom CSS classes has benefits? or that you did indeed add it to the global FSE or that pages do share identifiers?
@elliottrichmondwp3 ай бұрын
@timnashcouk * "Saved the media queries into the global styles used for FSE and they affect the entire site?" - Yes. * "You targeted column 6, etc., div class IDs generated per page, so you can have two pages with the same class names but different layouts?" - I'm not entirely sure of the specific use case you're referring to, but potentially, yes. If you have identical layouts on different pages, and the columns are dynamically numbered in the same way, this could apply. However, if you want the same fix for smaller devices across both pages, it's likely you'll need to apply it universally. That said even those block on pages could also be moved and throw the targeting out of the window ( reference my pinned comment ) * "Are there benefits to always adding custom class names to be sure you're targeting the right element?" - Yes, and this is actually my preferred approach, which is why I demonstrated it in the video. But there is a downside: if the block is ever removed, you might end up with unused CSS, leading to bloat over time. This is especially problematic if the site content changes frequently and you're using this method for every change. ( again, ref my pinned comment ) The aim of the video was to show a fundamental way of addressing layout issues on smaller devices without touching theme or plugin files. You can definitely take it further by targeting body template classes or post ID classes, but this too can result in unused CSS over time, leading to bloat. So, while there's no perfect solution, I hope the video has provided a solid starting point. The best approach really depends on the specific use case. Hopefully, it helps inspire folks with the process :)