Proposal: allow customized paths (URLs) for node reference URL widget (e.g. to use a create content form as Panels pane)

2nd trial for adding my patch

Now it seems that my patch is visible in #2.

@quicksketch:
Thank you for your answer.

I read about the ?[name]=[nid] syntax, but I couldn't bring it to work (with my 6.x-1.3 version). What should [name] be filled with?
I checked .module code and I can't find the place where this additional syntax will be handled.

/**
 * Implementation of hook_widget().
 */
function nodereference_url_widget(&$form, &$form_state, $field, $items, $delta = 0) {
  $element = array('#tree' => TRUE);

  // Check for an existing NID or pull it from the URL.
  if (isset($items[0]['nid']) && is_numeric($items[0]['nid'])) {
    $referenced_nid = $items[0]['nid'];
  }
  elseif (arg(0) == 'node' && arg(1) == 'add') {
    $referenced_nid = is_numeric(arg(3)) ? arg(3) : NULL;
  }
...

My solution is working (at least for me :)
And I found an old issue (http://drupal.org/node/492980) which could be solved with my patch - so I am not the only person that needs such a feature...

I think that there is a misunderstanding of my intention writing this patch. I'll try to describe it better:

I don't want to override my node forms with panels.
I want to use panel pages with an arbitrary path that may contain (beside other panel panes) one or more panel panes for creating new (and possibly different) content types.
So: one Panels page (e.g. path 'node/%nid/my-custom-panel-page', where %nid is the node ID of my content type C, which should be the reference for other content types A and B) --> panel pane A contains the node add form for content type A (which should be refernced with %nid of content type C) + panel pane B contains the node add form for content type B (which should be refernced with %nid of content type C, too)
In such cases your proposal doesn't work, because I can't give my panel page 2 different paths 'node/add/B/%nid' and 'node/add/C/%nid'. Or am I wrong?

And Yes, you are right. The existing mechanism won't work for my use-case.
That is the reason why my patch #2 adds the following elseif under the original code posted in #3:

...
  // Handle custom paths.
  elseif (isset($field['widget']['custom_urls']) && drupal_strlen($field['widget']['custom_urls'])) {
    $custom_urls = explode("\n", $field['widget']['custom_urls']);
    $current_path = $_GET['q'];
    if (drupal_strlen($current_path)) {
      foreach ($custom_urls as $path) {
        $path = trim($path); // Delete whitespaces.
        if (!drupal_strlen($path)) {
          continue;
        }
        // '/^node\/([0-9]+)\/[a-zA-Z_\-0-9]+\/add$/' will find 'node/%nid/%/add'
        $path = '/^'. str_replace('/', '\/', $path) .'$/'; // Replace slashes and add start and end delimiter.
        $path = str_replace('%nid', '([0-9]+)', $path); // Replace %nid.
        $path = str_replace('%', '[a-zA-Z_\-0-9]+', $path); // Replace other wildcards (%).
        $matches = array();
        if (preg_match($path, $current_path, $matches)) {
          $referenced_nid = ((isset($matches[1]) && is_numeric($matches[1])) ? $matches[1] : NULL);
          break;
        }
      }
    }
  }

And // '/^node\/([0-9]+)\/[a-zA-Z_\-0-9]+\/add$/' will find 'node/%nid/%/add' is only an example that I used to test my regular expression.

The other parts of my patch are quite easy:
- usage demonstration with hook_menu (must be uncommented to work and shouldn't go into Node Reference URL Widget code)
- adding a textarea in the options section
- storing its value
- validate handler for this textarea
- and the piece of code above (which does the work)

If you (or other community members) don't like this patch, than it is fine for me. It is only an attempt to give something back to this great Drupal community. And in my opinion it is a good relation between 'additional code' and 'extended functionality' - but this is only my opinion.

Hi Phil,

I don't know Form Block in detail.
As far as I can see you don't have to modify the hook_menu example in the patch, because by using Form Block you already see your node add/edit form at a path differing from standard path (node/add/...).

To make this patch solving your problem, you must figure out where you can find the reference node ID in your path (with the Form Block node add/edit form).
e.g. 'my-path-with-node-add-form/page/3' --> then add as search pattern in nodereference field settings: 'my-path-with-node-add-form/page/%nid'

If you need further help, please describe your problem in more detail (including your path values and their meaning and maybe a screenshot).

After reading your first post (about Form Block), I tried it by myself and it worked for me.

Maybe your problem is that ~/abstracts/[user]/22 is an URL alias and not a system path. You said that entering this path gives you the identical output like visiting node/22.

Please try to use node/%nid as pattern in nodereference field settings section. That should work...

My patch was designed for system paths (and not URL aliases). Maybe this could be a further improvement, but I don't know if it is easy to realize.

And beside you nobody is interested in this patch :-(

Good luck :-)

@gunzip:
Have you tried my patch?
It should work in your use case.

My solution is easier than writing PHP code to get the default value. By the way: you can use original node reference CCK field if you want to use custom PHP code. Node Reference URL Widget is intended to get this 'default value' from URL...

@quicksketch:
I don't understand what you mean with your sentence in #12

I definitely won't be adding a PHP field for custom code.

My patch (#2) introduced an additional settings form field (which could be placed in a collapsed fieldset...), but it is NO place for custom PHP code. It is a place to put patterns (like your patterns in $conf['nodereference_url_paths']) for "simple" Drupal users who are not familiar with editing their settings.php file.

But in my opinion your commited patch (#12) is a way to solve this issue.

I have one suggestion for further improvement of your patch (where I have developers in mind).
There are 2 places where you call variable_get('nodereference_url_paths', array('node/add/%type/%nid')):

$link_urls = variable_get('nodereference_url_paths', array('node/add/%type/%nid'));
...
$add_urls = variable_get('nodereference_url_paths', array('node/add/%type/%nid'));

What about calling a helper function instead, which gives other modules a chance to hook into the 'nodereference_url_paths' array?

Should I open a new issue for that? Do you need further explanation what I mean? The helper function should return the content of $conf['nodereference_url_paths'] + added array elements which can be provided by other (custom) modules.
Without such an opportunity I have to use hook_install to place my own 'nodereference_url_paths' elements into $conf['nodereference_url_paths'] by writing such nasty things like:

$add_urls = variable_get('nodereference_url_paths', array('node/add/%type/%nid'));
$add_urls[] = 'path/to/my/panels/node/%nid';
variable_set('nodereference_url_paths', $add_urls);

without a way of cleaning it safely with hook_uninstall (because I don't know the paths that were added by other modules in a similar manner) AND with the risk that an entry in settings.php will override my settings.

If each module would make use of settings.php to set variables this file would be a mess...

Please don't misunderstand me: I'm not a native English speaker and I'm only interested in a good solution which helps the Drupal community (including you and me :).

Thanks,
Martin

@gunzip:
You can try the new 1.4 release of Node Reference URL widget. It should work in your use case. There are configuration instructions in README.TXT.