See #1420534: Consider a new hook - hook_ctools_automodal_paths() rather than using hook_menu() #4.

These patches (especially #1420534: Consider a new hook - hook_ctools_automodal_paths() rather than using hook_menu()) drastically change the way this module works. It seems like the best path forward would be to create a 2.x branch with these modifications so we can keep the development on d.o., rather than forking projects on github.

I created a fork with a fix for #1422002: How do I use with a node form? at that I believe has all the latest code.


acouch’s picture

+1 for this. Would be great to get that code created by wojtha on D.O.

Perhaps we could make him a maintainer of this module?

jlyon’s picture

I just updated my fork of wojth's github fork at

Additional features:

  • Fully-baked support for node/add, node/%/edit pages
  • Additional 'redirect' parameter options for hook_modal_paths() calls:
    • "modal": hijacks a $form_state['redirect'] redirect to open the redirected page in a new window
    • FALSE: Ignores and $form_state['redirect'] values.
  • A new parameter commands_callback, which lets you include a function that returns a custom $commands array (for updating only a portion of the page, or making any other Drupal 7 AJAX calls
wojtha’s picture

Nice :-)

nicholas.alipaz’s picture

It may be best to follow the steps in if you would like to become a maintainer.

jlyon’s picture

Dave Reid’s picture

As I stated in I would not be opposed to moving to the new hook with backwards-compatibility in 7.x-1.x and not needing a new branch. Other than that I haven't really seen any big reason why we need a new branch?

acouch’s picture

The reason for the branch is that the updated module is three times as large in the .module file, contains an example module as well as an api.php file:

It would be extremely tedious to merge each feature of the updated module into this project. Creating a new branch would allow you to continue to maintain what is there as well as have a branch with the new features.

Alternatively we could copy the entire updated updated module into the 7.x-1.x branch. Would that be a better alternative Dave Reid?

jlyon’s picture

I agree with most of acouch's points that the api for the "2.x branch" is entirely different, which is what I thought initally that a new branch made the most sense. hook_modal_paths() and hook_modal_styles() don't even exist in 7.x-1.1.

@Dave Reid, I can understand your desire not to create too many branches, as well. If we want to go ahead with merging everything into the current branch, I will focus my efforts on that. It doesn't seem like it will be too difficult, although it seems like there might be some issues turning off the automatic AJAX form submission in modals the the "2.x branch" sets up by default.

wojtha’s picture

I also think that 2.x version would make more sense. It is a kind of different module now with extended API and much more powerful.

But in any case we need to support the 1.x way of modal window registration - legacy support or at least provide a update path for it.

capellic’s picture

Update please?

wzoom’s picture

I think, this is very useful module. Please make the version 2.x official so we can test it and push it forward.

fox_01’s picture

Issue summary: View changes

There are some great changes in 2.x.

Is there a new status about publishing it on drupal?

Renee S’s picture

I'd love a v.2 of this module. I also have some code for making it work with ECK if anybody is interested, just some minor tweaks in how the submit handler works. That's here:, note that I'm using ctools_automodal_admin to load all my paths, but, the general idea stands.