When this module is enabled, the admin/blocks page stops working properly. The page no longer displays with the correct theme, all blocks are set to seemingly random or "none" showing, custom regions from the current theme no longer show up, and no settings can be saved.

When I disable workflow-ng, all returns to normal.

I tried digging through the code, but could not, at least at first glance, tell what might be triggering this. We'd like to use the functionality of this, and dependent modules, but we kinda need to be able to administer blocks. : )

Comments

Coyote’s picture

Coyote CreditAttribution: Coyote commented
Version: 5.x-1.0-beta4 » 5.x-1.0

Entered the wrong version in my note. We're using workflow_ng-5.x-1.0.tar.gz

fago’s picture

fago
Primary language German
Location Vienna
CreditAttribution: fago commented

hm, sry but I've no idea how workflow-ng should cause this. workflow-ng doesn't do anything related to theming or blocks.

Are you sure workflow-ng is the only module you have disabled / enabled when you ran over the issue?

Coyote’s picture

Coyote CreditAttribution: Coyote commented

Yep. It's had me puzzled. I couldn't find anything that leaped out at me in workflow-ng, that I thought should cause this. I'm suspecting that it's a conflict with another module, but disabling other stuff doesn't seem to help. If I can isolate what exactly it seems to not play well with, I'll update.

I've tried disabling other modules, to see if I can narrow down what might be conflicting.

Basically, there seem to be two things I can do to get the blocks page working again.

Disable the admin theme setting (so that the admin pages use the regular site theme).
Disable workflow-ng.

I don't think we've done anything particularly strange with our theme. When I get to work tomorrow, if I can, I'll try enabling different themes, and see if it's (somehow) a theme issue.

anthonyyager’s picture

anthonyyager CreditAttribution: anthonyyager commented

I can confirm that has happened to me as well using the same version.
Does this support page help http://drupal.org/node/72851

fago’s picture

fago
Primary language German
Location Vienna
CreditAttribution: fago commented
Version: 5.x-1.0 » 5.x-1.x-dev
Priority: Normal » Critical
Status: Active » Fixed

ah thanks. I was able to reproduce it and I committed a fix to 5.x-dev.

However, some conditions or actions configured for event "user is going to view a page" might lead to this behaviour again. If so, as workaround a condition that checks the path for the block admin page, should help as workaround.

Anonymous’s picture

(not verified) CreditAttribution: commented
Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.

plan9’s picture

plan9 CreditAttribution: plan9 commented
Version: 5.x-1.x-dev » 5.x-2.2
Component: Code » Wng API
Status: Closed (fixed) » Active

I have this problem with "user is going to view a page" events. Adding a condition to check for block page path - or user is not Admin - has no effect.
Removing or de-activating the rule makes the block page accessible again.