Enable taxonomy term translations #17
Conversation
Adds the `TermTranslation` type during type registration to provide term translation fields since these fields are slightly different than those for posts.
Adds fields to Taxonomies types, visible on the terms, in the same way these fields are added to posts. Adds the following fields: * `locale` - the locale of the current term * `translations` - list of `TermTranslation` objects * `translated` - list of the translated `Term` objects
Adds a hook to remove the WPML `get_term_adjust_id` filter that is attached to the WP `get_term` function at a very high priority. This filter causes WPML to adjust term ids for every request - shifting request terms to the "current language". The problem is that the WPGraphQL requests don't typically use the current language (and especially not for use cases like Gatsby). This results in term IDs only ever being returned for the default language and with single term queries always returning the default language's term. The function is added to the `init_graphql_request` action that runs at the beginning of the GraphQL request cycle. Using this action ensures that we're making adjustments for only "graphql" requests and that those changes are early enough in the cycle to get in front of the WPML filters.
Adds a hook to set the `$icl_adjust_id_url_filter_off` global to `true`. This global is used in the `WPML_Term_Adjust_Id->filter()` to indicate if term ids should be adjusted. Setting this global protects against another hook or filter turning this feature back on. The function is added to the `init_graphql_request` action that runs at the beginning of the GraphQL request cycle. Using this action ensures that we're making adjustments for only "graphql" requests and that those changes are early enough in the cycle to get in front of the WPML filters. Setting this to `true` is another guard against WPML id adjustment that results in only ever seeing the terms for the default language.
Adds the `slug` field to the term translations response (type and
resolver) to help when a term may have the same slug between different
locales. When the same slug is used, WordPress will add a numerical
suffix to the href/link even though the same slug may be desired.
Adding the slug to the response allows the client to use the slug when
generating routes. For example, imagine the situation with two locales:
English and Spanish. Creating a `tech` tag in both locales would look
like this:
* English
- slug: `tech`
- href: `https://.../tag/tech`
* Spanish
- slug: `tech`
- href: `https://.../es/tag/tech-2`
With the slug and the href, the client can use whatever works best in
that context.
| * run. There is a WPML setting named `auto_adjust_ids` that will turn | ||
| * off this feature, but it should never be on for GraphQL queries. | ||
| */ | ||
| function wpgraphqlwpml__remove_term_adjust_id_filter() { |
There was a problem hiding this comment.
I need to double check this, I am currently working on filtering menus and menu items and had a case where I actually need to get the adjusted ids.
There was a problem hiding this comment.
@rburgst no problem! We could probably set it conditionally if needed. We were lucky enough to not need any menu data for our project but the adjusted ids caused some serious havoc with Gatsby pulling translated terms.
There was a problem hiding this comment.
In fact, we could use this or the constant below and set them around the resolver functions if that would work better for you.
| * should be adjusted. Setting this global to `true` ensures that | ||
| * term ids are not adjusted during GraphQL queries. | ||
| */ | ||
| function wpgraphqlwpml__set_global_adjust_id_filter_off() { |
There was a problem hiding this comment.
I am confused here, doesnt do this the same as line 773?
|
Thanks a lot for your contribution, however, one of my queries produces worse results with your patch than before, could you please check why this is the case? previously returned after your change, the locations for the non-default language menu elements seems to be gone I am pretty certain this is due to the fact that now all |
|
@rburgst We don't use menus anywhere so I'll need to take a look at that. Thank you for the thorough response. |
|
Is there any progress on this? |
Overview
Enables support for taxonomy term translations that return the correct translated IDs and objects for terms in non-default locales.
Details
Adds fields to Taxonomy types to be visible on the terms:
locale- the locale of the current termtranslations- list ofTermTranslationobjectstranslated- list of the translatedTermobjectsAdds two hooks to resolve the issues with WPML term ID adjustment. Basically, WPML adjusts term ids for every request, shifting request terms to the "current language". The WPGraphQL requests don't typically use a current language and that's especially the case with Gatsby. We want to retrieve all of the terms at once and let Gatsby handle the language switching. These two hooks ensure that term IDs are untouched during GraphQL requests allowing retrieval of non-default locale terms.
Adds a
slugfield to the term translation response to help in the situation where the same slug is used for terms in different locales. The example in the commit message shows what it would look like for thetechtag in two locales:English
techhttps://.../tag/techSpanish
techhttps://.../es/tag/tech-2Having the
slugallows the client to do what it needs - in our case, it was building out tag pages with the correct tag in the route.I've also included all of this context and more in the commit messages.