This appears to have been resolved in a subsequent update, as both render_callback
and render_template
work on the acf/init
hook using WordPress 5.5 and ACF Pro 5.9.
I’m encountering the same issue since updating the plugin, although the form never appears. (The JavaScript error always appears in the console.)
I have a possibly related issue: if I use acf_register_block_type
on the acf/init
hook, the block doesn’t render in the frontend. If I use the init
hook, it works. This appears to be a new problem, as my code was working fine in December.
I have a possibly related issue: if I use acf_register_block_type
on the acf/init
hook, the block doesn’t render in the frontend. If I use the init
hook, it works. This appears to be a new problem, as my code was working fine in December.
It’s been a while! But a tip: if the dates have been saved by a date_picker
field and not a date_time_picker
field in Ymd format (for example 20200916), you’ll need to convert the values in the database to a machine-legible date string (Y-m-d) before integrating this solution. Otherwise, the dates will all be displayed as 1970 dates, and potentially saved with incorrect values when re-edited.
There’s some code here which looks as if it could contain stuff you could use.
@nenosw I would expect so. Have you tried the code to see what happens?
I thought that too, but after reports from a client, it might also be connected with the Gutenberg plugin at version 6.3.0 or 6.4.0. I’ve registered an issue here too, in case that’s the problem. https://github.com/WordPress/gutenberg/issues/17395
Yes, I know. But if it’s a custom theme, the strings in your screenshot are probably not coming from ACF, but are fixed in the PHP code. I’ll need to see this code if you need me to help you further, thanks.
I see what you’re trying to achieve. It’s likely that these strings aren’t coming from ACF at all, but are fixed in the code. Is the code online anywhere, e.g. in Github?
A note; the solution here is for translating the ACF input field labels. Not the content. That’s an important difference. If you’re trying to translate the content, then you don’t need anything except the regular Polylang or WPML Plugin functionality. If the strings on the website are fixed in the code and untranslatable, then that’s a different issue. I’d be happy to help directly if you need consultancy in that area.
Both WPML and Polylang work fine with ACF. I’m confused about what you’re trying to achieve. Can you send me a screenshot of the strings as they appear in the front end of the website, which you’re trying to translate?
Advanced Custom Fields are usually only output in the backend. If they are output in the front end in your project, I’d recommend contacting the developer who made the site and clarifying that with him/her.
Yes, but how are you outputting the ACF fields in the front end?
@riba86 Are you using the acf_form
function?
This still appears to be a problem. If I add the call to acf_form_head
using the wp_head
hook, the main error message _Validation failed. 1 field requires attention_ still appears in English. I found that my moving it to the wp
action, which is called before wp_head
, the problem is solved.
Same here – the meta box name given by @elementh (Stronky) works, the one prefixed with tagsdiv-
doesn’t. (WP 5.1.1 and ACF 5.8 RC.)
The documentation still indicates that the function has been available since 5.0.0 – that is confusing and should be amended.
A further suggestion of using existing tech, then: perhaps look into using either a custom taxonomy or a “Feature” CPT, then you can pull that in to each Provider/Product using a Relation field. That way, the editor can add whichever features they need, then apply them to the main CPT freely. This would work in the same way as categories and tags on regular posts.
That sounds like a very complicated way to build a simple table. I still think that you’ll be better off creating (what look like) Providers as individual entries, then assigning each one attributes, which you can then output on the front end in an infinitely flexible number of layouts. Binding the data to a single layout means that you’re stuck if you want to use the same data in a different layout. If the “learn more” link leads to a detail view of that provider, then you’d have to create the data all over again for that view, if you don’t use the Post-based solution.
When you change the return type, you may need to save the Post/Page again. Have you tried passing the Post/Page ID to the get_field
function as the second parameter?
Also: your two examples aren’t referencing the same field category_insect_family. Is the field called category_insect_family
or insect_family
? Make sure you use the correct field key.
Welcome to the Advanced Custom Fields community forum.
Browse through ideas, snippets of code, questions and answers between fellow ACF users
Helping others is a great way to earn karma, gain badges and help ACF development!
We use cookies to offer you a better browsing experience, analyze site traffic and personalize content. Read about how we use cookies and how you can control them in our Privacy Policy. If you continue to use this site, you consent to our use of cookies.