Working with WPML and ACF

Working with WPML and ACF

/* NB: I started this post on the same day that ACF v5 was released. This shouldn’t change much of what I’ve shared below, but know that I have not yet tested this new release. */

I’ve been working with WordPress Multilingual (WPML) for a while now, but I just discovered Advanced Custom Fields (ACF) this year, and man do I love it! But until my most recent project, I wasn’t using them together. It didn’t even occur to me that it might be problematic…until it was.

Is ACF compatible with WPML?

The short answer is: yes, mostly (or no, not really if you’re a glass-half-empty kind of person, which I am not :)). However, if you’re looking for a plugin that gives you a nice interface for adding metaboxes to WordPress posts and pages and is fully compatible with WPML, then you probably want to go with Types, which is made by the same company that does WPML. I’ve used Types before and it works well. It’s free, and integrates into your theme much the way ACF does. I starting using ACF recently for a few simple reasons:

  1. I had been hearing about it a lot and wanted to give it a go,
  2. I was drawn to the Gallery Add-on (now integrated into the 5.0 Pro version), which is an important feature in two projects I’ve worked on this year,
  3. I really like the interface, finding it more esthetically pleasing than that of Types (though to be fair, I haven’t upgraded Types in almost a year so don’t know what kind of changes they’ve implemented since – on my to do list!).

Glass half full

When we think about translating a website, we are mostly concerned with content being available to write and read in multiple languages. And for that, ACF adapts to the WPML environment just fine. You can create groups of fields and assign them to posts, pages and custom post types, and they will automatically be available for both languages. No extra work is required when integrating the custom field content to display in a theme, because ACF simply references the field’s name, which remains the same regardless of language, it only cares about the content and stores it for each individual post ID. WPML does the job of knowing what language we’re viewing.

wpml language translate separatelyYou can even use the WPML feature to duplicate content, including images, from one translation to another, which can be really handy. However, I did run into to trouble with this when using the ACF Gallery feature, and ended up needing to add those images independently to my translations. But of course with WPML Media installed, I’m still referencing existing attachments, not adding new physical copies.

Where things get tricky: Conditionals

The difficulty arises, however, when you want to assign a group of custom fields to a specific page (or post or taxonomy), which is a great feature in ACF. Unfortunately it doesn’t know how to communicate with WPML in this way. So, for example, I have a page “About” for which I want to add an custom field “Google Map”, but I don’t want this field to show on any of my other pages because I’ll find that distracting while I’m editing them. You’ll notice that there’s no language column when viewing your ACF groups, and even though you can toggle languages via your admin bar, this won’t create the behavior you’re expecting. I know because I tried, and banged my head against the wall quite a bit in the process. Because it looks like it should work, like it really really wants to work, but it just doesn’t. In my tests, I got one of two types of behavior when trying to toggle between languages to create conditional scenarios for my field groups.

  1. After switching languages and clicking on the field group to modify, I was brought back to the original language, all page names showing in that language.
  2. I was able to switch languages and even create a conditional scenario in both, but they wouldn’t save correctly. When ever I would save one language, I’d go back to the other to discover the page was defined as something else. I’d then edit that group, toggle back and the one I’d previously done would no longer be saved to the correct page. Like ping pong. It was maddening.

I’ve also experimented with taxonomies, but it amounts to the same thing: you cannot specify targets based on the names of things. Field groups cannot be translated. But my glass is still half full! Because all this comes down to then, is needing to create conditional scenarios based on things that posts between languages can share. Like templates. A page template is a fast and easy way to create a target for field groups. WPML will automatically define the template for each additional language to save you time, and the template name is a constant so ACF won’t have to sort it out. Perfect!

What about taxonomies?

Sometimes there are cases where you’d really like a field group to display (or be hidden) only when a taxonomy is chosen. This too is a really cool feature, but again, ACF looks to the name of the taxonomy value, which likely won’t be the same from language to language. An alternative could be to create a specific taxonomy and/or value that would be given the same name for every language. In that way, the name remains a constant and the conditional scenario can be applied regardless of language. Worth testing!

Sometimes it’s also worth asking, is this really necessary? For me, working with WordPress and its world of plugins usually means compromise. And for me, that’s not a bad thing, it just is. I accept it. Instead of worrying about what the client might think of this extra field set that she doesn’t need to use for every case, I think about how I will write up the documentation for her to easily understand why it’s there and when to use it.

Things aren’t always perfect, but we can generally get them to a place where they are acceptable, and moreover, satisfactory. That works for me.

One last thing: hardcoded post IDs

Oh yeah, so how about if you need to reference a field through your theme, but on a different page? It’s also a really handy thing with ACF to be able to reuse field content in different places throughout the site. No need to enter the content more than once. Well, WPML is already set up to handle this with it’s icl_object_id() function.

[pastacode lang=”php” message=”” highlight=”” provider=”manual”]

$pageID = icl_object_id(425, 'page', false);
the_field('custom_text', $pageID);

[/pastacode]

In this example, I have a field called custom_text and want to display the corresponding content from my post with the ID 425 (which is in the site’s default language) on some other page or template. Using the icl_object_id() function tells WPML then to look for that page’s translation, and the relative content for that post including custom fields. Easy.

Have other cools solutions for working with WPML and ACF? Let me know in the comments below!