Custom ACF field in Taxonomy Terms block within a Query block not displaying on front end


We are using a Taxonomy Terms block to display an ACF custom field for a Taxonomy within a Query block (a price suffix for the duration of a subscription term).

Screenshot 2023-04-17 at 12.04.31

This displays perfectly in the editor
Screenshot 2023-04-17 at 12.11.14

But on the front-end nothing displays:
Screenshot 2023-04-17 at 12.13.20

If we specify a fallback it is used.

Displaying standard taxonomy fields such as description works perfectly:
Screenshot 2023-04-17 at 12.05.04

The Taxonomy Terms config is standard:
Screenshot 2023-04-17 at 12.05.46

Step-by-step reproduction instructions:

Please write the steps needed to reproduce the bug.

  1. Open the Post Editor
  2. Add a Query block with front-end rendering switched on
  3. Add a Taxonomy Terms block within the Query block that displays a custom field from a Custom Taxonomy

Environment info

  • WordPress version: 6.2
  • Gutenberg Plugin version: -
  • Cwicly Plugin version:
  • Cwicly Theme version: 1.0.3

@Araminta, thank you for your communication and work with all the recently reported bugs.

This is the final issue that prevents us from releasing this particular site and so this is our priority to solve.

Please let me know if you need any more information to be able to replicate this.

1 Like

I updated the steps to reproduce to include front-end rendering - we haven’t tried without, but thought you should know.

1 Like

Hi @Araminta,

I am just checking on this as I notice it has not been marked confirmed.

Let me know if you need any more information to replicate it as this is really holding us up at the moment.


Hi @StrangeTech,

Terribly sorry for not keeping you updated on this!

I can confirm I have been able to reproduce this and that it is a bug.
We’ll be sure to have this fixed as soon as possible.

Apologies for the inconvenience.

In the meantime, as this seems urgent, could you possibly achieve this with a visibility condition?


Believe me, I want to! We’d much rather use one of the many other ways that Cwicly allows, unfortunately we seem to be blocked at every turn on this one. Please see here for a full outline of what we have tried:

And as mentioned - this related one:

If you think that these are bugs rather than feature requests, we’ll be happy to change them and see them fixed also.

Thanks again for your help.

1 Like

Both these feature requests are valid and will definitely be addressed in due course.

However, does your price suffix necessarily need to be implemented with a custom taxonomy?

Without a clear understanding of your current setup, it’s difficult for me to determine the best approach.
Perhaps if you could provide additional details, we might hopefully be able to find a workaround.

Thank you for your patience.


For now, as long as the price suffix changes when we change filters and is easily and clearly editable by our client, we will take any workaround you can provide.

The monthly / yearly toggle is currently a custom taxonomy because that seemed to be the cleanest and most logical approach.

Having a custom field on that made sense because it should change when the taxonomy term changed.

If you have a better way of doing this, we are more than willing to try it.

1 Like

Given the fact that we have multiple filters (e.g. subscription duration and currency), using a standard post category as a taxonomy didn’t occur to us - I suppose we could switch the subscription duration custom taxonomy for a standard post category and then use the Post Category visibility filter for it to display the price suffix. This is not ideal for a number of reasons but as long as Post Category visibility filters work with front-end rendering, then it should technically be viable.

@Araminta, can you confirm whether this is a reasonable workaround or if you have any other better suggestions.

1 Like

Thank you for the clarification, @StrangeTech!

Perhaps it might be easier for you to add a filter to your Query, using the shortcode whitelist.
This way all the logic is done in PHP so you can directly access exactly what you need (your custom taxonomy).

If you need any help setting this up, I’ll let @Louis know! :slight_smile:

However, if you feel more comfortable with using a standard post category as a taxonomy, then that might be the best solution.

Please don’t hesitate to let me know if you have any questions on this.

Thank you for the suggestions @Araminta

Our priority is the client editing experience and we are happy to use whatever method yields the optimal result for them.

I can see how the shortcode whitelist can work in this case, in the sense that we can access whatever fields we want via code.

The only downsides to this being the development time required and that we have been aiming to keep custom code as light as possible for ease of maintenance.

Can you please confirm whether as far as Cwicly is concerned, the post category visibility conditions currently work with front-end editing and if so, we may use this as a fast workaround.

If neither this nor any of the three other options will be available within the next week or so, then we will probably take the shortcode route.

Thanks again!

Thank you for considering my suggestion, @StrangeTech

Apologies for not focusing on the client aspect earlier.

To answer your question, I can confirm that on my end, post category visibility conditions work as expected with frontend rendering.
However, if you experience any issues with this, please do not hesitate to reach out to us, and we will fix it as soon as possible.

If you decide to use the shortcode route, be sure to let us know if you need help!

1 Like

Hi @Louis & @Araminta, you may already be fully aware, but just to give a quick update, from our testing this still doesn’t appear to be working yet, with