Blocks page display problem [#1786072]

Blocks administration page is destroyed after enabling Modal forms module, showing all blocks as disabled, except
Navigation (module: user) and User login (module: user) , that show up as beeing in the "Content" region, even if they are not actually in there. More than this, the options for the regions are limited to "Content" and " none ".

Comment	File	Size	Author
#4	modal_forms_block_admin_1786072_4.patch	1.41 KB	dalin

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

zet CreditAttribution: zet commented 17 September 2012 at 21:26

After further review, i see the issue described above happens when there is a specific administration theme set up. So the blocks page display just that administration theme's blocks configuration, regardless clicking links for other themes blocks page configuration.

After disabling Modal forms module, everything goes back to normal.

Comment #2

cluke009 CreditAttribution: cluke009 commented 24 September 2012 at 13:44

Could you let me know which theme you are using and perhaps add a screenshot

Comment #3

graysadler CreditAttribution: graysadler commented 29 September 2012 at 20:14

I have the same issue using RootCandy admin theme. The issue appears to be related to hook_init and not returning when on admin urls.

For some reason I can't create a patch, but here's my code to fix it. First check if _modal_forms_doheader returns true and if not return:

function modal_forms_init() {
  // These function calls must be made in this order.
  // If not the modal js code will not be loaded correctly.
  if(!_modal_forms_doheader()) {
  	return;
  }
....

and then in _modal_forms_doheader be sure to return true:

...
  if (variable_get('modal_forms_contact', 0)) {
    drupal_add_js($path . '/js/modal_forms_contact.js');
  }

  $already_added = TRUE;
  
  return true; //added
}

Comment #4

dalin

he/him

English

🇲🇽, 🇨🇦, 🌍

CreditAttribution: dalin commented 13 May 2013 at 15:01

Component:	User interface	» Code
Priority:	Normal	» Critical
Status:	Active	» Needs review

File	Size
modal_forms_block_admin_1786072_4.patch	1.41 KB

Marking as critical since this can result in data loss if someone saves the block admin page while the page is in this broken state.

My problem was actually two-fold. I was dealing with the issue described in #3. But there was an additional problem where a WYSIWYG had mangled the "Deactivate modal forms on specific pages" field at /admin/settings/modal_forms (wrapping in p tags and replacing line breaks with spaces). So for other people dealing with this, be sure to check that as well.

Patch attached that instead moves the ctools calls to the bottom of _modal_forms_doheader() (Since we those are mandatory to make the whole thing work).

Comment #5

frjo CreditAttribution: frjo commented 14 May 2013 at 09:22

It was user cluke009 that committed the D6 version but noting has happened after the first commit. If anyone is interested in taking over the D6 branch please let my know.