Skinr forces Panels 3.7 into legacy mode

i'm seeing this as well -- for skinr 2.x.-dev.

tsvenson: Category --> bug? Version --> 6.x-2.x-dev? (didn't want to change your bug ... will open a new one if appropriate)

Panels operating in Legacy mode
Panels is operating in Legacy mode due to the following issues:

* Panels 3.6 made changes to the rendering order in a way that affects certain style plugins. The above modules implement style plugins, but have not indicated their compatibility with this new system. See http://drupal.org/node/###FIXME for information on how to update style plugins to the new system.
o skinr - Style plugins

drush pm-list | egrep -i "skinr|panels|ctools"
 Chaos tool suite    Chaos tools (ctools)                                     Module  Enabled        6.x-1.7       
 Chaos tool suite    Chaos Tools (CTools) Plugin Example                      Module  Not installed  6.x-1.7       
                     (ctools_plugin_example)                                                                       
 Chaos tool suite    Custom content panes (ctools_custom_content)             Module  Enabled        6.x-1.7       
 Chaos tool suite    Custom rulesets (ctools_access_ruleset)                  Module  Enabled        6.x-1.7       
 Panels              Mini panels (panels_mini)                                Module  Enabled        6.x-3.7       
 Panels              Panel nodes (panels_node)                                Module  Enabled        6.x-3.7       
 Panels              Panels (panels)                                          Module  Enabled        6.x-3.7       
 Panels              Panels In-Place Editor (panels_ipe)                      Module  Not installed  6.x-3.7       
 Skinr               Skinr (skinr)                                            Module  Enabled        6.x-2.x-dev   
 Skinr               Skinr UI (skinr_ui)                                      Module  Enabled        6.x-2.x-dev

might as well ... revert if/as needed.

You mean go back to the old version?

Subscribing

> You mean go back to the old version?

no ... revert the bug if the OP prefers/insists

Subscribing

Subscribing

Subscribing

Is there something we can do to speed this process up? Is there a schedule?

I really want the full awesomeness of skinr AND panels. ;)

Actually what does mean with Panels running in legacy mode?
Panels are limited over all? Or Panels works with all functions, just not with Skinr?

@ddave, one of the maintainers was just married and on vacation and the other is getting married this week and will be on vacation as well so thus the lack of updates recently. Right now there are primarily only two people maintaining and contributing to the module and what would speed the process up is for more people to jump in and help with testing, debugging, and most importantly writing patches! I'm sure if anyone is able to step up and help, it will be welcomed and appreciated.

tsvenson and BenDJ, thanks for the report and details!

I am very willing to test any devs that might come. Sadly I am a no code guy but I am pretty good at testing/breaking. ;)

It seems the only impact this has is that you can't choose any of the 'new' panels rendering modes. The only new rendering mode I've seen is the 'In Place Editor'. The old legacy mode renderer works fine with the current Skinr. I'd love to help get Skinr compatible with the new renderers but the upgrade guide doesn't seem to exist yet (note the ###FIXME in the URL #1)

Edit:

1st step seems to be telling panels / ctools plugins that you support the new set up:

in skinr.module

/**
 * Implementation of hook_ctools_plugin_api() to let the system know
 * we support the new panels rendering engine
 */
function skinr_ctools_plugin_api($module, $api) {
  if ($module == 'panels' && $api == 'styles') {
    return array('version' => 2);
  }
}

Only just started testing but everything seems OK so far. Some of my CSS is being over-ridden by the IPE styles; but nothing some more specific CSS selectors in my skinr classes can't fix.

@tsvenson

What happens? The new CSS selectors messing with styles or something more serious? I'm only messing around with a dev site at the moment, so I'm working pretty basic at the moment.

@tsvenson(, @meatsack)

My impression is that all that's going on here is that panels is checking that the new version is fully supported and finding that skinr isn't fully ready for it yet and so is running in a mode that allows it to function fine but not fully.

So panels in legacy mode should be just as good, and almost certainly even better, than the previous version, and there's no need to dump skinr, which only has a bit of catching up to do, unless you can't wait to use the full new panels release.

But nothing is broken about panels because of this and nothing bad is happening.

Perhaps @meatsack or someone can confirm that as I'm seeing the same thing and wouldn't want to follow my own advice if I misunderstood!

Apart from asking merlinofchaos directly those issues might help to understand the problem and how to fix it:

Panels: #865840: How to upgrade a style to be legacy free
Tabs Panel Style: #865922: Update to work fully with panels 3.7

@tsvenson

I linked to those issues because they deal with the problem and contain some useful info. Maybe it is useful for those trying to fix the problem here but most probably the maintainers already know what to do.

http://drupal.org/node/869612 (a problem with content visibility rules for mini panels in Panels 3.7) might or might not also be associated with Panels running in legacy mode awaiting Skinr update.

So, regardless of what I said in #18, I've now reverted to Panels 3.5 for the time being.

Subcribing

Subscribing

subscribe

Subscribing

Subscribing

subscribing

Sub

Same issue, subscribing.

Subscribing

sub

subscribing.

Have you guys seriously explored what Panels 3.7 can do now?

It's completely off the hook — to the extent that I need someone to explain what Skinr brings to the table that Panels doesn't already do by itself.

We could already add arbitrary classes and id's to panel regions and/or individual panes through the basic Panels UI. And now, with Panels 3.7 we have the ability to save and reuse layouts, custom content, rulesets and even complete style sets for both panel regions and panel panes.

Not to be cold, but remind me again why we still need Skinr?

@Zach, If you don't need or want to use Skinr, don't, but please don't spam this issue. A lot of us here, myself included, are frustrated, but patiently waiting for the updates required to make Skinr with the new version of Panels. If you want to have a discussion about whether or not Skinr is worth using, go to the group, the forums or create a support request.

My apologies, Jacine. I can see that my tone was kind of flip. I wasn't trying to spam the issue or denigrate anyone's efforts. I really like Skinr and it has fast become one of the default modules in my startup set.

Like many others in this thread, I was doggedly trying to get Skinr to work with Panels 3.7 when it occurred to me that the new features in Panels 3.7 are capable of delivering some, if not all, of the functionality that we have previously needed Skinr to provide?

Is this not at least a valid point to raise within a thread full of people who feel stymied by incompatibilities?

Just as an FYI, the only thing you lose in legacy mode is the IPE. All of the other new features are available.

@Zach: Is the current Skinr 6.x-2.x-dev working at all for you? On my site it is completely broken for about 3 weeks. Issue: #856768: Fatal error: Call to undefined function skinr_fetch_config(). And yes, this site is (um... was) using Skinr styles (opposed to Panels)

@Zach, Thanks for your thoughts and feedback. There is one important distinction you seem to have missed about Skinr. It works without Panels. Not everyone is using Panels and having a means to apply classes or skins to Drupal entities directly is a key, important feature. If you are using the newest version of Panels and it offers everything you need, then by all means don't use Skinr. Also, note that another key feature is to be able to apply skins that include additional CSS files AND Javascript files to fully setup complex functionality such as a superfish style menu with only the click of a button.

@Merlinofchaos, thanks for the heads up on the additional information!

@Chris: A few quick replies to your points.

There is one important distinction you seem to have missed about Skinr. It works without Panels. Not everyone is using Panels and having a means to apply classes or skins to Drupal entities directly is a key, important feature.

Conversely, we could argue that one important distinction of Panels is that it works without Skinr ;)

After all, according to the official usage stats there are 48,885 sites using Panels vs. 13,629 using Skinr — and having a means to not only add classes and skins, but position any and all Drupal entities as draggable panels is pretty key, too .

Also, note that another key feature is to be able to apply skins that include additional CSS files AND Javascript files to fully setup complex functionality such as a superfish style menu with only the click of a button.

Panels 3.7 Styles can do everything you just said and much more: Not only can you create custom panel Styles with the ability to load css and javascript, they can also control foreground and background color (like color.module), manipulate css, and even process images. The Panels Stylizer can even creati custom Styles directly through the UI. Panels Styles can be saved, reused and even exported (through the new Export UI framework) to other sites as custom plugins along with custom rulesets and even custom content.

(P.S. I feel this is a productive discussion directly relevant to this thread, but if the others disagree, it won't hurt my feelings to move it.)

Oh my god... Are we seriously comparing Panels to Skinr here? I'm sorry but the two are nothing alike at their core, and it is comments like this that make me wonder why I spend so much of my free time contributing, to people who do not understand that we spend our time working on this stuff, without getting paid most of the time, and at times have personal and professional obligations that mean we CANNOT be on the bleeding edge 24/7/365. It's upsetting to say the least, especially when yes, there are 13k people using it and not one has stepped up with a patch.

The whole reason Skinr was written is so that you can easily use predefined styles between panels and non-panels output, and also give your clients admins using contrib themes that support it an easy means of applying them to new content. You clearly prefer to use Panels, so go for it.

This issue is about upgrading Skinr to work with the new version of Panels and that is it.

No need to get upset, Jacine.

I'll try again. And this time I'll do my best to stay within the approved parameters of upgrading Skinr to work with the new version of Panels.

In reading Merlin's Panels 3.7 announcement, I noticed he actually hoped Skinr could make use of the new Stylizer back end:

As part of this release, the entire UI was moved completely to CTools. While at the moment only Panels currently implements stylizer styles, the move means that non-Panels systems can make use of the stylizer back end for whatever nefarious purposes they desire.
This means Skinr hopefully can eventually use it, or someone could write a style manager for blocks that overrides theme('block') and lets non-Panels websites style their blocks more freely.

That sounds really cool, and is completely in line with Skinr's goals to easily use predefined styles between panels and non-panels output. In terms of upgrading Skinr, would you be interested in leveraging the stylizer back end like he is suggesting?

Oh, now I shouldn't be upset. You are still spamming this issue, while at the same time asking for a feature request, and then you have the balls to throw collaboration attempts that we've made with Earl Miles to try to improve Skinr's interface with Panels in our face (after insulting us by saying Skinr is worthless) because it's not implemented in the time frame you want?

Bravo. Typical from someone with no code contributions under their belt.

Have some patience, Zach. The future of skinr is bright, and it is incredibly useful both to people with and without Panels. Lots of work has gone on in parallel and it's always an interesting issue in open source when parallel development ends up meeting. We'll work it out.

Panels' style system is very specific to Panels and the needs of panes and panel regions. skinr is much more generic and it works on lots of different things. You can still do a lot of things with skinr that you can't easily do with stylizer, and figuring out the right way to be able to get the best out of both of them has left us all scratching our heads a bit on what is the best way, but I'm confident that we'll figure it out and get it done. But these things do take time; the improvements in Panels 3.7 represented months of work by Sam and I and I would hardly expect contrib developers to all be able to figure out how to update their stuff right away, especially when Sam got busy (and sick) and the upgrade documentation didn't get written.

For what it's worth there is an issue in the Panels queue where I describe in broad strokes what is needed to update a style to the style 2.0 system and for most things it's not too much effort. (It's linked several comments prior to this.) For skinr it may be a bit more, I'm not quite certain. That said, maybe you could look at writing a patch for them.

@ Jacine

Just to brighten up your mood: Don't get annoyed by "contributions" like those of Zach. Loads of users "with no code contributions under their belt" are really grateful for your work on the fabulous skinr module. Perhaps try this approach: http://drupal.org/node/876284#comment-3310558 ;)
*slap on the back mode off*

Pretty sure I got it working... patch on the way. stand by.

Please patch this against skinr-6.x-1.5 ONLY, this is the latest stable release so it should be a problem for you.

Once we can be sure its working we can push the changes to 1.x-dev which has some file rearrangements...

crap, its got my file locations... sorry folks one more sec...

Ok this one should work.

For those that haven't patched much, download this file to the skinr module folder, then from the command line, run:

patch -p0 < skinr-panels-866184.patch

Updating status... and a big THANKS for the patches!!!

♥

@jacine: Me loves ya passion. :)

So let's test Dreditor reviews with floats!

+++ modules/panels.skinr.inc
@@ -374,6 +374,12 @@ function skinr_ctools_plugin_directory($module, $plugin) {
+function skinr_ctools_plugin_api($module, $api) {

Missing PHPDoc, should be "Implements hook_ctools_plugin_api()."

+++ modules/panels.skinr.inc
@@ -382,7 +388,8 @@ function skinr_panels_styles() {
-      'render panel'       => 'panels_skinr_style_render_panel',
+      'render panel'       => 'panels_skinr_style_render_region',
+      'render region'       => 'panels_skinr_style_render_region',

Both referring to the same rendering function looks odd. Deserves a code comment explaining the situation at least.

+++ modules/panels.skinr.inc
@@ -399,13 +406,15 @@ function skinr_panels_styles() {
- */
...
+ *
+ */ ¶

Trailing white-space and bogus empty ending PHPDoc line introduced here.

+++ modules/panels.skinr.inc
@@ -399,13 +406,15 @@ function skinr_panels_styles() {
-function theme_panels_skinr_style_render_panel($display, $panel_id, $panes, $settings) {
...
+function theme_panels_skinr_style_render_region($display, $owner_id, $panes, $settings, $region_id, $plugin) {

If $region_id and $plugin are new arguments, then they should be optional and default to certain backwards compatible values, no?

+++ modules/panels.skinr.inc
@@ -444,14 +453,14 @@ function theme_panels_skinr_style_render_panel($display, $panel_id, $panes, $set
  * Render pane callback.
  */
-function theme_panels_skinr_style_render_pane($content, $pane, $display) {
+function theme_panels_skinr_style_render_pane($content, $pane, $display, $plugin) {
...
-function panels_skinr_style_settings_form($settings, $panels_display = NULL, $region = NULL, $type = NULL) {
+function panels_skinr_style_settings_form($settings, $display, $pid, $type, $form_state) {

Are these changes related to this patch?

Powered by Dreditor.

EDIT: #FAIL =)

Subscribing. I appreciate both Panels and Skinr.

WOW! I knew Dreditor was pretty cool, but I never got around to installing it... that's about to change, as long as I can get it running in Chrome ;)

Here's a cleaned up patch. I don't have too much more time to do an intense programming review on this, any help would be appreciated.

Regarding function panels_skinr_style_settings_form($settings, $display, $pid, $type, $form_state) {,
getting it to work was a bit of trial and error. I believe this was causing skinr form issues, so I took the example of the arguments from the new panels style plugins.

Not sure tho, is it worth pulling the changes out and making sure they're required? These are the new panels style plugin variables.

Also, I don't have time to test this on a panels<3.7 install, if anyone is still running 3.5 or earlier and can test this patch for backwards compatibility, it would be appreciated... it may not work tho, a lot of hook arguments changed.

P.S. For anyone interested, I also created a patch to enable Style config in the new Panels In Place Editor: #881562: Panels IPE: Add Style configuration link to pane editor

sub

sub

Thanks @careernerd, @merlinofchaos, @sun and @dddave :)

The patch @careernerd posted was rolled against 6.x-1.5. I tested that and it appears to work. BUT work has already been done on a prior version of Ctools, to account for some of the changes being made in this patch in the 6.x-1.x-dev version. A new directory was created for panels and the stuff was separated into 2 files. So, I attempted to re-roll this manually against the 6.x-1.x-dev version. That patch is attached and needs review and testing with 1 prior version of panels.

Then, there's sun's awesome review. I don't know the answers to those questions. Need a developer here.

As for the 6.x-2.x version, I've also applied these changes there, and all appears to be working. There's a patch attached for that as well. Note: Although this patch should get things working, we need to get these this resolved: #727386: "Cog" missing from all panels and panes that don't actually have Skins applied.. Hopefully something like #727396: Skinr needs drupal_alter for links array has been implemented in the version of panels, but just so everyone knows - that is a separate issue, so let's not get into it here.

So, please... test them out and if all is well and someone can PLEASE test with an older version of panels, and we'll get this committed.

Thank you.

4 days later, 50+ comments on this issue, and no one has been able to test this? :(

Applying the patch file against the most recent released skinr-6.x-1.5 from within the 'Skinr' module's directory fails; applying the patch using the -p0 parameter fails, also. Patching skinr-6.x-1.x-dev without -p0 option fails, also.

The patch file applies cleanly against skinr-6.x-1.x-dev from 2010-Aug-16 with the p0 option:

# patch -p0 < skinr-1.x-dev-panels-3.7.patch
patching file modules/panels.skinr.inc
patching file modules/panels/skinr.inc

The status report at ./admin/reports/status reports:

Panels is operating normally - no out-of-date plugins or modules are forcing it into legacy mode

Applying the patch file skinr-2.x-dev-panels-3.7.patch against skinr-6.x-2.x-dev from 2010-Aug-12 with the p0 option applies cleanly, also:

# patch -p0 < skinr-2.x-dev-panels-3.7.patch
patching file modules/panels.skinr.inc
patching file modules/panels/skinr.inc

.

Status report looks fine, also. I didn't notice any negative side effects so far. I believe that this has fixed a couple of display issues on panel pages with rounded corners as a free bonus. Good work! ;)

Changing status.

Thanks & greetings, -asb

Thank you asb.

Testing still needs to be done with the previous version of Panels, so we don't break the sites of people who have not upgraded. I also would really appreciate it if a developer could look at this and make sure it's all good. Just because it works doesn't necessarily mean I didn't screw something up.

Also, the patches I posted are only meant for the dev versions, with the -p0 option as @asb noted above.

Marking critical

Subscribing

If you're going to change the function name of theme_panels_skinr_style_render_panel to theme_panels_skinr_style_render_regions then you're going to have to make sure to change 'render panel' => 'panels_skinr_style_render_panel', to 'render panel' => 'panels_skinr_style_render_region', as well.

Otherwise the code for 6.x-2.x looks good.

I haven't tested the 1.x code, but I assume the same changes need to be made there. One note for the 6.x-1.x patch... I don't remember having broken out the panels code into a separate file? Was that done later?

subscribe will start testing asap :)

Subscribing

I'm seeing no problems with the patch and panels 3.5...

Works great!!!!:)

skinr 6.x-2.x-dev (2010-Aug-26)
panels 6.x-3.x-dev (2010-Aug-23)
ctools 6.x-1.x-dev (2010-Aug-21)
jquery ui 6.x-1.x-dev (2010-Jul-11)
jquery update 6.x-2.x-dev (2010-Jul-11)
dialog api 6.x-1.x-dev (2010-Aug-13)

(I realize not all of the these are the most recent dev releases, I think Panels has an aug 29 release now.)

I just needed to say THANK YOU!!!!!, this is amazing and I am very excited to dive into it. All your hard work and amazing vision and talent is so much appreciated. Thank you for opening this up to the community, it's just invaluable.

PS I attached the patched version of the Aug 26 release if anyone would like it.

I applied the same patch g76 at #67 used with no problems using:

panels 6.x-3.7
ctools 6.x-1.7

Thanks!

I have also used the patched zip file in #67 , thanks g76, using panels 6.x-3.7 and ctools 6.x-1.7 on production site . Panels is no longer running in legacy mode and all is good.
woohoo

Setting 'reviewed and tested' based on #67-69 reports.

I've been spending all night trying to figure out why my user profiles are crashing with this error on the site I'm working on but I couldn't repro it on another site:

Call to undefined method panels_renderer_legacy::add_css() in /home/...snip.../sites/all/modules/panels/plugins/layouts/flexible/flexible.inc on line 362

It turns out that it was because I didn't have Skinr on the other site and the error only happens in legacy mode. The patched version in #67 fixes it. Yay!

Michelle

The theme function name for region was named wrong. I guess no one tested on regions? I fixed that and suggestion in #23 committed to both dev branches.

However, in panels.skinr.inc we are still using "panels_panel" for preprocess hook callbacks and handlers, and there is no mention of "panels_region" yet. This seems wrong and I'm not sure where to go with it, so marking needs work.

Subscribing

Edit: Oops, sorry.

subscribing. will try to run the patch on a current dev site

The patch has been committed to 6.x-1.x-dev and 6.x-2.x-dev as of 9/4. The issue specifically named in this title has been fixed so I'm closing this issue to avoid confusion.

The remaining tasks that I'm aware of are outlined here: #922136: Ensure features and hooks are properly updated for Panels 3.7.

Working on getting panels to work in D7. Looks like it's not going to be a straight port.

Sorry for the confusion. This should really be done in a separate issue, which I've opened here: #947790: Write simpletests for panels plugin.

subscribing

subscribing

This is closed and fixed in dev... No point in subscribing everyone.

Could this be summarized? Is it fixed in the dev of Panels or Skinr, or both? Thanks!

To summarize:

The fix to make Panels not run in legacy mode is included in the 6.x-1.x-dev and 6.x-2.x-dev versions of Skinr. It was not a problem with Panels. This will be included when 6.x-1.6 official version is released (very soon) and when 6.x-2.0 official is released (will be a bit further away.)

To make Panels not run in legacy mode you will need to upgrade to one of the Skinr dev versions listed above.

It's important to note that there are other some issues/bugs with Panels integration which you can also find listed the queue here.

Let's keep this one closed for good now! :-)

Installing the latest Skinr + Panels + cTools works fine - but upgrading an existing site to the current versions of these modules does not remove the legacy warning on the status report..

EDIT: Upgrade OR clean install - it shows as legacy mode..

At Panels 6.9 now, and this problem still exists..

I've just found out that applying

sudo chmod -R ug+rw drupal-6.20/sites/example.com/files

(which allows reading and writing for webserver in 'files' dir) has resolved the Panels legacy issue for me.

UPD: the issue reappeared, so this advice does nothing. :(

#88 does nothing for me.

thanks @lolmaus for reporting that. I haven't tested that problem but having the right permissions set on your files directory (and sub files/directories) is certainly important. It's possible that people may also want to do change the user/group ownership of the files as well, depending on your operating system. For instance many linux variants such as Ubuntu/Debian use "www-data" for the apache user while others use just "apache" or "httpd" If you run the command in #88 to ensure you have correct permissions set, you may also want to run something like:

sudo chown -R www-data:www-data /path/to/drupal/sites/example.com/files

Please make sure to check what user apache runs as on your system first before running that command or you may break file upload functionality until you get the permissions right. You can find more information on proper file permissions setup at:

http://drupal.org/node/244924

Also, marking this down from critical to major as I don't believe it's critical for 7.x dev right now. :-)

Just for the record, I'm experiencing this with 6.x.

Subscribing

We are decoupling Skinr from 3rd party forms. See #1044222: Remove skin configuration functionality from third-party forms for details.
That means this will be a non-issue for D7. Moving the issue back to D6 where it might still be pertinent.

I take back my earlier comments.. seems fixed now. Was missing panel style lines in the theme info file.

So what's the situation with this issue?

I get:

Panels is operating in Legacy mode due to the following issues:

• Panels 3.6 made changes to the rendering order in a way that affects certain style plugins. The above modules implement style plugins, but have not indicated their compatibility with this new system. See http://drupal.org/node/###FIXME for information on how to update style plugins to the new system.
• skinr - Style plugins

I checked http://drupal.org/node/###FIXME , but it's completely irrelevant.

So, is any action required, or we can just ignore the message?

Vanilla install of Drupal Commons 1.5 includes Panels 6.9 and skinr 1.6, and is displaying this issue. I see little by way of functionality loss for my individual needs in Panels Legacy mode, but it's certainly curious to get a big scary warning sign on the main status page of a pre-packaged "turnkey solution" product.

Is there a -dev version of skinr that fixes this issue? Even so, the Drupal Commons folk tell you not to upgrade a bundled module independently of the release version, but I'm feeling a tad rebellious and might anyway.

Subscribing

Thanks for the two wonderful modules Panels and skinr. Both the modules are terrific - make life so much easier.

On my site, I am still gettting this warning in the Status Report that the Panels is operating in legacy mode.

My site has
- Panels 6.x-3.9
- skinr 6.x-1.x-dev (2011-Feb-25)

I tried with skinr 6.x-1.6 (2010-Nov-10) and get same warning in the Status Report.

I understand that only loss of functionality in Panels operating in legacy mode is IPE.

If possible, I would like to get rid of this warning in the Status Report page.

On my site this warning appears sometimes, but then goes away... Fun.

Any updates on this issue? I have all the latest versions of panels,ctools, and skinr and I'm getting this issue. Panels is forced into legacy mode and no panels are showing up. The page loads but the panel doesn't.

I'm using:

panels: 6.x-3.10
Skinr:6.x-1.x-dev (2011-Feb-25)
Chaos tool suite (ctools) 6.x-1.8+46-dev (2012-Jan-21)

Drupal 6.25

Hi Guys,
Patch g76 at #67, also works great.

Plus I have tried using:
CTools 6.x-1.8
Panels 6.x-3.10
Skinr 6.x-1.6

This is also remove the legacy error.

--
Kamran Zafar
mail.kamranzafar@gmail.com
http://www.cognitiveaxis.com/

It wouldn't work for me since I have a new version of skinr and I can't downgrade. I get this error if I try installing that version now:

warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, 'theme_panels_skinr_style_render_region' was given in /home3/babblefl/public_html/includes/theme.inc on line 669.

Any updates on this issue? I have all the latest versions of panels,ctools, and skinr and I'm getting this issue. Panels is still forced into legacy mode and no panels are showing up. The page loads but the panel doesn't.

I'm using:

panels: 6.x-3.10
Skinr:6.x-1.x-dev (2011-Feb-25)
Chaos tool suite (ctools) 6.x-1.9

Drupal 6.26

This has been fixed a while back. If you're still having problems, open a new ticket. It's likely due to another module or theme.