Drupal

Drupal related posts by Gábor Hojtsy.

Tools for the D7CX movement and helping Drupal 7 and modules get translated

Moshe Weitzman recently started the D7CX movement to rally people to get Drupal 7 contributed modules upgraded and released on time for the Drupal 7 release. This would be a great boon to the Drupal 7 release, which shapes up to be a huge improvement over Drupal 6 already. He also suggests a contributed module release manager who can help with (among other things) ensuring that tools are available to help people upgrade.

Two alternatives for the D7UX overlay implementation

By now, the Drupal contributed repository grew so big that there are likely multiple solutions to the same problems there. Maybe these solutions solve the tasks with different angles, have slightly different features, but at their core, they aim at solving the same issue. So it is getting harder for site builders to pick the modules they want to use (and drupal.org is planned to offer more tools in helping with the selection). When it comes to core inclusion though, one needs to very clearly define the requirements and meet core goals, such as lean and mean implementation, maintainability and reusability.

With Mark Boulton's and Leisa Reichelt's suggestion to have most of the Drupal administration interface show up in an overlay on top of the public facing webpage, we are again at such technology crossroads. Drupal 6 at least has two contributed modules to implement a similar-looking solution: Popups API and Modal Frame API. Both got their pros when I researched for possible overlay implementations, and frankly, when there are already two modules implemented for the same complex task, why would we start from scratch?

The goals for the core overlay (purposely not called a modal dialog) is to take up most of the window with a dim background on the original page content. The overlay would have a close button on its right side and possibly tabs on top to switch to different subpages (loaded via Ajax or will already be on the same page, but hidden). We don't need the overlay to be moveable or resizable. We don't need to show multiples at once, since it only makes sense to show one. However, the overlay should work well with the header so that when an option is selected, it keeps being active in the header, and the header should work so one can pick another area to work on without first closing the overlay.

This is how the overlay would look:

With different tabs or without tabs but otherwise consistent look elsewhere:

For easier evaluation of how we can meet these goals, I've ported both above mentioned modules to Drupal 7 and implemented Drupal 7 user experience "skins" for them. In the case of Popups module, it was a skin which the module already supports via an internal API, with Modal Frame API, it was an actual glue module which mapped elements marked up for being displayed in the overlay to a style similar to what Mark and Leisa suggests. Neither of them is pixel perfect to what is to be done, but the initial goal was to have D7 versions to evaluate and discuss the implementation internals, so we can fix up styling once we picked either one or a third way.

You can find my Popups module port patch at http://drupal.org/node/466732#comment-1681554 and the Modal Frame API port patch at http://drupal.org/node/491224#comment-1703366 but to make all these easier to test with the D7UX header in progress, all this code is available with the glue modules and custom skins in the D7UX code repository. You can try out both by installing with the d7ux install profile and then either turning on the "Popups API" module or the "D7UX overlay look" module. Make sure to only have one of them enabled at once and let Drupal install their dependencies. Switch between the two implementations by switching between the two modules.

Overlay implemented via popus module:

Overlay implemented via modal frame API module (the close button is not yet themed to look like on the mockups, but think of that as a minor detail):

Let's go beyond the UI and compare the modules:

  Popups API Modal Frame API
Started December 2007 May 2009
Maintainer starbow: http://drupal.org/user/33290 markus_petrux: http://drupal.org/user/39593
Contents Popups API, popups admin (admin mapper) and popups test modules (for human testing), skins Modal Frame API, Example glue module for testing
Based on Lots of custom code based on jQuery Small amount of custom code based on jQuery UI and jQuery
Codebase Light on PHP code, heavy on JS Light on both PHP and JS code, jQuery UI makes up for it
Overlay rendering Ajax request for a JSON object which contains the rendered content of the page, JS and CSS files to be loaded for the page and Drupal messages Ajax request for a fully rendered HTML page which is themed by the Modal Frame API module to only include the main region and some wrapper code.
Overlay display Merges rendered overlay into main HTML document; merges in CSS and JS files (possible ID collision) iframe element added to the page (no requirement for CSS and JS merging)
Stacked popups Supported, only one visible at a time Not supported
Dirty forms (unsaved edited form warnings) support Supported via custom code Supported via http://drupal.org/project/dirtyforms
Form submission in popups Reloads originating page (via Ajax or full reload) or runs custom callback Overrides form submit redirection and closes overlay

We are obviously at crossroads with picking our ways. The Popups module approach already has numerous core patches which were suggested earlier, while Modal Frame API leverages jQuery UI to lessen custom code burden and iframes to avoid colissions in merging HTML documents, which might be more attractive.

What did I miss in my comparison? Did I miss another alternative? What do you think a core solution should look like? jQuery UI to core? Just a targeted custom implementation for our own needs? IFrames or HTML merging? JSON output or overlay specific theming? These are general conceptual questions, so I choose to write a blog post to try and start a conversation instead of using the issue queue, which would be useful for more targeted questions. However, answers to some of the questions infer answers to others. What do you think?

Started a third party repository for the D7UX work

Seeing how Young Hahn, David Rothstein, Paul Lovvik, Charlie Gordon, Daniel F. Kudwien, myself and others work on parts of the Drupal 7 user experience implementation already, it is getting harder to apply all the patches, keep up with their development and get them integrated to work together with various efforts.

Starting to make some Drupal 7 UX concepts work

At Acquia, among other Drupal 7 UX improvements, we've been working making the overlays work as designed by Mark Boulton and Leisa Reichelt. The plan includes a header with two levels of fixed items, which all invoke overlays (almost full window popups), showing above the current page. Instead of reinventing the wheel, we started working towards porting the existing Popups module to Drupal 7 and implementing the Drupal 7 overlay looks via a skin, so we can leverage the existing work, testing and wisdom from the module.

Due to how hard JS is to debug still with Firebug, we faced some issues, but given that we are over those, we have the basic overlay looks ready and facing some other engineering problems which are pretty much standard with how the Popups module works. For integration purposes (and because our proof of concept version of the header did not look as good), we worked with Young Hahn's header patch. You can find my modifications to that to work with overlays on the issue. While Young's patch does not yet map to the D7UX plan to have a fixed set of top level items and a fixed set of lower level items, redefining the D7 admin information architecture, for working out the overlay, it is pretty good as it is now.

Since we were working on (a) porting Popups module to Drupal 7, (b) create a d7ux skin for it, (c) a header which we did not use in this experiment, and Young Hahn was working on a header which needs a patch and images added, I've decided to pull together a quick Drupal package for your testing pleasure. The distribution includes a D7UX install profile which should be used so that the proper modules are set up. It also includes the latest header patch from Young's issue (which has my popups class modifications) and the images and sprite from there. The ported Popups module and the D7UX skin for it is also included.

While I am searching for the best ways to collaborate on the overlay (and possibly also on the header), so we don't need to work back and forth in issue queues, possibly stepping on each other's toes, I am also sharing the D7UX Popups module theme as a separate package, so those fond of applying patches and adding up images from different sources can keep up with development.

There are some pretty significant known issues with the overlay/popups. The biggest one being that since the overlay page is loaded into the same DOM tree (same HTML document) as the rest of the page, ID collissions can easily apply. If you load up a node edit form on a page with a node edit form, #node-edit will appear twice. Behaviours rightly assume that an HTML ID will ever appear once, so they do not expect this situation. This breaks some behaviors. Also, since Popups modules opens new popups on clicking on new links without closing the previous ones, this can also happen if you open two node forms in the popup in a page view. There are also smaller styling problems (eg. overlays on lower layers move up a few pixels when new popups are opened), but we should focus on the significant issues first.

I am looking at breaking down the Popups module (again) to core patches so its parts can be included in core. That would assume that the basic working of it (loading up new HTML-particles into the same HTML document) can be made work without major issues. The great maintainer of Popups module, Tao Starbow worked on quite a few core patches, but unfortunately those got the fate of the overdebated. The issues were split up, then some of the individual pieces were discussed to be over-generalized and in other areas, the scope of Popups in core was narrowed considerably to some confirm forms. No doubt Tao got burnt out from there.

That was way before Mark and Leisa suggested using the overlay technique for the Drupal 7 administration UI. I hope we can revive and refocus some of the issues and get this effort going faster, so we can focus on usability of the actual admin screens showing up in the overlays. Rendering API, JS and CSS wizards welcome! Look for my upcoming blog post on a plan to get this into core!

Download the full Drupal package to test or download the d7ux-popups-skin only, if you are keen on applying all the patches yourself. Place the skin into the skins directory of Popups module.