Rethink Skin System

[Luke]

I didn't think about this until I had actually bought a skin from someone. Before it didn't make as much sense because I had made my own skins and the current skin system was sufficient.

When you make changes to a skin it shows as "red" indicating that it's different from the root skin. With a custom skin there are already changes made by the skinner you hired (or bought a skin from), but you want to make custom changes to that skin to fit your custom requirements. You make a mistake and screw something up and go to revert it, only to find yourself reverting that bit to IPB's default instead of the skinners default. Oh god what do you do now.... Re-import the skin as a guide and hide it? It's crude, but it seems to be the only option...

Then there's the idea of making another skin as a child of that custom skin and using that one so you can revert it to the skinners default... But wait a minute, you have to show it's parent because if you hide it they can't see the child one. On top of that you're really not to fond of showing your members the exact hierarchy of how the skins were put together, you just want to give them simple choices. You decide to do it anyway and have the main parent( s ) as "Blah Blah Blah Root"... But then you get complains of "this doesn't work", "that doesn't work", just to find they've chosen the root one when what they really want is the modified child version.

... :blink: ...

[UBERHOST.NET]

Making changes on the test board on my PC suits me just fine. As far as changing modified template bits, simple. I copy over the modified working bit to a text file and save it as a backup before tweaking it. When it's done, I import it to my live board.

[Luke]

But that defeats the purpose doesn't it? When you're working from the root template you're able to revert changes. But when you're working with a skin other than the root you don't have that option. And you don't always think about backing up a template bit before changing it. You may think that it's a simple change and wouldn't hurt anything... But then you find out it broke some javascript thing or something crazy.

[Digi]

So, if I get your request, you are asking that the child skins only default to the parent, similar to how parents default to the master templates?

Only issue I see with this is that it will take more space in the database (skin_template table) to implement.

[Luke]

No, I'm saying there should be a better way of handling skins.

If you make a new skin that's a child of your custom skin and hide the parent skin you can't see the child skin.

A simple solution would be to allow the admin to customize the skin selection list without displaying them in a tree hierarchy. I'll give you an example:

In AdminCP:

-Root
---Default IPB Skin
---Custom Skin
-----Customized Custom Skin

Would translate to (for the user):

-Default IPB Skin
-Custom Skin
---Customized Custom Skin

Now if you had this in AdminCP

-Root
---Default IPB Skin
*--Custom Skin
-----Customized Custom Skin

The user would see:

-Default IPB Skin

It would be nice if instead of showing what skin inherited from another to simply show a set of linear choices, shown by the Admin:

-Default IPB Skin
-Customized Custom Skin

That would solve the problem entirely.

[Digi]

Oh I see, I didn't realize this was the case (children not showing if parent is set to invisible) :)

[Alex]

Wasnt the thread about reverting issues :S

[Digi]

Wasnt the thread about reverting issues :S

That's what I thought at first, but I was told otherwise I guess :S

[Luke]

Well you can revert to your custom skin if you make a blank skin a child of your custom skin and modify that child. The problem is the user can select that parent skin when all you want them to select is the child. So you can't use this method unless you want people getting confused to why they can't select the parent.

[Lewis P]

So in short you should be able to set all skin customiseations as default for that specific skin, so that when you revert the html/css, it is back to how it was before YOU modified, not the skin creator?

[Alex]

No, I now understand :) When a skinner creates a skin, it is different from default IPB (duh), but when you click REVERT, it reverts to IPBs default and NOT the skinners default.

[Digi]

I think you are still confused, but it isn't your fault :P

When a skinner creates a skin, it is different from default IPB (duh), but when you click REVERT, it reverts to IPBs default and NOT the skinners default.

you can revert to your custom skin if you make a blank skin a child of your custom skin and modify that child.

So you can revert to skinner's changes, IF you make a child of the skinner's default!

What LUKE is complaining about is, if you set a Parent skin as hidden, no matter if you set the child visible, the children are hidden as well!

He wants that fixed.

[Luke]

True, but not entirely accurate. The skin choice currently reflects the "tree-view" of how the skins are arranged. That's why when you hide the parent skin it would make sense that the child is hidden... It's like hiding a forum and not being able to see the posts. So I can see where the logic in that is.

What needs to change is the skin choices drop down. Instead of simply making a skin visible or invisible you should be able to make a linear list (one level) of available skin choices for the user to see. So if you have:

-Root
---Skin 1
-----Child 1-1
---Skin 2
-----Child 2-1
---Skin 3

You can make a linear list of choices look like this:

-Child 1-1
-Child 2-1
-Skin 3

Instead of:

-Skin 1
---Child 1-1
-Skin 2
---Child 2-1
-Skin 3

Picture the skin's as they are in AdminCP wraped in a box like they are. Instead of having the eye for visible and invisible have an arrow pointing down. There's another box below that represents "Skin Choices". When you click on the arrow it places that skin in the "Skin Choices" box. Items in the "Skin Choices" area have an "X" to remove that skin from the "choices menu".

Or simply make the skins appear in a linear list when they are visible, and make children visible when the parent is not (fix it as Digi says).

Hopefully I'm making some sense..