Let's say that I have a fields group that's assigned to a specific content template (I've selected a content template, or a set of content templates in the "Where to include this Field
Group" section).
This works fine, but it fails during export/import process.
Let's consider the following scenario:
1. Export Types (site A)
2. Export Views (site A)
3. Import Types (site B)
4. Import Views (site B)
This will not work with content templates assignment because on the 3rd step when Types fields are imported on the site B, Views content templates don't exist yet. So, Types content template assignments are not imported.
So, let's consider the following scenario:
1. Export Types (site A)
2. Export Views (site A)
3. Import Views (site B)
4. Import Types (site B)
This should work fine because Views are imported before Types. So when Types are imported then Views (and content templates) already exist and Types content template assignment should be imported properly.
But for some reason, it doesn't work either. Content templates assignment is blank after import, no matter in what order the XML files are imported.
IMO the fact that Toolset has 3 separate exporters/importers (for CRED, Types and Views) is the key problem. There should be one combined exporter that would do the whole job.
The second problem is that if something can't be imported there's no warning, no message is displayed so the user isn't aware that something went wrong in the case of a failure.
Indeed it fails.
I reported this as a BUG, and thank you for the report.
I will keep you updated here.
I've found an another issue. I'm not sure is it related, maybe it's just a coincidence. Sometimes content template assignment is not even saved. Sometimes, when a content template is selected in the "Where to include this Field Group" section, then after the page is saved the assignment is not saved - a checkbox returns to unselected state after page reload.
But it happens only with some of my content template. I can't find any rule.
That requires a new Ticket.
This is in order for you to get the fastest possible assistance.
Thank you
I tested this with the Release candidate for Types and it works all great there.
This will be released very soon, but I cannot say yet exactly when (it's a matter of days)
I will keep you posted.
> I tested this with the Release candidate for Types and it works all great there.
Great. Thanks.
> That requires a new Ticket. (...)
I'm not so sure because these 2 things seem to be related. I'll wait for the new Types release and I'll create a ticket if there's still an issue.
Thanks.
This should be fixed now, in the current release.
Thank you for your patience.
Thanks. I'll check it out and mark the issue as solved.
I've updated the Types plugin to 2.2.11 (other Toolset plugins are also up to date) and I can't confirm it's fixed. Content templates assignment is still lost during export/import.
You are right, I missed one crucial step in my last test on the stable release.
This is not fixed.
It's becuase the new Content Template has a new ID.
And that Setting in the Toolset Types most certainly works on the ID.
I am re-escalating this for again to be reviewed.
I am sorry the trouble.
So, I definitely made a wrong test when I tested that with the release versions.
The Settings uses the ID of the Content Template, and that ID will change when you import a Content Template.
As such, those settings will never match and never work on an import.
It could be possible to use the Slug, but you can imagine this is also risky, given that the ID is unique, the slug might not be.
I sent this forward as a new feature to be looked at. It is not a BUG, per se.
I will update you as soon as possible here.
I understand why it happens, but from a user perspective, it is a bug. If the exported data differs from the imported data it can definitely be called a bug - no matter what is the under-the-hood-reason.
The main problem here is that there are 3 different importers/exporters and they work separately, and they "don't know" of each other. If there was a one, combined exporter then everything could be exported flawlessly, because the relationship between content templates could be stored in the export file.
I fully understand, and agree.
I can tell you, the Developer actually told me the same, after analyising my report.
So now, this issue has a status of BUG and will be solved as such.
I will put this ticket in a specific state:
"Escalated to second tier".
Even thou I function as second tier, I have to do that so I can update you once the bugfix is released.
Thank you so much for the report (I am not sure this would have been found otherwise, and it will allow to fix a few related things as well) and for your patience as well.
I hope I can bring good news very soon.
One more note. I know that implementing one unified importer would solve the problem, but I also know it is not very likely to happen soon ????
So, as a workaround you could implement some kind of unique ID. A unique ID (for example in a UUID format) could be an identifier of a content template. This ID would be stored as a hidden custom field (assigned to a content template and of course exported in the XML file)
But this solution would require a change in both: Views and Types plugins. The downside of this solution is that it would work only if Views were imported before Types.
In fact, it could work if Types were imported before Views. But in that case, Views importer would have to fix types/views relationship during import.... so again, a combined importer seems to be the best long-term solution.
I have posted a separated feature request: https://toolset.com/forums/topic/combined-exporter/
