Skin Manager Interface Suggestions

[Chris Griego]

I often hop into the language set while skinning to look for available language bits to fill in here and there. Especially with 2.0's format changing so drastically ("ipb" instead of "ibf", [''] instead of .) it's hard to pull them over once I find them. I made this small change myself to my AdminCP and it's already made my life easier.

[b]Languages[/b]

- Have the language bit names listed in a ready to copy and paste format. [s]<ibf.lang.bit_name>[/s] {ipb.lang['bit_name']}.

<{POST_SNAPBACK}>

[eyedam]

[b]Skin Manager Home[/b]

- Show the total number of members using each skin, like in previous versions.

Yes, this would be a very nice, and, I suppose, quite easy to implement feature. :)

- Add a method for copying portions over from other skin sets, say I create a new parent skin and want to start off with another skin's stylesheet or macro set. Especially in the case of the macro set, there's no easy way to do that.

Yes, this is the downside of the skin manager interface change v1.3 -> 2.0
Before, there were each template set, wrapper, css and macro set separated. And then you just combine them together to form different skins.

Now, when the inheriting system is implemented, you can either use the parent set for a specified elemtn or not use it (and make anything from scratch). This is easier only for the HTML templates, as there are a lot of them. And thanks to this system, you can change only a few of them leaving the rest untouched.

However, if not HTML templates, the system is more inconvenient for applying particular wrappers, macros or css. I have had problems especially with the macros. As basically I have two types of macro sets. And I want to apply them to different subskins. But I cannot, because I can only choose to inherit the macros (that would be OK for one macro set), or not inherit (and now I must change all the macros by hand!!!).

I would suggest something between these two systems. Like, for the macros, for example, you can have a few sets of macros. And then you can choose for a child skin if it should inherit the macro set from the parent. If not, then it would let me choose another macro set, I've made.

I hope, this makes sense. :)

Janis

[Chris Griego]

I've overhauled the list to clean out items that have been implemented so it's easier to follow the current suggestions.

There are also new suggestions throughout the list including a Language Palette and improved template compare tool.

[Chris Griego]

[b]Skin Engine[/b]

- Unpack the macros on the front-end (@functions.php load_skin) instead of the backend (@class_display.php unpack_macros). What this will do is allow you to use their contents within the html logic (ipb.skin['_macros']['MACRO_NAME']). You can then use them for skin-specific settings. You can use IPB settings, but these will apply for all installed copies of the skin, macros are tied directly to copies of the skin.

<{POST_SNAPBACK}>

New one inspired by a question asked of me by a skinner. Unfortunately he can't really do what he wanted but this change would allow him. :)

[Chris Griego]

Somebody pinned this. (w00t)
Who? :unsure:

[Matt]

Me. It's a handy reminder of a few things I wanted to do for 2.1

[nicoo]

that sounds good !

[Logan]

Excellent suggestions Chris. Hopefully the majority are added in 2.1 :D.

[bfarber]

http://forums.invisionpower.com/index.php?showtopic=168675
:P

[Toper]

is the CPadmin will be hard coded or it will have "lang_files.php" ?

[Chris Griego]

What's that have to do with skin editing?

[Matt]

All macros are now available from the script execution under the:

$this->ipsclass->skin['_macro'][ --macro name --] array.

[Chris Griego]

Thanks Matt, I've tried to update the list to show what items are known to be included in 2.1.

[iToke]

the ability to assign a skin to member groups would be cool a cool feature :)

i'd like to be able to force guests and standard members to view my site with a skin carrying adverts and give subscribers and donators the ability to browse ad free using a different skin :thumbsup:

[Chris Griego]

Added to the list, thanks iToke. That's something others and I have wanted and I can't believe I havn't added it sooner. :)

[iToke]

Added to the list, thanks iToke. That's something others and I have wanted and I can't believe I havn't added it sooner. :)

Thanks :thumbsup:

[ph_bradley]

I'd like IPB to translate [ b ] and [ i ] (without spaces) tags in posts to <strong> and <em> HTML instead of the non-logical equivalents < b > and < i >

perhaps some other SEO/accessibility changes too, maybe the use of h1 tags for example? and <alt> tags on images by default, perhaps the filename of the image?

[Will L.]

cgriego i like your list man kool suggestions

[Chris Griego]

I'd like IPB to translate [ b ] and [ i ] (without spaces) tags [b]in posts[/b] to <strong> and <em> HTML instead of the non-logical equivalents < b > and < i >

That's not really related to the Skin Engine or Manager Interface. :unsure:

perhaps some other SEO/accessibility changes too, maybe the use of h1 tags for example? and <alt> tags on images by default, perhaps the filename of the image?

The filename is an awful use of the alt attribute, it's not even alternative content because screen readers will read the filename if there is no alt text. Do you mean these in-posts as well or in the skin? Not really what this topic is about also either way.

And thanks Will78 :)

[DarkChris666]

Jeez these are all great.

[Chris Griego]

The first post has been completely updated in reaction to the new 2.1 Technology Preview, including confirmation of some suggestions being implemented, suggestions that are no longer necessary being removed, a few new suggestions, and a list of 2.1 regressions.

[Chris Griego]

I'm now tracking 2.1 Bugs so it may be worth your time if you find one to check the list first to see if it's reported or even already fixed. Also tweaked and added a few more refinement suggestions.

[Chris Griego]

I just wanted to highlight some of the newer additions to the list, especially the newest one which will make it safer for skins to use graphics for component links like "Blogs" and "Gallery". :)

[b]Skin Engine[/b]

• Pass the 'com_section' or 'com_filename' to the global_board_header_component_link template bit so that it can be used if the skin uses graphics for component links.
  

[b]Edit CSS - Simple[/b]

• There is no Skin Manager breadcrumb.
• Have the color picker link at the top open in a sized window like the other links instead of full screen.
  

[b]Manage HTML Templates[/b]

• Fix the glitch where selecting an HTML template after previously closing another displays the original's list of bits before the new template's bits are loaded. (Perhaps attach the expand event handler code to the iframe's onload event?)
• Use Ajax to save the html template bit to the server so that the textarea scroll and insertion point positions are not lost. Include notification that shows that the save is in progress and remove it when it is completed.
• It would be more intuitive if you could open an HTML template with the same row-sized click-area like you can select template bits with.
• Move "Edit Selected", "Add Template Bit", "X", and the HTML Template Title out of the scrollable area.
• Move the template/bit navigation above the bit edit textareas so things stay in a consistent spot. This interface is also familiar with applications such as iTunes.
• Do not reload all template bits textareas when saving one when editing multiple.
  

[Matt]

"Pass the 'com_section' or 'com_filename' to the global_board_header_component_link template bit so that it can be used if the skin uses graphics for component links."

Done...

[Chris Griego]

Thanks Matt, list updated. :)