Update: Doesn’t work for all location settings.
Eg. If Page = About, then custom fields group shows only for primary language.
If Post_Type = Post then shows for both languages..
Not sure :/
Update w/Solution to my query: Disable the Make ‘Field Groups’ translatable option. Use Duplicate to create a new language.
I also installed the ACF plugin @thomask recommended.
Hi @thomask No – I’m not. Just looking into it. Will it solve my above configuration?
Cheers
Currently I have to create a translation for each field group.
So if I have 4 languages and 3 field groups I have to manage 12 separate field groups.
Is there a way to have global field groups. By that I mean 1 field group working across all languages. It doesn’t matter that the field labels will all be in a primary language.
This would save us a lot of administration. In this thread there are also others reporting about a very manual and error prone update process when adding/modifying/removing fields and this global field group option would resolve that pain point.
Is it possible for some feedback about whether this is currently possible and if not if it could be considered for future release.
Thanks
Just to chime in – increasing memory limit will solve to a degree, but we had an enormous site and even if we maxed out the memory limit we still had issues.
A better solution would be to limit the lookup so the server does not max out. Hopefully Elliot and the ACF team will consider adding some functionality to address this
Thanks
This fixed it for me too.
Hi Everyone – I had this issue on the edit page and it only recently occurred. I realise this occurred just after I imported 100’s of post-types into WordPress and I had a field that was looking up the available pages for links. In fact I had this on a repeater.
Elliot – Any ideas if this can be ajax-ified so these pages are fetched when required we don’t run into these memory issues? Or perhaps another way to index links so this doesn’t cause an issue?
Everyone else – Either change the look up to be a text field and enter this manually or a bad compromise is to increase the memory limit: http://stackoverflow.com/questions/21680244/fatal-error-allowed-memory-size-of-268435456-bytes-exhausted-tried-to-allocate
Hope that helps
Update with code on Stack Overflow: http://stackoverflow.com/questions/24127714/wordpress-url-and-wp-get-attachment-image-src-http-vs-https/24551425#24551425
I’m not convinced this is the best approach and suspect I am missing some core functionality somewhere.
With WP Engine and a similar issue.
We have the following code
<?php $image = wp_get_attachment_image_src(get_field('home_hero_image'), 'home-slide'); ?>
<div class="home-top" style="background-image:url('<?php echo $image[0]; ?>');">
This image source always outputs HTTP. So when we access page with HTTPS it warns us this is unsecure content. I’ll see if I can add another way, but I thought using $image[0] was best practice.
Elliot
