Theming Modal Frames

Yeah I see what you are saying.

Jquery UI Themes
It does make sense to submit requests to the jquery UI module moderators to provide a patch so users can specify themes to use. I already started researching this and the easiest solution is a small settings form that loads the themes for the jquery ui module into a select list and then have a pre-processor function add the theme css resources during pre-precess for the jquery ui module.

-- snip --
Looks like the community is already discussing this and has a patch (not in the dev release yet) http://drupal.org/node/388384

I could also make a bridge module that is just aware of the settings and provides a link or render of the settings form in an admin for modal frame. Maybe called (Modal Frame Theme)?

Modal Dialog Content Theme
As for the ThemeKey module I agree that is where I am going to start. For starters I am going to research different techniques between the themekey and modalapi modules and see where I get. I think I will identify issues with the two very quickly. My current theory is that the themekey module bases the switching of the theme by path or form ID. So as a developer I would have to register every instance of a modal dialog path or form ID. That could be very time consuming and fragile as the developer would have to keep up with each new path and or form ID (such as adding a new module, content type, view, etc). It would be easier if a developer could specify what theme to use and where.

• Use theme A for all modal frames
• Use Theme B for the page content type
• Use theme C for the path "submission/contact"

Or maybe a list of registered paths and form IDs that are loaded in the modal frames.
Perhaps I could make a bridge module that is dependent on the themekey module that provides a centralized administration UI as it pertains to modal dialogs? Maybe call it (Modal Frame Content Theme)

ADMIN V2 Menu Conflict
http://drupal.org/project/admin

I am working on a design pattern related to the issues I highlighted above it includes using the ADMIN module V2 with the modal dialog. The problem is that all modal dialogs render the admin menu when they appear and I am thinking of creating another bridge module that disables the rendering of the admin menu within a modal dialog. This could also be a setting displayed in an administration ui too. (Modal Frame ADMIN Settings)

I understand your reasons for not having a settings interface for the contributed modules.. but we could have a Modal Frame UI module that is optional (similar in concept to views and panels) it isn't required and can be turned off. So developers can hide it from clients if they so choose.

Contributed Module Ideas
I am also researching a few ideas and wanted to know if I should post a new issue for each with status updates and code once I get a first build. Here is what I am thinking about:

The current Modal frame contrib module provides hooks for editing blocks in-context. Need to research node, field group, cck field, and views modal dialog editing in-context to a page.

Features Ideas

   1. Modal API Administration Settings
         a. Form to define Modal Dialog Themes (integrate with jquery update and jquery UI modules, extend css location with drop-down of themes in [development-bundle/themes] directory.
         b. Form to define default Theme of Modal Content
         c. Maybe integrate with ThemeKey to register per Path and Form ID theme selections (reference Captcha examples)

   2. Modal Settings per Content Type (edit node)
         a. Validate against permissions for a type.

   3. Modal Settings per Field Group
         a. Validate against permissions for a field group. (don't think there is a access permissions scheme for field groups)

   4. Modal Settings per Field
         a. Validate against permissions (integrate with Field permissions module)

   5. Modal "Preview" for node add/edit (to provide a real preview in the whole theme) Especially good when using a different theme for administration verses the main site.

   5. Module to override rendering ADMIN V2 menu in modal dialogs. (Modal API ADMIN Bridge)

   6. Create new icons for editing in-context for blocks, nodes, field groups, cck fields, and views. maybe different icons based on types.

My first pass is providing the ability to edit content in-context for a page. Once I have accomplished that if I get the theme modules working is to provide theme selection per content type, field group, cck field, and or view. Of course the first build will just be to specify a theme for all modal frames.

Could we keep this issue open so I can post updates, images, and code as I progress through the testing stage?

Update

Jquery UI Themes
Applying the patch detailed in this issue adds the ability to select jquery themes for a dialog. (http://drupal.org/node/388384)

To accomplish it I had to:

1) modify the css in the theme to not squash the css loaded for the dialog.

// modalframe/css/parent.css and modalframe/css/modalframe.parent.css
/* $Id: modalframe.parent.css,v 1.1.2.4 2010/01/02 06:07:14 markuspetrux Exp $ */

/**
 * jQuery UI Dialog classes.
 */
/*
.modalframe {
  color: #000000;
  background-color: #ffffff;
  border: 2px solid #1b5084;
}
.modalframe .ui-dialog-titlebar {
  position: relative;
  cursor: move;
  height: 26px;
  background-color: #336699;
  border: 1px solid #6694c6;
  white-space: nowrap;
}
.modalframe .ui-dialog-title {
  display: block;
  position: absolute;
  top: 0; left: 0;
  margin: 0.2em 0.5em;
  padding: 0;
  color: #d9d9d9;
}
.modalframe .ui-dialog-titlebar-close {
  display: block;
  position: absolute;
  top: 0; right: 0;
  margin: 2px 2px 2px 0.5em;
  padding: 0;
  width: 23px;
  height: 20px;
  background: url(../images/close.gif) no-repeat 0 0;
}
.modalframe .ui-dialog-titlebar a.ui-state-hover,
.modalframe .ui-dialog-titlebar a.ui-state-focus {
  background-position: 0 -20px;
}
.modalframe .ui-dialog-titlebar-close span {
  display: none;
}
.modalframe .ui-dialog-content {
  color: #292929;
  background-color: #f8f8f8;
}
*/

/**
 * ui-dialog overlay.
 */
.ui-widget-overlay {
  position: absolute;
  top: 0; left: 0;
  width: 100%; height: 100%;
  background-color: #aaaaaa;
  opacity: 0.4;
  filter: alpha(opacity=40);
}

/**
 * Dialog content.
 */
#modalframe-container {
  margin: 0;
  padding: 0;
  background: url(../images/loading.gif) no-repeat 50% 50%;
  overflow: visible;
}
#modalframe-container.modalframe-loaded {
  background: none;
}
#modalframe-element {
  margin: 0;
  padding: 0;
  border: none;
  /* border-bottom: 1px solid #1b5084; */
}

/**
 * Helpers to enhance the Modal Frame API.
 */
.modalframe-throbber {
  display: inline-block;
  width: 13px;
  height: 13px;
  background: transparent url(../images/throbber.gif) no-repeat 0 0;
}

2) Add class names to the modalframe-page.tpl.php

<div class="modalframe-page-wrapper ui-widget">
  <div class="modalframe-page-container clear-block">
    <div class="modalframe-page-content">
<?php if ($show_messages && $messages): print $messages; endif; ?>
<?php print $help; ?>
<div class="clear-block">
  <?php print $content; ?>
</div>
    </div>
  </div>
</div>

This enables the themes to be loaded (see attached screen shots)

Modal Dialog Content Theme
Actually it was quite easy to setup themes per paths for the modal frames. It still requires lots of configuration but once you identify the paths updating it is trivial.

http://drupal.org/project/themekey

In my test case I am defining the theme for the noderelationships module (http://drupal.org/project/noderelationships)

I added the following themekey theme switching rules:

a) Drupal:path = noderelationships/search/% (theme)
b) Drupal:path = noderelationships/create/% (theme)

The last bug I am working on is the ADMIN menu (I minimized it for the screen shots [top right corner]) is displayed on every dialog.

So this is encouraging!

Arg the images I uploaded were works in progress the attached are the final examples once I fixed some css collisions.

Thanks for the update:

CSS Override
Yeah it looks very easy to override the css for the module in the theme.
So I would copy the css from the module into my theme directory and register it in the info file like so:

stylesheets[all][] = parent.css
stylesheets[all][] = modalframe.parent.css

Template File
Yep the example I provided I moved into my current theme. The important thing is to put the template file in the correct theme. Defining the theme via ThemeKey means you must put the template file in the correct theme (In my case the Rubik theme).

Theme Key Path
I see so when I get the newest update I may need to add this path instead.

Drupal:path = node/add/%?noderelationships_referrer_type=%&noderelationships_field_name=field_noderefence | (theme)

Sweet! Thanks I will battle forward to try and get the ADMIN module conflict solved.

Ok solution for ADMIN integration, the solution isn't very elegant but it works.

From the ADMIN module copy the [admin/theme/admin-toolbar.tpl.php] template file and move it into your theme folder.
Add the following line and the admin menu won't render in modal frames.

if (empty($GLOBALS['modalframe_page_template'])) { 

template display goes here

}

--
I researched the ADMIN module and found two locations where I tried to "short circuit" the loading of the menu.

admin_init()
This hook loads all of the admin CSS and JS resources into the head of the page template.

admin_theme_registry_alter()
This hook add a process_pre_page function that loads blocks of content into the menu block prior to any of the page preprocess functions in the preprocessor stack.

admin_footer()
This hook loads the rendered ADMIN container divs and blocks into the footer of the page template.

--
So I attempted to create a bridge module modalframe_admin that would stop loading at any of the three hook locations based on the state of the global variables defined by the modal frame api. Sadly I couldn't crack that nut :(

So the solution you see if what I could get to work without modifying the ADMIN module. The short coming of this tactic is all of the CSS and JavaScript for the ADMIN menu is loaded into the modal frame even though I don't render the container and divs. I don't like my solution as it is pretty inefficient and may have performance issues on larger Drupal sites with 1,000 to 10,000 of concurrent users.