Fixed Creating template in non master style with default_addon variable in debug mode

[Despair]

When creating a template in a non master style, if you have debug mode enabled and have the $config['development']['default_addon'] variable set to an addon, the template will be incorrectly assigned to the default addon.

In the helper_addon_unit admin template if the $addonOptions is empty it'll place the hidden input with the $addOnSelected variable. In the _getTemplateAddEditResponse there is this code:

'addOnSelected' => (isset($template['addon_id']) ? $template['addon_id'] : $addOnModel->getDefaultAddOnId()),

Which needs to check for whether it's a master style or not. I took a look at other areas and the style property controller response does a check for that:

'addOnSelected' => (isset($definition['addon_id'])
? $definition['addon_id']
: ($definition['definition_style_id'] <= 0 ? $addOnModel->getDefaultAddOnId() : '')
),

So I guess the same thing needs to be done for the template response... I noticed this issue when using the TMS addon, which uses the same code, I guess they will need to update it too...

 

[Jeremy]

When creating a template in a non master style, if you have debug mode enabled and have the $config['development']['default_addon'] variable set to an addon, the template will be incorrectly assigned to the default addon.

In the helper_addon_unit admin template if the $addonOptions is empty it'll place the hidden input with the $addOnSelected variable. In the _getTemplateAddEditResponse there is this code:

'addOnSelected' => (isset($template['addon_id']) ? $template['addon_id'] : $addOnModel->getDefaultAddOnId()),

Which needs to check for whether it's a master style or not. I took a look at other areas and the style property controller response does a check for that:

'addOnSelected' => (isset($definition['addon_id'])
? $definition['addon_id']
: ($definition['definition_style_id'] <= 0 ? $addOnModel->getDefaultAddOnId() : '')
),

So I guess the same thing needs to be done for the template response... I noticed this issue when using the TMS addon, which uses the same code, I guess they will need to update it too...

I believe that this is intentional on how development should occur. The Master X is the epitome of what is in the system and is what is used to export things. Any custom templates for an add-on should be inserted into the master style and master language.

 

[Despair]

I believe that this is intentional on how development should occur. The Master X is the epitome of what is in the system and is what is used to export things. Any custom templates for an add-on should be inserted into the master style and master language.

Hmm, I think we're talking about different things, or maybe you misunderstood.

The template I'm creating is not for an addon rather for a style. (Of course for an addon the template would be of the master style). When you create a template on a style you cannot choose an addon and instead the helper_addon_unit will include a hidden input set to a empty string instead of a select option. However because I have the default_addon variable set it's setting the hidden input to my default addon. Instead it should be checking that the template I'm creating is the master style, otherwise it should be the empty string. Like I said above, this is already done in the style property controller response.

I changed it to the below so it doesn't have the issue.

'addOnSelected' => (isset($template['addon_id'])
    ? $template['addon_id']
    : ($template['style_id'] == 0 ? $addOnModel->getDefaultAddOnId() : '')
),

 

[Jeremy]

Oh, yeah, I misunderstood! I thought you were talking about developing add-ons and not adding into the master style. I'll go hide in a corner, because this should be the case, but then again, it does do what it should, so it might be as designed.

 

[Despair]

Oh, yeah, I misunderstood! I thought you were talking about developing add-ons and not adding into the master style. I'll go hide in a corner, because this should be the case, but then again, it does do what it should, so it might be as designed.

At first I also wasn't sure if it was as designed or not, but the style properties does do this check, so I assume it was just left out for the template. It can cause some minor issues. For instance it's possible for the template list to show a template assigned to an addon that might not even exist. In the case of TMS (which used the same code to grab the selected addon) it's a bit worse, as it groups the modification into the wrong categories. And if the addon doesn't actually exist then the modification will simply be disabled and not even work. Not sure when TMS will be updated either so I just used the same code in the addEditResponse.

 

[Mike]

Fixed for 1.1.5, thanks.