class lost when editing block and user doesn't have "access skinr classes" permission

The "access skinr classes" is for the advanced settings on the skinr settings form. It has nothing to do with the classes actually printing, and neither do any of the other permissions. They are all strictly for administering Skinr.

If you are still having this problem it's likely that your theme became disabled by this lovely core bug: #305653: Themes disabled during update. It's hard to catch because your theme doesn't actually change, but when you visit the theme listing page, you'll see that it's not checked. That is a common cause of this happening with Skinr.

It's also possible that you are using a module that is causing problems with Skinr, like SwitchTheme, which wreaks havoc with Skinr and should not be used with it.

I'm pretty sure this is not a bug with Skinr, but I'll wait to hear back from you for a bit before closing.

me too having the same issue.

There's no patch to review ;-)

Speaking of patches. Here's a patch to fix this issue. :)

The problem was that the skin was getting reset without checking the old values. So in the case where the user didn't have permissions to the classes options skinr would just set that option as empty without populating it with the old values.

This patches solves this issue by checking if the user has access to the classes options. If the user doesn't have access then it checks if the classes where set before, if they where it sets it again, if it wasn't then it just leave it alone.

EDIT: REMOVED by ericduran.

I love it my Comments are somehow getting submitted twice at the same exact time.

Jacine perhaps this should be committed?

I know this is minimal, and I did write the patch but I'm reviewing this now and the coding standard is wrong. I'm missing a space in the "else".

Also I'm curious if we can have more than one person test this patch ? I just looked at the code and it seems right but I feel we might have miss a couple of situations. Maybe test what happens when someone has the other skinr permissions and make sure nothing breaks. I just don't remember. It was a while ago :-(

Yes, well I would have tested and fixed the code style issue before committing anyway, given what's been going on lately, but you're right.

I would like to see tests written and SimpleTest used, TBH. I just have no clue how to begin with something like that.

Ha, I was thinking simpletest too. :)

Trying to use the patch to test but i cant get it to patch.. :/

+++ includes/handlers.inc	10 Sep 2010 04:36:34 -0000
@@ -75,6 +75,7 @@ function skinr_submit_handler(&$form, $f
+        $pre_edit_skin = skinr_get($theme_name, $hook , $key);

I think $saved would be better here.

Powered by Dreditor.

Will be testing this shortly ;)

Ok, works like a charm. I can't believe no one has reported this sooner. Thank you @jm.federico and @ericduran!

Here's a re-roll, with better comments and $pre_edit_skin changed to $saved. Please review :)

The patch works as advertised. It just needs to be re-rolled to pass testing.

This patch makes the above adjustments in the panels and views plugins as well for version 1.x.

And the same patch for 2.x version of skinr.

Testing failed due to additional wrong version patch. Please test the patch in #22.

Here's a new patch that should apply cleanly to 6.x-1.x-dev.

The patch in #27 applies cleanly and fixes the described issue for 6.x-1.x-dev.

#27: skinr_891942_27.patch queued for re-testing.

I can confirm that the patch in #27 works as described

Thanks! Committed ;)

6.x-2.x: http://drupal.org/cvs?commit=449004
6.x-1.x: http://drupal.org/cvs?commit=449002

Switching to 7.x, as this needs to be ported.

Here is my stab at porting the D6 patch to D7. Probably need some revisions, but we'll see.

*edit* Since I redid my CVS just now it seems the patch is doing a lot of deleting then adding the same code back. I think its because of a way I edited the file. Will see and try to revise properly. Ignore this patch.

This patch now has just the needed changes, hopefully it works.

I was going to test this issue, but before i even installed the patch has anyone confirmed this is a problem in 7? because i can't replicate the error before applying the patch.... :/ my custom class is not getting lost when edited by a user with just access skinr nor does the custom class field appear on the block configuration page....

There's no reason the problem shouldn't exist. It's on the old codebase, which definitely had a bug. I have no idea why you wouldn't be able to reproduce that, but of course that is the first step that should happen in testing.

Also, the indentation is all off in this patch and should be 2 spaces, not tabs. Try running the patch through the coder module.

does this problem happen for you?

I tested this on my current D7 setup and was unable to reproduce the bug. However I would like to install a fresh copy of D7 which has been updated anyway since I setup my local environment. Will do that soon and post back.

Tried testing with latest versions of Skinr & D7 but the edit skin and advanced options from config menu have vanished. Possible issues with update code in Skinr, (http://drupal.org/node/956990#comment-3812874) pending a fix before I can report on the class lost bug being an issue with D7 Skinr or not.

Okay thanks to a patch by Moonray things are working again. I tested with latest version of Skinr (2010-Dec-09) and current D7 (2010-Dec-01) and following the steps does not reproduce the bug. The class remains fine even after editing. This was a bug in D6 Skinr that was never patched in D7 Skinr so why the bug is not present is mysterious.

With #995080: Permissions are confusing fixed, the bug should now become apparent.

Vraja: Have you been testing with an account other than the primary admin account?
I can reproduce this bug without fail.

Here are some tests for this issue.

last patch had a redundant test. Removed and updated.

And of course, it fails. Let's try again.

EDIT: #1082842: Update storage of skin configurations to give more granular control already fixes this bug and passes these tests.

Re #42: "Vraja: Have you been testing with an account other than the primary admin account?"

I don't think I tried this outside of the primary admin account, maybe that was why I couldn't get it. Your latest patches fix this it seems, but i'll test today and see what happens.

Committed tests to http://drupalcode.org/project/skinr.git/commit/9b7803e

#1082842: Update storage of skin configurations to give more granular control fixes the bug itself.