- This topic has 19 replies, 3 voices, and was last updated 4 years, 7 months ago by
.
-
Posts
-
The more I learn about GP elements the more I am impressed by power and versatility of this feature. It’s mindblowing, to say the least. However, this can easily lead to heavy use of elements which might have effects on performance, especially if you use many rules.
What would you consider best practice when it comes to elements from a developer’s point of view? Before I knew elements I usually had put everything in the functions.php of the child theme. This changed a little bit. Take local fonts for example. I used to put the CSS rules in the stylesheet. Then I used the wp_header hook to load the fonts as early as possible. Today, I use a hook element for this. Since this is essentially the same like using the functions.php, I wonder what I should prefer. Should I use elements only for tasks that cannot be done so easily in the functions.php?
I know that this question is probably too broad. But since elements are such an important feature of GP, I dare to ask. 🙂
Customer Support
Hi there,
I’d keep all the hooks w/o any required display rule location/condition on functions.php. Filters as well.
I’d keep the use of Hook elements to a minimum w/ mostly for presentation purposes hooking like adding custom HTML structure on specific hook locations.
While you can run PHP in it, there will be limitations.
for one, you can’t pass values to the hook if you use a custom hook from the dropdown.
Another would be, you can’t mix echo do_shortcode() with dynamic variable and a plain shortcode while having “Execute Shortcode” is ticked.
While having a few Hook element won’t hurt, if you get in a habit of using the hook element like Code Snippets plugin, eventually the number of Hook elements listed will blow up and it can affect the site’s performance if you have to many running at the same time.
Thank you very much for taking the time. This sounds like a very sensible approach. Will consider this best practice in future projects.
No problem. Glad to be of any help. 😀
My customer wants to have individual page hero images for many pages. Usually, I use a header element for the standard resolution and the featured image for retina. This image is switched like so:
add_action( 'wp_head', function() { if( is_page() ) { $featured_img_url = get_the_post_thumbnail_url(get_the_ID(),'full'); if ( !empty( $featured_img_url ) ) { echo ' <style> @media (-webkit-min-device-pixel-ratio: 2), screen and (min-resolution: 192dpi), screen and (min-resolution: 2dppx), screen and (min-width: 2000px) { .page-hero { background-image: url(' . $featured_img_url . '); } } </style>'; } } });Would you recommend a CSS-only solution where I set both images invidually per page ID? I’m not sure whether the header elements will impact performance. Right now, we have 23 elements in use. Loading times are quite good. So far, I don’t see any negative effect.
While pure CSS would be lightweight, it couldn’t be edited by the customer.
Not quite sure what’s best here.
Not exactly I fully understand what you mean.
From the looks of the code, it’s dynamically fetching the featured image set on the page to be used as page hero image.
I think this is already fine for ease of use for users who want to easily change the page hero image. You simply tell them to change the page’s featured image and that should change the page hero.
As for having a CSS only solution, I don’t think this is practical because it will require to have to write something like this –
body.page-id-1234 .page-hero { background-image: url(''); }– for each page manually.It’s not exactly like that, but you got the main idea right. The function switches the standard image set in the header element (1920px width) to a retina image (3840px width). This needs probably more processing time compared to a pure CSS solution. But since I am not a fan of page specific CSS rules, I avoid them if possible.
I’ve just tested a page: without any hero image vs. a header element. Loading time and total blocking time were almost identical. I guess, there is nothing to worry about. At least, if you use a reasonable number of header elements.
I’ve just tested a page: without any hero image vs. a header element. Loading time and total blocking time were almost identical. I guess, there is nothing to worry about. At least, if you use a reasonable number of header elements.
But if you get into a hobby of doing that for each page, you’ll end up with hundreds of header elements once the site grows in static page numbers. 😀
I remember a user having this issue recently. He had a header element for every page he created and it ended up the same way I mentioned. Now he has 110+ header elements to maintain. Aside from potential slow downs, it’s simply tedious to maintain all of them. 😀
I absolutely agree with you. But you know, customer is king. 🙂 I have to walk a fine line here. On the one hand I have to deliver what the customers wants. On the other hand I want the performance to be as good as possible. Right now, we have 23 elements. That should not have significant negative effects. There is always something that customers don’t understand about “Keep it simple!”. 🙂
Customer Support
Hi there,
i am a little unclear as to why you would need 23 elements.
Are you creating an individual element for each ‘variation’ of a Header Element ?If so, whats the difference between each of those ?
I am a little unclear as to why you would need 23 elements.
Well, apart from 3 hooks, the elements set individual page hero images for pages, blog page, archive pages etc.
Header A > image for page A
Header B > image for page B
Header C > image for blog page
Header D > image for all single posts
Header E > image for all category archives …Do I miss anything?
With CSS it would look like so:
.page-id-123 .page-hero { background-image: url('image1.jpg'); }
.page-id-456 .page-hero { background-image: url('image2.jpg'); }
.page-id-789 .page-hero { background-image: url('image3.jpg'); }Why not use the Featured Image for the background image for the pages ?
You already have this in play:
https://generatepress.com/forums/topic/make-page-hero-retina-ready/#post-1826383Which sets the size of the default background image size.
And then your other snippet above, will be rewriting the CSS rules to load the Full featured image on the larger screens.
Unless there is something fundamentally different in the Page Hero HTML or its specific styling ( different padding, background styling ) or your wanting to load a completely different image for lower res screens for each page, then there shouldn’t be a reason for having separate heros…
Maybe i am missing something.
It’s probably me who is missing something. 🙂
The problem is that we use images that have several different width to height ratios. So, we can’t use the same padding for all pages. Elements work very well. I set the image and the correct padding and just switch to the featured image that has a higher resolution. No need to change padding, since the width to height ratio is the same. I could use retina-ready images only. But I consider this bad practice. To make a long story short, here a some examples:
Page with small header
https://doriskirch.de/achtsamkeitstage-achtsamkeitspraxis-vertiefen/Blog
https://doriskirch.de/achtsamkeits-blog/Single Post
https://doriskirch.de/corona-angst-achtsamkeit/Page with large header
https://doriskirch.de/achtsamkeit-online-kurs-flourishing/Page with no header at all:
https://doriskirch.de/ueber-uns/Using images with the same dimensions would make things much easier. Unfortunately, the customer wants something else.
Ooh thats fancy 🙂 And i see what you mean.
I assume you’re using image ratio % for the padding, to keep them responsive.
If thats the case then you could do something like this:add_action( 'wp_head', function() { if( is_page() ) { $featured_img_url = get_the_post_thumbnail_url(get_the_ID(),'full'); if ( !empty( $featured_img_url ) ) { $width = $featured_img_url[1]; $height = $featured_img_url[2]; $ratio = $height / $width * 100; echo ' <style> .page-hero { padding-top: ' . $ratio . '%; } @media (-webkit-min-device-pixel-ratio: 2), screen and (min-resolution: 192dpi), screen and (min-resolution: 2dppx), screen and (min-width: 2000px) { .page-hero { background-image: url(' . $featured_img_url . '); } } </style>'; } } });I assume you’re using image ratio % for the padding, to keep them responsive.
Spot-on! 🙂
Wow, YOUR solution is fancy. 🙂 A very interesting approach. But how would I use two different image sizes (standard resolution and retina)?
We could probably fix this using a specific naming scheme and something like:
featured-image.jpg
featured-image2x.jpgstr_replace(".jpg","2x.jpg","$featured_img_url");Might work, but not a very robust solution. Any mistake in the naming scheme would break it.
- You must be logged in to reply to this topic.
