When link leads to link which cant be accessed by the current user an empty CTools Modal window is opened followed by the AJAX error with the output of the standard Drupal page render of the 403 or 404 error page.

CTools Modals AJAX Error

#5 1450232.patch4.51 KBdouggreen
PASSED: [[SimpleTest]]: [MySQL] 0 pass(es). View
#1 1450232-1_handle_menu_errors.patch4.59 KBwojtha
PASSED: [[SimpleTest]]: [MySQL] 0 pass(es). View
ctools modals ajax error48.73 KBwojtha
Members fund testing for the Drupal project. Drupal Association Learn more


wojtha’s picture

4.59 KB
PASSED: [[SimpleTest]]: [MySQL] 0 pass(es). View

Initial attempt to fix it.

If the menu callback is returning access denied or page not found in menu_execute_active_handler() the CTools Automodal menu callbacks are bypassed and standard Drupal error pages are returned via drupal_deliver_html_page() causing the AJAX errror.

I'm using hook_page_delivery_callback_alter() to detect it the request is AJAX request and I'm detecting if the current menu callback returns error or not. If so I'm returning special version of the error page and I give opportunity with hook_modal_error_alter() to other modules to react - change the error message or react with own customized AJAX commands on some paths.

wojtha’s picture

Status: Active » Needs review
marco’s picture

thank you for your patch.
I tested it and it worked, but it caused problems with quicktabs module. Every Ajax tab load caused a "An AJAX HTTP error occurred" alert to pop up (and the quicktab was not populated). Interestingly, "HTTP Result Code" was 200 and "StatusText" was OK.

I was able to fix this removing $callback = 'ajax_deliver'; in ctools_automodal_page_delivery_callback_alter(), but I'm not sure why you didn't leave $callback as "drupal_deliver_html_page" when you don't intercept the callback, so I don't know whether my fix has some side effects. Can you please shed some light on this?


wojtha’s picture

Yeah, I've also found that week ago. The "$callback = 'ajax_deliver';" does it wrong, but didnt have time to update the patch yet.

There is no side effects AFAIK, so remove it :-)

douggreen’s picture

4.51 KB
PASSED: [[SimpleTest]]: [MySQL] 0 pass(es). View

Updated patch removing $callback assignment and also fixing PHP warning caused by not imploding $path_parts in one code path.

j0rd’s picture

I have the same problem (updated)

Patch #5 doesn't work for me, I still get the large ajax alert error box.

Patch #1 does seem to work for me, I get the appropriate drupal_set_message() error in the alert box and only that.

Here's what I'm doing.

Using user/login in the modal.

1. Be an anonymous user.
2. Open two tabs.
3. Login (in the modal) with Tab#1 and wait until that process finishes.
4. Now try to do the same in Tab#2 and you'll get "Access Denied" 403 error because you're logged in, and that how it works in the user.module
5. Get a mega huge alertbox with patch #5, and reasonable one with patch #1.

I am also using loggintoboggan module, which has `function logintoboggan_page_alter()` which adds some drupal_set_messages(), which could be causing my additional problems.

Here's that code from logintobogan

 * Implement hook_page_alter().                                                                  
function logintoboggan_page_alter(&$page) {
  // Remove blocks on access denied pages.
  if (isset($page['#logintoboggan_denied'])) {
    drupal_set_message(t('Access denied. You may need to login below or register to access this page.'), 'error'); 
    // Allow overriding the removal of the sidebars, since there's no way to 
    // override this in the theme.                                                               
    if (variable_get('logintoboggan_denied_remove_sidebars', TRUE)) {
      unset($page['sidebar_first'], $page['sidebar_second']);

UX Improvement: Close modal after error is closed.
After the javascript alert() box is closed, ideally we would close the modal as well. This seems to make sense for things like MENU_ACCESS_DENIED, MENU_SITE_OFFLINE, MENU_NOT_FOUND use cases, as the modal will just sit there and be blank.

Dave Reid’s picture

Should this be filed against CTools modal functionality itself? I'm not sure why this is specific to CTools automodal.

antondavidsen’s picture

patch #5 seems to give some warnings in relation to other modules. This was caused by features:

Warning: preg_match() expects parameter 2 to be string, array given in ctools_automodal_is_path_modal() (line 181 of ... ctools_automodal.module).

asimov6’s picture

Shouldn't the path given in menu_get_item($path) in function ctools_automodal_get_page_callback_error($path) not be the full path, i.e. including 'ajax' or 'nojs'.
I am getting page not found for all of the paths without the last bit (ajax,nojs)