This will be part of the Skins v2 plugin thing i'm going to do, i've already got that functionality for panels.

But as you like your hacks so much, why don't you just have;
if ( $current_user->id != MyId ) die('not allowed');

In your skin file?..........

A long time ago [url=http://wonderwinds.com/hackblog.php/2004/09/29/alphabetizing_my_skins_another_b2evo_hac]I did a hack[/url] that covered this idea without telling a visitor to die. Besides going by my ID isn't the idea at all. http://wonderwinds.com/rackblog.php is a publicly available blog that uses an extremely focused skin. If I wanted to allow skin switching how, other than using my skinslist file, would I enable skin switching but not enable selecting the 'rackblog' skin?

-----------------

Back in the day we used to get a lot of people wondering why they had a skin called "_XYZ". That's not the real name but it was a folder that FrontPage put into folders so it could do it's thing. Users who also used FrontPage were getting a 'skin' with that name. _ followed by 3 capital letters is all I'm sure of. So recognizing that issue, and others I'm sure, Francois decided that a folder in skins/ with a _ as the first character didn't get included in the skins list. Likewise if the folder started with a dot (for UNIX hidden files) or CVS (for those who play in that arena) then the folder was deemed not a skin. Unfortunately for me, that decision applies to both the back end and front side of the blog.

This situation is different. I want a folder to be a skin in the back office but not the visible side of the blog. For example if the skin name begins with 'AO_' then I could select if via the admin stuff but you as a visitor wouldn't see it in my skins list.

I thought the skin list (well the one i created anyway ;)) scans the /skins/ folder and any folder that includes a _main.php file is added to the skin list.... With /_something/ skins being excluded.

Hmm.... why don't you just manually exclude your skin from each skinlist?

But you want this functionality added to the core....

I got 2 ideas;

1.
Well, as all sidebar items should be a Panel.
The skinlist would be the same for each skin.
So then you just need to add the functionality into the Skins Panel....

Like have a exclude array....

2.
Let the Skin Framework v2 plugin handle it, but thats a long way off...

But i do not see this as something that should be added to the core..... As it is mearly a issue with how skins display their skins list.... Or am i totally out of tune?

balupton wrote:

Hmm.... why don't you just manually exclude your skin from each skinlist?

Skin lists are dynamically generated. With my way-old hack I can do that, but it's a hack. That means any b2evolution user can't both select a skin for a blog but not allow it on other blogs without hacking. Even with my skin-hack you still have to hack the files. In fact since I did it without putting a bit in the skins/ folder you have to hack _skinslist.php in each skin you have AFTER hacking _main.php in each skin.

balupton wrote:

Like have a exclude array....

Exactly! That's what I did back in the day. A manually built list of skins to not allow on the skin switching section of the front end.

balupton wrote:

Let the Skin Framework v2 plugin handle it, but thats a long way off...

A plugin is probably a completely workable method, which means it doesn't need to be a core feature at all. For example a plugin that lets you select "front side" or "back office" or "both front and back".

balupton wrote:

But i do not see this as something that should be added to the core..... As it is mearly a issue with how skins display their skins list.... Or am i totally out of tune?

The change that hid "_foo" and ".foo" and "CVS" skins was also a change that affected how skins display worked, which is why I thought of a core change. If it was part of the core it would be a subtab on settings that let you say if a skin (other than the three excluded types) was public or back-end or both.

Either plugin or core: as long as it didn't take hacking it'd be a smart improvement. My opinion only eh?

But '_foo' skins serve a particular purpose that needed changes to the core...

But to me i think just using plugins to fix this is a fine idea.

I say the Panels aproach is the best.

But the Skins v2, Aproach would be needed if you want to make sure a user cannot switch to the 'special skin', like via ?skin=thespecialskin.
But that could just be fixed by a plugin / hack anyway....

I think tomorrow I'll do the hackage it takes to make this happen. Shouldn't be that hard given that there are only 2 cases where the skins list is generated and displayed. Adding a user interface on it is overkill. A simple naming convention that says if it's back office only should suffice.

What you could just do, is add a _skinlist.php file in the /skins/ folder and make all the skins include it.... Then in your _skins.php file, add the exclude array functionality and then add your special skin to the exclude array....

That seems to be the easiest/simplist way, and it's a hack not a plugin, so it has EdB written all over it ;) - Or is the hackish EdB starting to take a turn to plugins? :roll:

http://wonderwinds.com/hackblog.php/2004/09/29/alphabetizing_my_skins_another_b2evo_hac

Already half way there :P

Uh... completely there is more like it. I see now where that hack doesn't make pretty for people who want to use a drop-down list, but that's probably something I need to tweak in CSS even though it is (again: probably) due to something that changed in b2evolution itself.

The motivation for this feature request was because it shouldn't take a hack to get it done. I want to be able to download any skin and have it in the back office but not something visitors can select from the skins list.