Hook/filter Reference for Dynamic Content?

I’ve been looking at the new Layouts for building Wocommerce templates as an alternative to having to use a combination of hooks/filters and editing the woocommerce templates in a child theme. I seem to be running into a couple of issues where some hooks/filters are needed but the standard ones don’t seem to work.

For example, if I want to show prices with both inclusive and excluding tax, hooking a function to ‘woocommerce_after_shop_loop_item_title’ no longer seems to work. Is there a reference to the hooks/filters that have possibly replaced this?
Previously, something like the following would work (but no longer does):

add_action( 'woocommerce_after_shop_loop_item_title', 'add_tax_prices', 10 );
function add_tax_prices() {
	global $product;
	if ( !empty(wc_get_price_including_tax( $product ))) :
		echo '(<span class="show-exvat-price">' . wc_price( wc_get_price_including_tax( $product ) ) . '</span> Inc. VAT)<br />';
	endif;
}

Do you have a reference somewhere for all of this?

Hi @sguilliard,

Thanks for reaching out.
You can use the predefined action filters and hooks of the X and Pro into your Child Theme to customize a few predefined sections. If you are not proficient with the Hooks and Filters, I would suggest you hire a developer who can assist you to do this customization.
Please find the article on the Action Hooks and Filters: https://theme.co/docs/actions-filters-and-hooks

Hope it helps.
Thanks

Ok, maybe you didn’t properly read my post? I don’t need help understand what hooks/filters are nor writing functions.

With layouts in use, the example I provided previously won’t work. Switch layouts off and normal service is resumed. So my question is, are there any hooks/filters related to the dynamic content that should be used instead (using the previous example as the context)?

I know that there are more hooks and filters than those few listed on the link you sent (I’ve found more by trawling through the code) which hasn’t been updated in a long time (before the introduction of layouts or loops), and hence my question.

As it stands, I’ve abandoned the layouts I was trying and have gone back to the tried and tested method of coding it manually with the standard WooCommerce hooks and fillers that work (I haven’t got time to go trawling through the code to find if what I need is there - that’s supposed to be what up to date developer documentation is for).

Howdy, @sguilliard! Thanks for writing in and sorry for the confusion here. I’ve been reviewing this post along with @alexander internally it prompted some discussions of how to handle the various moving pieces going on here.

With regards to hooks like the one referenced in your example, the primary functionality of hooks comes from long ago in WordPress when themes and builders were much less robust than they are today. Back when theming typically meant installing a product with a “fixed” style and markup, hooks provided a much-needed way to access different parts of the markup without having to alter the core files of the theme itself. Utilizing a child theme and the appropriate hooks allowed users to inject markup or functionality where needed, much like your example.

Fast forward to today with the more modern approach of utilizing a builder and a specified library of Elements to layout pages and templates, the functionality that these hooks provided is less appropriate / necessary due to the very nature of a builder and the fact that these builders give users total control over the markup of their layouts. Pair that with the addition of new features like our Element Conditions and Dynamic Content, and there’s almost no need for these hooks as you can recreate the same logic needed in a hook from directly within the builder.

That being said, we do understand the desire for some users to implement the traditional hooks into their designs either for backwards compatibility, or just as a preference. Because of this, we are planning on implementing a new Dynamic Content specifically for referencing hooks, which you as the user will be able to place anywhere in your design. We didn’t want to get into the opinionated nature of trying to bake in all these hooks where we think they should go, because it might still not give you the exact placement you want on something. So in a future release (not this coming one that is going out soon), we plan on introducing a Dynamic Content tag that will be structured somewhat like this:

{{dc:hook:woocommerce_after_shop_loop_item_title}}

You will be able to specify any hook in the tag like that (as long as it belongs to our internal whitelist for security reasons, or you can add in anything you need from another plugin) and have it function as expected in the markup. This would likely go into one of our Raw Content Elements so that there’s no additional markup around it and functions more closely like the hooks in a traditional theme or plugin.

As mentioned above, this won’t be baked into the builders for a while as it will take a bit to build out, but we have also analyzed a few shortcomings in our various Price Dynamic Content tags, that when paired with some of our Element Conditions should get you to what you’re trying to accomplish. This following functionality will be available in the coming point release that should be going out today (or later this week at the latest).

Previous to the coming point release, our {{dc:woocommerce:product_price}}, {{dc:woocommerce:product_regular_price}}, and {{dc:woocommerce:product_sale_price}} Dynamic Content tags did not honor the global WooCommerce setting to include or exclude tax from the price output. Once this point release is available, each of these tags will honor that setting and your tax values you’ve added. If desired, this can be overwritten with the tax_inclusive flag like so:

  • {{dc:woocommerce:product_price tax_inclusive="true"}} – Will output this price with tax, regardless of what the global setting is.
  • {{dc:woocommerce:product_price tax_inclusive="false"}} – Will output this price without tax, regardless of what the global setting is.

That flag will work on any of the price tags once this point release is out. So with this, you should be able to access the values you want. Additionally, you can use our Element Conditions to output content only if an item is taxable, like so:

If you are not familiar with our Element Conditions, I highly recommend you read up on them with our documentation, as it will open up a whole new world of dynamic templating with your designs:

So for your example above, you could create a Text Element that outputs your item’s price with the tax_inclusive flag set to true to always output the taxable value, regardless of the global setting, and then add a condition on that Element so that it is only displayed if the item is taxable. I believe that should get you to what you’re wanting to achieve, all within the context of the builder. Longterm, once our hook Dynamic Content tags are in, you could leverage those instead, but we personally feel that in the context of the builder, utilizing Dynamic Content and Element Conditions is the cleaner way to go. Hopefully this helps to point you in the right direction on things…cheers!

1 Like

This looks awesome! :slight_smile: Just spotted the ‘Apply price formatting to WooCommerce Dynamic Content price fields’ in the latest changelog and then this! The DC tag fits the bill! :slight_smile:

While you’re at it, I’ve noticed something that could be improved on the custom attributes that can be added to elements: for some elements (such as sections, rows or columns) it would be useful to be able to apply attributes to the child elements such as images (such as using the <img> tag for ‘background’ image). This would then allow attriibutes such as 'srcset' to be applied, especially as Google’s mobile first indexing and the Lighthouse tool are now such a major part of SEO. The only workaround at the moment that I can see is to manually add the html for those images…

Hello @sguilliard,

Thanks for appreciation, In the image element the srcset attributes not yet implemented yet. We will keep in mind.

Thanks for understanding

Hi @sguilliard,

I wanted to reach out to provide some additional context here. We won’t be adding a way to add attributes to nested markup, so you might need to continue using HTML. I can understand that motivation here, but regretfully it would be quite a bit to manage and really isn’t in reach for us. Another alternative would be using the Div element positioned absolutely to create a faux equivalent of the background feature while having more control over the final output.

I also wanted to let you know we do have a way to enable srcset support through a stopgap implementation that we will ultimately revisit when we do our Theme Options reboot cycle and add many more global options to X and Pro.

Try adding this to a child theme

add_filter( 'cs_enable_srcset', '__return_true' );

This will enable outputting srcset attributes on images. There are two requirements:

  • It will only work if the image was added via the media library because it uses all the native WordPress functions for resolving the image dimensions and URLs.
  • The image must have the retina option turned off.

When we add official support it will most likely be through the same process of leveraging the built in WordPress functions, but we might change how it gets turned on/off and allow it to be managed at an element level.

That filter is somewhat experimental since we haven’t done much testing with it and opted to make it available for those who want to try it out. I’ve honestly not tried it with background images so I don’t know if it will be applied there or not. When we do the official implementation we’ll check all the different use cases.

Hopefully this helps in the meantime.

1 Like

Hi @alexander,

The srcset for images filter is perfect! :slight_smile:

For backgrounds, I have noticed that I can use the custom option (only just noticed it) and add background images with the <picture> tag using something like the following (which solves the problem perfectly):
<picture> <source media="(min-width:650px)" srcset="image.jpg"> <source media="(min-width:465px)" srcset="image-300x200.jpg"> <img src="image.jpg" alt="Image" style="object-fit: cover; object-position: center;"> </picture>

Thanks again for the updates… :slight_smile:

1 Like

Glad to hear that @sguilliard :slight_smile:

Hey @christian and @alexander, i am using PRO 4 and was trying to use the Unsplash official plugin.

Although i enabled the filter in functions.php for the child theme, Unsplash’s plugin still does not work with SRCSET, even though “normal” wordpress images are now working with the attribute. (thanks for this optional feature by the way!)

Here’s the plugin comment section where the developer talk about it:

Just a heads up, so maybe you can work with them on this Killer feature.

PS: If you are curious, here’s a link for the page where i am using Unsplash images with the image element (bottom page):

Hi @dmconsulting,

I’ve used these kind of plugins before too. The only one that seems to not screw everything up (you’re still better off doing it manually and generating .webp images yourself, although be aware that Safari on anything but Big Sur won’t show .webp images so you’ll need .jpg or .png fallback images) is WPMU Dev’s Web Smush Pro, and that needs judicial use (manual is still best)

@dmconsulting, the way that filter works is it tells Pro elements to start using the WordPress wp_calculate_image_srcset and wp_calculate_image_sizes functions to add additional attributes to the <img> tags. Based on the developers comment it sounds it should work considering they integrate with the media library which is where Pro pulls images from. Hopefully they can take a closer look and help figure out what’s happening.

@sguilliard thanks for chiming in to share your experience on the topic!

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.