Fixed Customized style templates marked as belonging to default add-on after importing from designer output

[Jake B.]

Affected version

2.0.0 DP 10

Steps to reproduce:

1. Set $config['development']['defaultAddOn'] to a valid add-on that is installed and active
2. Run xf xf-designer:enable X Y for a style with customized templates

And you'll see something like this:

 

[Mike]

This is fixed now. There are actually 2 parts to the fix:

1. We now track the addon_id of the template in the designer output (next time it's written). When that's present, that should fix the issue.
2. If it's not present when we import, we look at the parent version of the template and inherit its addon_id.

When a master template is inserted (or addon_id changed), we also adjust the addon_id of any templates with that name. That should help with the case where an add-on gets installed later.

Unfortunately, this won't be an automatic to resolve thing after you upgrade to a fixed version. I believe the best way to resolve it after upgrading would be to import from the designer output which should pick up the parent template addon_id and then export to push the addon_id back to the metadata. If you edit after we start tracking the addon_id, that may push the wrong addon_id into the designer output (which would make outdated templates not detectable at least).