Allow modules to directly affect mm_show_page()'s call to _mm_render_pages()

Sure! Here's what we're doing in mm_panels.module (we haven't committed this change to the github copy yet, pending resolution of this issue).

/**
 * Implements hook_mm_showpage_prerender().
 */
function mm_panels_mm_showpage_prerender(&$mmtids, &$oarg_list, &$err) {
  $panelized = &drupal_static('mm_panels_page', FALSE);
  $this_mmtid = end($mmtids);
  reset($mmtids);
  // If "Panelize this page" is checked set $panelized to $mmtids.
  // In theory, $oarg_list is only NON-empty when there are unresolved path
  // components after $this_mmtid in the URL (ultimately, a 404).
  if (empty($oarg_list) && _mm_panels_get_current_status($this_mmtid)) {
    $panelized = $mmtids;
    // Stop anything else from being rendered.
    $mmtids = array(1);
  }
}

/**
 * Implements hook_mm_showpage_postrender().
 */
function mm_panels_mm_showpage_postrender(&$mmtids, &$oarg_list, &$err, &$output) {
  $panelized = &drupal_static('mm_panels_page', FALSE);
  if (!empty($panelized)) {
    $this_mmtid = end($panelized);
    reset($mmtids);
    $err = '';
    $output = mm_panels_page($this_mmtid);
  }
}

Basically, all we need is a pair of preprocess and process hooks, to let mm_show_page() still run, but:

1. change the MMTIDs that are rendered more granularly than hook_mm_showpage_router() allows
2. alter the $content post-_mm_render_pages() execution

I ran a bunch of tests with '%' in July 2013, and for some reason it didn't work right; I should have taken better notes. Maybe I forgot to set partial path (boy, would that be embarrassing). Since I don't have total recall of whatever the issue was, I'll try it again in a moment. Tracing through _mm_render_pages() and _mm_showpage_router() now, it definitely looks like it should work, and registering a partial path of "%" should end up with a REGEXP like ^[^/]+(?:$|/), which pretty much matches any mm/$this_mmtid path.

As for multiple callbacks per path, that's mostly future-proofing. If, for example, mm_panels.module registers the '%' path, then that means absolutely no other module could try to do a similar thing (where that similar thing is to conditionally affect the rendering of an arbitrary MM page anywhere in the tree).

Well, one thing is after mm_module_invoke_all_array('url_outbound_alter', array(&$temp_path, &$temp_options, $temp_path)); is called, $temp_path is empty on the homepage, so the REGEXP doesn't match.

Should str_replace('%', '[^/]+', preg_quote($path)) be changed to str_replace('%', '[^/]*', preg_quote($path))? Either % could match zero or more characters (which isn't consistent with hook_menu paths), or we could implement Drupal-like behavior and allow for the "*" wildcard:

function _mm_showpage_router($reset = FALSE) {
  // ...
        $path = '{^' . str_replace(array('%', '\\*'), array('[^/]+', '[^/]*'), preg_quote($path)) . $ending;

Edit to add: Note, you need the "\\" in the str_replace() call because preg_quote() turns "*" into "\*".

With the attached patch (allowing the "*" wildcard), I got mm_panels.module working with these functions:

function mm_panels_mm_showpage_routing() {
  return array(
    '*' => array(
      'page callback' => 'mm_panels_showpage_callback',
      'page arguments' => array('_mmtid_', '_all_'),
      'partial path' => TRUE,
    ),
  );
}
function mm_panels_showpage_callback() {
  $args = func_get_args();
  $this_mmtid = array_shift($args);
  $correct_page = FALSE;
  if ($page = mm_content_get($this_mmtid)) {
    $correct_page = end($args) === $page->alias;
  }
  if ($correct_page && _mm_panels_get_current_status($this_mmtid)) {
    return array(
      'no_nodes' => TRUE,
      'output_post' => mm_panels_page($this_mmtid),
    );
  }
}

Oops, entirely my fault: I realized it wouldn't be obvious so I edited #6 to add the note about why "\\*" is necessary, but Drupal doesn't email out updates to existing comments (thankfully, most of the time). Since the str_replace() happens after preg_quote(), the string(1) "*" has already been turned into string(2) "\*", so you've got to str_replace() the asterisk along with its backslash.

I'd love your expert opinion on the best thing to do for determining $correct_page. Since the callback gets as its arguments an array of aliases, it's impossible to tell where the real path ends and the joined $oargs_list begins without either a) running mm_parse_args() and comparing $this_mmtid, or b) getting the alias of the current page and checking the path to make sure it's the last item (though as you point out, there might be a collision there).

Here's a version of mm_panels.module that goes the mm_parse_args() route, which at least won't ever accidentally render the panel just because the last $oarg happens to match. I don't really know if mm_parse_args() is too heavy a function to use on every page hit, but this should work (as long as nobody ever wants an MM block to also be Panelized):

function mm_panels_mm_showpage_routing() {
  return array(
    '*' => array(
      'page callback' => 'mm_panels_showpage_callback',
      'page arguments' => array('_mmtid_'),
      'partial path' => TRUE,
    ),
  );
}
function mm_panels_showpage_callback($matched_mmtid) {
  $prefix = mm_parse_args($mmtids, $oarg_list, $this_mmtid);
  $correct_page = $matched_mmtid === $this_mmtid && empty($oarg_list);
  if ($correct_page && _mm_panels_get_current_status($this_mmtid)) {
    return array(
      'no_nodes' => TRUE,
      'output_post' => mm_panels_page($this_mmtid),
    );
  }
}

Come to think of it, mm_parse_args() is always called by mm_show_page() anyway, right? So if we cached the result from that call per-$url parameter, then it really wouldn't be any extra hit. Do you think that's a possibility? If so, I'd be happy to roll the patch for that as well. I know we call mm_parse_args() in other modules too, so it'd be nice to speed that up as much as possible.

That looks great to me!