You are here

function wysiwyg_dialog in Wysiwyg 7.2

Same name and namespace in other branches
  1. 5.2 wysiwyg.dialog.inc \wysiwyg_dialog()
  2. 6.2 wysiwyg.dialog.inc \wysiwyg_dialog()

Page callback; Outputs a dialog page for a wysiwyg plugin.

A Wysiwyg dialog is a bare minimum, simple HTML page; presented in a modal/popup window, triggered via JavaScript.

However, Drupal core does not support such a concept, at all. Insanity happens on two separate layers:

  • All HTML pages go through the default delivery callback of drupal_deliver_html_page(), which calls into drupal_render_page(), which in turn *unconditionally* invokes hook_page_build() implementations. Thus, block_page_build() and similar implementations add the entirety of their page regions and blocks to our simple dialog page. Obviously, we don't want that.
  • There is a nice default 'page' theme template implementation, which performs all the heavy-lifting that is required for outputting a sane HTML page through preprocess and process functions. The theme system does not support to "inherit" preprocess and process hooks to alternative implementations. Even a very basic HTML page requires almost all of that. However, the default page template (normally overridden by a theme) contains too many regions and usually also huge a header and footer. Obviously, we don't want that.

The poor workaround would be to follow the Overlay module's implementation in core: override the theme, build everything, and after doing all of that, strip away what isn't needed. Obviously, we don't want that.

Instead, we bend Drupal to sane rules:

  • This page callback returns the actual main content.
  • wysiwyg_menu() defines a custom delivery callback that replaces drupal_deliver_html_page(), just because we need to replace drupal_render_page().
  • Our replacement for drupal_render_page() builds a $page that does not use #type 'page' but #type 'wysiwyg_dialog_page' instead.
  • #type 'wysiwyg_dialog_page' is defined like #type 'page' in system_element_info(), but is required, because there's no way to inherit a theme definition but override the page template file to be used.
  • As a consequence, #type 'wysiwyg_dialog_page' uses #theme 'wysiwyg_dialog_page', for which we have to implement stub preprocess and process callbacks in order to call into the ones for #theme 'page'.

As a result we get:

  • A HTML response.
  • A HTML page wrapped into html.tpl.php.
  • A page title, title prefix/suffix, messages, help, etc.pp.
  • A simple page without regions and blocks (neither built nor rendered).

See also

wysiwyg_menu()

wysiwyg_deliver_dialog_page

wysiwyg_render_dialog_page()

wysiwyg_element_info()

wysiwyg_theme()

template_preprocess_wysiwyg_dialog_page()

template_process_wysiwyg_dialog_page()

drupal_deliver_page()

drupal_deliver_html_page()

drupal_render_page()

system_element_info()

drupal_common_theme()

template_preprocess_page()

template_process_page()

1 string reference to 'wysiwyg_dialog'
wysiwyg_menu in ./wysiwyg.module
Implementation of hook_menu().

File

./wysiwyg.dialog.inc, line 72
Wysiwyg dialog page handling functions.

Code

function wysiwyg_dialog($plugin, $instance) {
  $plugins = wysiwyg_get_all_plugins();
  if (!isset($plugins[$plugin])) {
    return drupal_access_denied();
  }
  $callback = $plugin . '_wysiwyg_dialog';
  if (!function_exists($callback)) {
    return drupal_not_found();
  }

  // Suppress admin menu.
  module_invoke('admin_menu', 'suppress');

  // Add editor instance id to Drupal.settings.
  $settings = array(
    'plugin' => $plugin,
    'instance' => $instance,
  );
  drupal_add_js(array(
    'wysiwyg' => $settings,
  ), 'setting');
  $build = $callback($instance);
  if (!is_array($build)) {
    $build = array(
      '#markup' => $build,
    );
  }
  $build += array(
    '#instance' => $instance,
    '#plugin' => $plugin,
  );
  return $build;
}