[info] Status of 7.x-2.x version of Skinr

Thats weird, what theme are you using? The module is under active development and the overall structure is going to change by the final release but the current D7 version should work just fine. (I have it working on a production site right now) If you want to keep up with the development check out any of these issues:
Skinr D7 issues

The current state of Skinr for D7 can be considered "broken". Purposively. That is, because we are changing bare essentials of the module's functionality currently.

I guess it would be a good idea to keep this issue open.

Just tracking some/most of the relevant issues:

#954874: Rip out .info file handling from skinr core module
#956932: Determine optimal skin include file format
#956990: Clean up and optimize skinset handling code in skinr core
#956994: Write load and parse code for Skinr include files in PHP format

As sun says, its broken as of http://drupal.org/cvs?commit=443546, which is a bummer but just the way it is with many things in flux at the moment.

Yes, it's a bummer, but we are literally busting tail to make it better in so many ways.

It would be great if people could understand that.

subscribe

subscribe

sub

So I have skinr installed in my D7 site, but have not enabled it. I'm assuming this is safe...when it is in a state no longer "broken" for D7 I will grab it and enable then.

This is such a great module and I'm glad the team is developing it to make it even better for D7, I am totally understanding of the wait, just let us know when we can enable it on our D7 site without breaking the site and I for one will help test it out.

Thanks again!

subscribing

Asking very kindly if you Skinr peeps would have a rough guestimate on the ETA of Skinr for D7? I know that's a very hard question to answer and its kinda out of desperation that I ask at all.

As you probably know I rely on this module heavily as do others and out of desperation I upgraded 6.1 to D7 and have it working (unlike the 7.x-1.x alpha in CVS which is not really working at all), because at this stage all my D7 themes are pretty much dead in the water without this module and I need something to develop with (the CSS to support the classes etc).

What I am really driving at here is the possibility (if the ETA is months for 7.x-2.x, which I think it may well be), could we release a simplified 7.x-1-x version (basically a strait upgrade of 6.x-1.x) so we at least have something to work with? It won't be pretty but at least it will work and we'll all have something to use for dev work until the new version is ready? Even when the 7.x-2.x version is ready we'll all have to release new versions of our themes with the new required plugins + build the plugins + testing etc etc, this is all going to delay our theme development efforts for D7.

Please don't think I am moaning, far from it, however I really do wish we had some working code now rather than having to wait an unknown period of time. Basically I am freaking out that we won't have working Skinr code for D7 for 6 months or something, and right now I'm in a position where I just don't know.

Subscribing

@Jeff Burnz, I understand. A release of the 1.x version is just not going to happen. There is just not enough people helping with this module to take the time away from the version we are moving forward with. I'm really disappointed that we aren't further along right now, but it's not for a lack of trying and there isn't much I can do about it.

While the code in CVS isn't "working" right now, this is the only issue that is actually holding up the basic functionality: #956994: Write load and parse code for Skinr include files in PHP format, and it has working patches. I've got the one in #29 running locally to use for my themes: http://drupal.org/files/issues/patch_commit_4790e14e3753.patch

There are changes being made to the hook_skinr_api() part, and it's possible the that .inc file and hook naming might change, but the skin structure itself is pretty much set in stone and documented here (still a patch at this point): #956990: Clean up and optimize skinset handling code in skinr core

The administrative UI is pretty useless right now, so the one catch is that you need to enable the skins in code manually by using the "status" property. To see an example of this, look here: http://dl.dropbox.com/u/912092/grids.zip That is a module implementation of a skin plugin. It's enabling "sky." In a theme all you need is the following (with that patch applied):

1. Add skinr[skins] = skins to your .info file.
2. Create an include file with the name of the plugin in a skins directory: skins/default.inc
3. Implement a hook_plugin_skinr_info() in that file that matches the file name, like: themename_default_skinr_info()
4. Make sure to enable the skins in code by setting 'status' => array('themename' => 1), per skin.
5. Make sure to return $skins
6. Note that there are default groups you can use, which Skinr provides: #977110-10: Create the default group implementation.

This will get you through development.

I really hope that patch will be committed ASAP, but I really don't know when, because I am counting on the work of others to make it happen. After that we still have a lot to do.

Enabling and disabling skins isn't the same as applying a skin to a block or other entity. There is no working administrative interface for enabling and disabling skins at admin/appearance/skinr/skins, but Skinr does work with that patch, if you enable the skins in code, like I said.

What would help dramatically is if you guys would try to follow along with the issue I mentioned (#956994: Write load and parse code for Skinr include files in PHP format) & test things out instead of just asking what the status is. We have a lot of work to do, and I'm sorry it's not ready. Really, I am. However, I plan to get as much actual work done instead of doing damage control in the issue queue for early adopters, otherwise we will not get anywhere fast.

If you are having trouble developing using the instructions I gave in #12, let me know and I'll do what I can to help. :)

Thanks Jacine, much appreciate the robust feedback. Sorry I havent been able to participate more in the testing, time is so precious around this time of the year, I had to let a few things go.

No problem, Jeff. I totally understand. :)

If you are having any issues trying to get this working let me know.

Patches in #12 (956994 and 956990) applied. If there is still work to be done, perhaps a bulleted list on this thread, or somewhere accessible from the homepage, would help.

Look, we have been working on this for months. There is a whole issue queue full of things that need to be done. Attempting to combine issues that are separate for a reason, without any understand of what is going on is not helpful.

My comments in #12 and #14 were directed at Jeff Burnz and peach, as contrib theme developers who need to test Skinr with their themes.

The 7.x version of Skinr is not ready, or supported, so unless you are serious about testing, providing feedback and/or patches to help us get this work done, please do not use Skinr right now. I have updated the project page to make this crystal clear.

I have this working using the instructions in #12, just to fill in a few gaps - you need to checkout HEAD from CVS and then apply the patch linked to in #12. The grid module linked to in #12 is a perfect starting point and with the instructions building a plugin is strait forward.

Theres no sub-theme inheritance at the moment, see this issue #977118: Skins in disabled basetheme cannot be enabled for basetheme (to appear in subtheme), this is not a problem for theme development as I can just duplicate the plugins in the subtheme for the time being.

I'm getting a few notices, warnings here and there, should I report these or just leave it for now?

Inheritance of skins from basethemes into subthemes is tackled in #1015614: Subtheme inheritance.

Patch in #12 seems to contain skinr.api.php changes only, but that file is tweaked and revamped all over again currently anyway.

Overall, I think we can mark this issue as fixed. Trying to achieve a clean and sane target queue to work on for http://drupal.org/project/issues/skinr?version=7.x