As designed Add-on style properties aren't kept

[Jake B.]

Affected version

2.0.0

If I make a change to an add-on style property in one of our styles this value is not kept if the associated add-on isn't installed. it'd be really nice if this behavior was changed as we've made some style property changes to add-ons to make them work better in UI.X, but these have disappeared once another person on our team installs the style without that add-on

 

[Jake B.]

Have just done some further testing and the second you uninstall the add-on any customizations in a style get removed both from the database and designer output, this is really dangerous and hopefully can be fixed in the next update

 

[Chris D]

Unfortunately this system is very much so working as it's designed to. We can't leave orphaned properties for a few reasons. If you remove the add-on, and we leave the properties behind, those properties could be totally broken. Phases will no longer exist, the properties may depend on a template belonging to the add-on to even render it.

It's also potentially problematic and unexpected for the end user who installs the style and they don't have the add-on installed. Those XFRM properties will still be imported, but they'll be listed under "Ungrouped properties". To solve that problem, you might want to consider exporting your styles using the "Export from add-on" option. So you'd do an export for XF only, XFRM only, XFMG only, etc.

There's even a possible scenario whereby you could physically develop them as totally separate styles, and still do the "Export from add-on" option when exporting each one. That would likely solve the "dangerous" part you mentioned.

The individual add-on based exports can then be imported into the same style (using the overwrite option). The overwrite option will only overwrite templates and properties of the same name, it doesn't totally overwrite the entire style (at least not with the add-on export option).

 

[Jake B.]

If you remove the add-on, and we leave the properties behind, those properties could be totally broken. Phases will no longer exist, the properties may depend on a template belonging to the add-on to even render it.

It's also potentially problematic and unexpected for the end user who installs the style and they don't have the add-on installed.

I'd think that if they belong to an add-on they just wouldn't display, but keep the value in the database/output. Also, I'm fine with them not importing if the add-on isn't installed. I just want them to not be completely destroyed on my install if I uninstall the add-on

hose XFRM properties will still be imported, but they'll be listed under "Ungrouped properties".

They won't even exist in our database to be exported, as soon as someone on our team uninstalls an add-on (either for testing purposes or whatever other reason) these values are completely destroyed both from the dev output and the database.

There's even a possible scenario whereby you could physically develop them as totally separate styles, and still do the "Export from add-on" option when exporting each one. That would likely solve the "dangerous" part you mentioned.

The individual add-on based exports can then be imported into the same style (using the overwrite option). The overwrite option will only overwrite templates and properties of the same name, it doesn't totally overwrite the entire style (at least not with the add-on export option).

And that's potentially an extra 10 steps someone needs to take if we support 10 add-ons, I'm sure you can agree that isn't user friendly. I do hope this changes as right now we're essentially unable to make any changes to style properties within add-ons. We have 5 people that touch styles and add-ons, it's not realistic for us to expect all of these people to have the exact correct add-ons installed every time they touch UI.X.

 

[Chris D]

That’s really the only viable solution, there’s no changes planned here currently.

 

[Jake B.]

I'm still not really sure if the reasoning behind this is really worth completely destroying style property values in our products. It's essentially making it so we can't change a style property value of an add-on from our style because as soon as we uninstall that add-on it gets destroyed. I don't know about other people, but I'm constantly uninstalling and installing add-ons for testing and if that's going to break changes we make I'm not sure what we'll be able to do if we want to change the color palette value some add-on is using because it doesn't work with a dark style, for example. We can't just never uninstall the add-on on 5 separate installs between 5 separate developers

 

[Jake B.]

Seems this applies to templates too... So essentially we're not able to edit anything from an add-on without keeping it perpetually installed, correct?

 

[Ian Hitt]

This seems like it will be significantly problematic. We can no longer edit templates for add-ons, lest they be deleted upon uninstall? Not only do we uninstall add-ons when we no longer want them, but we also do it for debugging purposes as well. Every time we need to uninstall an add-on for debugging, we lose all template changes?

For CSS changes this may not be as big of an issue, you could argue that you should put all CSS in your own template. But you can't do that for content templates.

 

[Ian Hitt]

This may not apply to everyone, but in XF1 I very often made homepages using xenPorta, or AMS, etc. by customizing those add-ons content templates. This would no longer be a viable option for that.

 

[Mike]

Templates are only removed from the master style on uninstall; they are an exception and they are basically just blobs that aren't exposed in a "meaningful" way to the UI outside of the template. However they are a bit different from style properties -- style properties are essentially equivalent to options. We don't maintain normal options when an add-on is uninstalled, even if the value is customized. Maintaining style properties would be akin to doing that, never mind the situations where the properties could end up broken.

Frankly, you have a rather specific workflow where you require property customizations to be maintained when an explicit uninstall is done. This isn't really an expected situation and would actually be a net negative for the expected/"normal" use cases (which would leave meaningless and/or broken properties around). It is possible you may need to make changes that fit your specific workflow.

 

[Jake B.]

Templates are only removed from the master style on uninstall; they are an exception and they are basically just blobs that aren't exposed in a "meaningful" way to the UI outside of the template.

From my testing as soon as the add-on is uninstall the template is removed from the file system in src/styles/[designer_mode_id]. We've lost many customizations we made to XFRM and XFMG in this way.

Frankly, you have a rather specific workflow where you require property customizations to be maintained when an explicit uninstall is done. This isn't really an expected situation and would actually be a net negative for the expected/"normal" use cases (which would leave meaningless and/or broken properties around). It is possible you may need to make changes that fit your specific workflow.

Our workflow is simply developing add-ons and styles, sometimes these styles have to make style property changes to an add-on (in the event that color palette values a developer used don't work in dark styles, or something similar) that we choose to add better support for. I don't think anything about this is all that strange. The issue comes with the fact that we have 5 people touching these styles and I'm not sure of a reasonable way to make sure everyone constantly has all of these add-ons installed while touching styles and making sure that nobody ever installs one of them (for testing the uninstall process in one of our add-ons or otherwise)

 

[Ian Hitt]

Templates are only removed from the master style on uninstall

@Jake B. Just tested this and they are getting removed from all styles, not just master styles.

 

[Dad.]

@Chris D just curious if you don't mind. Say an add-on developer sets #fff direct in the addon style properties. We want to fix that for a dark theme as an example (quite an issue with even xf official add-ons in xf1) of course. How would you recommend we solve this?

ETA we lost all edits to XFMG and XFRM

 

[Mike]

From my testing as soon as the add-on is uninstall the template is removed from the file system in src/styles/[designer_mode_id].

That may be a bug, though we'd have to confirm it. It's not related to any issue with style properties though.

Just to clarify: this issue doesn't actually really have anything to do with add-ons; that's just a catalyst. It's simply the style tree that does this. If you remove a property in a parent style, it will remove customizations of it in a child style.

If an add-on comes out and removes properties, it doesn't make sense to keep the old ones -- at best, they won't work; at worst, they're broken entirely. The same thing applies to styles that add their own properties. Same logic applies to add-on uninstallation.

The problem is that now there are certain situations where this logic shouldn't apply. What situations specifically? This thread suggests add-on uninstallation, but clearly that isn't going to apply to most scenarios. Conversely, it seems reasonable to suggest that if you're going to be customizing an add-on, it should be installed.

 

[Dad.]

Conversely, it seems reasonable to suggest that if you're going to be customizing an add-on, it should be installed.

Perhaps this is specific to distributed themes and add-ons. In other words if you distributed a theme that has customizations to specific add-ons. I'm curious to know what the change in workflow you guys recommend if we are in fact going it wrong.

 

[Jake B.]

That may be a bug, though we'd have to confirm it. It's not related to any issue with style properties though.

Should I report this in a separate thread? Or is this fine?

Conversely, it seems reasonable to suggest that if you're going to be customizing an add-on, it should be installed.

Well we're not customizing add-ons that aren't install, the issue comes into play when we're customizing an add-on that we then uninstall for one reason or another (another add-on doesn't work with it, we need to test the uninstall process if it's one of ours). Realistically, even if it deleted from the database I'd be happy with it being left in the src/styles/style_properties directory. This may be something we can do with an add-on if necessary. I'd just rather not have customizations we make be completely destroyed from all existence because we need to test an uninstall process, or something along those lines

 

[Paul B]

Why not just set up a clone of the installation to test the uninstall process?

 

[Jake B.]

Why not just set up a clone of the installation to test the uninstall process?

It's not just testing the uninstall process, there are many reasons we uninstall add-ons. Not to mention we have 5 people touching it so the chances of one of these people not having one of these add-ons installed is a very real possibility

 

[Dad.]

Plus people may uninstall or do whatever, thus their style is different after doing so if they ever reinstalled. Or they install an add-on later on after installing a theme. This doesn't affect just us, but every theme designer I believe. Lots of tickets

 

[Steve F]

Say an add-on developer sets #fff direct in the addon style properties. We want to fix that for a dark theme as an example (quite an issue with even xf official add-ons in xf1) of course. How would you recommend we solve this?

I would say contact the developer to remedy that and if it is an official add-on make a suggestion for a change.

Plus people may uninstall or do whatever, thus their style is different after doing so if they ever reinstalled. Or they install an add-on later on after installing a theme. This doesn't affect just us, but every theme designer I believe. Lots of tickets

Isn't there an expectation that if you uninstall a add-on there will be data loss including any custom styling that may have been done?

It's not just testing the uninstall process, there are many reasons we uninstall add-ons. Not to mention we have 5 people touching it so the chances of one of these people not having one of these add-ons installed is a very real possibility

Wouldn't it be best to have a development board just for UIX and official XF add-ons? So everyone is on the same page then handle on a separate board all testing and compatibility issues.