Now Skinr and Fusion seem to degrading is there a chance that Skinr might be rescued and adopted by AdaptibeThemes?

Could be a cool feature of AdaptiveThemes for such ready to ride distros such as OpenOutreach and Drupal Commons

Would love to see the libraries concept for Skinr also?

Perhaps its as simple as adding some Skinr-esque features to AdaptiveThemes Extensions?

Comments

Jeff Burnz’s picture

Jeff Burnz commented

Why? It has to have a purpose, I don't see any purpose to include this in the core theme?

niccolox’s picture

niccolox commented

Is there another way to apply a style to blocks, panels, regions etc via the UI?

I've probably missed it but I can't find anything close to Skinr circa 2010.

Quite a few of the AT themes of that era had Skinr integration as a prominent feature

Did Skinr degrade? Did the functionality get replaced with something else? Or?

Jeff Burnz’s picture

Jeff Burnz commented
Status: Active » Closed (won't fix)

LOL, are you serious?

Do you seriously expect me to react favorably to someone being an ass?

Do you not think I have looked at Skinr, assessed its usefullness and rejected it already? Of course I have.

Skinr does NOT style your site, it adds classes that are pre-loaded with styles.

Skinr is about style, AT is a base theme that does not style. It does everything but style your site. There is not point in adding Skinr skins to this theme because that is the task of themer, to add such things to a subtheme, perhaps for their client and specific to their theme.

So, instead of totally missing the point of my question and going on a rant, you give me 5 solid reasons (use cases) why having Skinr skins in the core theme would be useful and I'll discuss it.

This is closed.

niccolox’s picture

niccolox commented

Rants? Bloody hell. Settle down jeff

You're pretty quick to jump down on pretty sensible and fair questions

niccolox’s picture

niccolox commented

just focussing on technical issues and skipping the insults

5 reasons to adopt Skinr and the Skinr Libraries

INTRO: SYMBIOSIS

For many of us, our first real Drupal sites where D6 using Acquia Drupal + Fusion + Prosper + Skinr. My next site-building experience was D7 Open Outreach + Fusion + Mix and Match + Fusion Accelerator (Skinr clone). It seems to me, that's a kind of symbiotic ecosystem of modules and themes. Skinr (later Fusion Accelerator) + Fusion was a undervalued combination.

I think I understand your technical point about Skinr as module and AdaptiveTheme as base theme. If Skinr has no place in a base theme then as yourself said it has a role in sub-themes. But how do I include a feature request in all your sub-themes without cross-posting? can we consider this request a meta-issue? I have no doubt this feature request is not quite technically correct, I dont understand enough about theming to be sure, that's why I posted the request to you. Not to annoy you, but to ask the question and start the conversation

I have done some use cases below, I guess they too will be considered rants, anyway, I am trying in good faith

USE CASE 1: existing end users want upgrade path for OpenOutreach + Mix and Match + Skinr

Myself and others use the Open Outreach distro, which had Mix and Match, Fusion and Skinr as a kind of solution. Open Outreach has converted to AdaptiveThemes and has created an AT sub-theme Outreach. Unless I am mistaken there is no way to replicate Skinr functionality in Outreach and although Mix and Match is being converted from Fusion to AdaptiveThemes the ability for users to apply style to page elements like blocks is no longer available through the UI.

USE CASE 2: Distro developers

Drupal Commons and Open Outreach are being built out as ready-to-go end-user friendly distributions based using the AdaptiveTheme. Both are migrating across from Fusion + Skinr. The ability to continue to do front-end appearance changing was a major if undervalued feature of the D6 version (Commons anyway, unsure about OpenOutreach). A major feature-set provided by Skinr is being dropped in upgrades from D6 to D7 which in my ranting attitude is a regression. I humbly ask here that you consider adopting it

USE CASE 3: Themers

The ability to quickly apply arbitary themes to page elements is important. Having Skinr type functionality in AdaptiveThemes core or base-themes is a fast way to get custom themes going with Mix and Match and or Pixture Reloaded, on user friendly, low-budget, ready-to-go distro's such as Open Outreach and Drupal Commons.

It seems to me that a base theme such as AdaptiveThemes would be a sensible place to admin "skin libraries", ie. styles that could be inherited from other skinr stype themes and managed into base themes like Mix and Match.

Why wouldn't I want to use some css from Mix and Match to apply to a login block to a default theme such as Pixture Reloaded? Shouldn't that be managed in a base theme?

USE CASE 4: Content managers

In place editing, WYSWIG, is the future of Drupal. Create.js and Aloha Editor are going into core for D8 I think. The Spark initiative is making the content managers experience a lot more WYSIWIG. Accessing back-end admin forms via links from on-page elements is becoming standard. Is there another way then Skinr to do this?

USE CASE 5: Site-builders

The new Panopoly base distribution is gaining traction. Open Outreach is migrating across on top of it. As to is Open Atrium. Panopoly is all about in-place editing. As a site builder I want a library of themes for sites and pages, but also want felxibility to apply elements of one theme into another default theme. The kind of flexibility Skinr allows.

CONCLUSION

I am attempting, in good faith, to contribute to the development of Drupal and AdaptiveThemes and I am personally sorry I was interpreted as ranting my attitudes

niccolox’s picture

niccolox commented

some more supporting links

Move AT Skinr styles to a module
http://drupal.org/node/892456

Produce new branch of Mix and Match based on AdaptiveTheme or Omega
http://drupal.org/node/1852830

Jeff Burnz’s picture

Jeff Burnz commented

By use case I meant design use cases. #3 is the only one that touches on that directly and makes the misguided assumption that AT Core can guess what a particular design might require. For example Mix and Match might NOT want to support something that AT Core assumes it will want, so in effect AT Core is now bullying theme developers into supporting all its Skins, otherwise they pay the price of answering support requests.

I don't want to do that anymore than we already do, which in hindsight is too much. I have to balance off what would be good for me (adding skins would be good for me) with what is good for the greater community (adding skins is both good and bad, but when its bad its really really bad).

It is simply far and away better to allow sub-themers to add their own skins, on their own terms. If Commons or any other distro chooses not to do this then you should ask them about it, that has nothing to do with me or AT Core.

Jeff Burnz’s picture

Jeff Burnz commented

Look, I just want to add that I have thought about this a lot, I mean A LOT.

It would be hugely advantageous for me to add Skins, think instant skin support for all of my subtheme, both free and commercial. Big win for me. But for the greater unwashed its not so good, and in fact could be quite detrimental.

That is why I thought about putting skins into a module, so AT users could add that module and get free skins, however even that is fraught with issues - in my theming experience its just really hard to make a generic set of skins that work for all themes. You end up with all themes facing the same set of compromises.

That is a big reason I dislike Skinr now, in 7.x, that all skins can apply to all themes, in reality it just does not work. If there is a feature to restrict a skin to just one theme then I would use it, however I am not sure about that, its been a while since I played with it, mainly because I need to learn yet another layer of abstraction.

niccolox’s picture

niccolox commented

ok, thanks for the answers, and no hard feelings, I posted late last night with from my mobile phone using my thumb and so my post wasn't of the highest quality

onto Skinr, Skinr Libraries or similar functionality

I agree it might not be the best place, AT Core, but I still think Skinr would benefit from a symbiosis with AT Core or one of its sub-themes, perhaps the new AT port of Mix and Match in OPen Outreach, or the AT sub-theme in Drupal Commons

I also agree it becomes a serious design management complication, you can create absolute shocking looking sites, think myspace gone wild and the UI becomes unweildy

I am thinking back to building and managing DotNetNuke websites which have styles for Pages and for page elements "Modules" i.e. Blocks/Panels/etc ... it adds a whole new layer of management

but to completely honest, I still think its worth it

I wonder if nedjo could chime in with some comments, perhaps others? if not AT Core, where does this happen? in Skinr?

it would be great if one AT sub-theme, say Outreach or Mix and Match or Pixture Reloaded "just worked" with Skinr libraries

Jeff Burnz’s picture

Jeff Burnz commented

I am replacing my original very long post with a very simple one .

Using Skinr is a risk, both financially to my business and places my users at risk also. If Skinr can fix it's UI bugs (admin menu for one) and can guarantee a timely D8 release without major changes then I might consider it, however past experience does not bode well. My gut feeling is that the Skinr project does not have a future, unless the developers learn to understand the requirements of users and can listen to their concerns.

Sorry, but I will not be supporting Skinr now, or in the future, without absolute rock solid assurances the module will fix its problems and not abandon its user base in D8 as it did in the D6 to D7 upgrade. We all got burned (financially) and we all remember, no one wants to go there again, its not worth the risk.

niccolox’s picture

niccolox commented

Jeff, thanks so very much for the absolute transparency on this issue.

I really appreciate your genuine response in this matter

I am having a look at Panopoly now and will see how that could work with AT etc

Panopoly uses the Panels/Panes style plugin approach...

it would be neat if there was a way for those plugins to extract CSS direct from the theme and not require special plugins

anyway, cheers, I totally accept your rationale and it resonates with my much more limited own experience

-N

nedjo’s picture

nedjo
he/him/his
Primary language English
commented

I think the way forward here is for skins to be provided at the module level rather than the theme one. If a skin is generic enough to be relevant to many themes, presumably it should be provided by a module. Then any theme (whatever its base theme, if any) is free to add its own theme-specific skins.

We mapped the way in #855602: Allowing modules to contains skins, but #886030: Pull Skinr styles into skin sets wasn't taken up (and then Fusion abandoned Skinr for its own custom alternative) and there don't appear to be any module-provided skin sets.

Anyone interesting in pushing this forward could begin by posting a new sandbox module and selectively merging in the most promising existing skin sets, looking e.g. to what was previously in AdaptiveTheme and Fusion.

nedjo’s picture

nedjo
he/him/his
Primary language English
commented

I posted a quick port of the Fusion skins to a new module, Skins. I'll look at porting the former AT skins as well if/when I get a chance, but of course patches or comaintainers meantime would be very welcome.

Jeff Burnz’s picture

Jeff Burnz commented

Well, as I said earlier I have no plans to support Skinr.