Design issue Overwriting With An Independently Exported Theme

[brstrm]

Hi all.

At @Audentio we've recently started exporting our products as independent themes. All of these products are initially built as children of UI.X.

I am finding that when overwriting a product XML that was previously exported and installed as a child theme of UI.X with a product XML that has been exported as an independent theme, none of the custom style properties created in the parent theme (UI.X) are editable in the product's style property menu via the Admin CP.

For example, having upgraded Quark 1.3.2.0 (non-independent theme) to Quark 1.3.4.0 (independent theme) using the overwrite import option, I am no longer able to change the search position (custom style property) because none of the custom style property groups created in UI.X show up in the Admin CP. After upgrading, the theme doesn't appear broken, nor are any invalid style properties flagged. So I'm led to believe that the style properties are available to the theme, just unable to be edited via the Admin CP.

Is this behavior to be expected?

Thanks in advance!

 

[Mike]

Are you saying your style is still a child of UI.X though it doesn't depend on it? There will potentially be some oddities if multiple styles define the same style properties, though this is the first time I've heard of anything.

If you install the independent theme in a sub-tree where there's no UI.X, does it have the same problems?

 

[brstrm]

To answer your first question, no. As one would expect, when overwriting a previously UI.X dependent child theme with its updated XML (now exported as a independent theme), the style tree reflects that it is no longer a child of UI.X. However, custom style properties created in UI.X are no longer shown in the Admin CP for the said theme.

To answer your second question, a fresh install of the independent theme works completely fine. The problem only arises when overwriting a previously dependent theme.

Thanks again!

 

[Mike]

Do you think you could provide me with the files to reproduce this? (As I guess I would need the parent framework, the dependent version and the independent version which I then install and move the style.) You can PM them to me if preferred.

I have a feeling this may end up being a design issue to some degree. The behavior around per-style style property definitions is very tricky, particularly when you have potential name conflicts like this.

 

[brstrm]

Thanks again, @Mike. I've sent a PM with the files.

 

[Mike]

This is sort of a design issue and it is down to the duplication of groups/properties.

When importing a style, if a group already exists in a style from a parent, it's not imported in the child. The properties still are, though they're associated with the parent definition (I think). When the style is moved, these properties are still set but the groups aren't available so they get hidden. The values are still there. There isn't really a great way around this short of not allowing style properties to be defined in custom styles (which isn't a solution).

Workarounds basically involve moving the style before importing the new independent version or importing, moving and reimporting.

 

[brstrm]

Thanks for looking into this matter, @Mike . @Audentio and I sure appreciate it.