[Resolved] Can’t assign translated child page to different translated parent page
This thread is resolved. Here is a description of the problem and solution.
Problem:
With Types 2 relationships it was possible to assign translations of child posts to different parent posts (that were not translations of each other), but this no longer seems possible with Types 3.
Solution:
With Types 2 relationships it was necessary to manually assign translations of child posts to parent posts.
In Types 3 this is handled automatically, but it means that it is no longer possible to separate which child post translations are assigned to which parent post translations.
This will be reviewed.
This support ticket is created 6 years, 4 months ago. There's a good chance that you are reading advice that it now obsolete.
This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.
Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.
This is a WPML and Toolset issue, but I don't know if it should be posted here or WPML. This problem occurred after migrating post relationships to Toolset 3.
We have Newsletters (parent) and Articles (child) in a one to many relationship. Many Articles can be assigned to 1 Newsletter.
Before the migration, when we translated an Article, it needed to be assigned to a different Newsletter that did not have a default language copy.
However, after the migration, we're unable to assign a translated Article to a different Newsletter. The Article stays assigned to the default language Newsletter, but this doesn't make sense for our site.
For example:
English:
Newsletter: January 2018
Articles:
Article A
Article B
Article C
Newsletter: February 2018
Articles:
Article D
Article E
Spanish:
Newsletter: March 2018 (No corresponding English version.)
Article A (translated into Spanish from the English Newsletter: January 2018)
Article E (translated into Spanish from the English Newsletter: February 2018)
How do we assign the translated Articles to a new "translated" Newsletter that does not have a corresponding version in the default language?
I tested this locally to double-check what to expect, and I found that you are right, you can't do what you are aiming to do.
My first instinct was to escalate this, but giving it some thought I don't think there really is an issue here.
You have an English newsletter which contains certain articles.
You have a Spanish version of the newsletter, but because of the time lag in translating articles, this newsletter contains different articles than the English one.
Meaning it is not really the same thing.
If The Times had a Spanish version whose articles were a week old, then today's edition of the English Times and today's edition of the Spanish Times would have little in common other than today's date, they are not translations of each other.
So, you should create separate post types for an English Newsletter and a Spanish Newsletter, and link English versions of Articles to the English Newsletter posts, and Spanish translations of Articles to Spanish Newsletter posts.
The English Newsletter posts and Spanish Newsletter posts are not translations of each other, because they are logically different.
This is really unfortunate as we built the entire website, all 2,600+ newsletters and articles translated in 8 languages using the previously mentioned setup with Toolset. Articles that are translated are assigned to different translated newsletters because other countries select different articles from various previous newsletters. Toolset previously allowed us to still show the translations of specific articles even if they weren't all attached to the same newsletter. The Toolset 3.0 completely destroys the site's entire translation relationships without recourse it seems.
We're at a bit of a loss of what to do here.
If we did as you suggested, then English articles would not show the language switcher for users to see the translation. Are there really no other options?
What should we do now that we can't update the plugins?
It is still the case that this doesn't really make sense to me because the Spanish newsletter is not really a translation of the English newsletter, it is a different newsletter, but...
if you have already set it up this way successfully on a Types 2 site and it doesn't work when updating to Types 3, well, we'll need to take another look at it.
I'm going to set up a new test site with Types 2 to see if I can get it working, but it may be that I need a copy of your site where you had it working (it sounds big, so I'll try on a simple test site first).
But let me mark your next reply as private so that I can get site credentials in case I need to take a copy.
Thanks for that. I looked at the links you shared, and I set up something locally to confirm how the change from Types 2 to Types 3 affects this.
I'm consulting with the developers and will get back to you, but in the meantime I would point out that this happens if you run the migration wizard to migrate the relationships.
If you just want the site to function as before you can update to Types 3 and not run the wizard, and it will continue to function as per Types 2. You would only need to migrate the relationships if you wanted to develop this further and take advantage of new relationship features.
Anyway, when I hear back from the devs I'll update you again.
I spoke with the developers about this, and it would be difficult to update Types 3 with WPML so that it behaved similarly to Types 2.
In Types 2 adding translations of child posts to translated parent posts was something that had to be done manually. Types 3 now handles this automatically, and it is done in such a way that means it is not possible to assign translations of child posts to different parent posts.
As I mentioned in my last update you can use Types 3 and *not* migrate the relationships, in which case they will continue to work as before.
If you were setting this up from scratch now you would have to create separate CPTs for the different language versions of the newsletters.
Hopefully you are okay to continue using the site how you currently have it, updating to Types 3 but not migrating the relationships.
Thanks for researching the issue, and for all your help and feedback.
We might try updating without migrating the relationships... as long as we will not be forced to use the new relationships structure, and still have access to the cpt settings.
To clarify your original idea, in Toolset 3 could a Spanish translation of an article be a child of a different custom post type than it's english default ? Also, would the Spanish Newsletter custom post types need a copy in the default language?
"So, you should create separate post types for an English Newsletter and a Spanish Newsletter, and link English versions of Articles to the English Newsletter posts, and Spanish translations of Articles to Spanish Newsletter posts."
CPT 1:
Newwletter English
CPT 2:
- Article A - English
CPT 3:
Newsletter Spanish (with no English version?)
CPT 2:
- Article A - Spanish Translation
Now that I come to try and actually implement this on a test site I'm running into issues that make it not practicable.
You *must* create content in the default language if you are going to set up post relationships, and so if you made a second CPT for Spanish newsletters (e.g. "Boletines") you would have to make them translatable, create them in English, and then translate them to Spanish, and the connections would be based upon the English versions, and if you viewed a Spanish Boletín on the front-end you would be able to use the language switcher to switch to the English version which you artificially created just to be able to set up the Spanish content, rather than switching to the actual English newsletter.
So, it seems like there is no alternative to persisting with the set-up you created in Types 2, upgrading to Types 3 (for other features/bug-fixes etc.) and not running the migration wizard.
We have a weekly meeting Thursdays to discuss broader issues, and I'll raise this to see if we might be able to make some changes down the line that would facilitate something similar with Types 3 relationships.
But you are safe to continue using non-migrated relationships in Types 3.
