When create a node with widget "Addnode List", all of the option links on the add page are disabled. I mean the option links in the form, such as "Input format", "Comment settings", "Authoring information" and "Publishing options".

Comments

colesidhu’s picture

I had exactly the same issue, but noticed the following:

Say node type "A" (the parent node type) contains an Addnode List of type "B". The problem that appeared with this module was that all the option links in node class "A" somehow became disabled (i.e. the option links were no longer "clickable", although the text for the option title still appeared). But I noticed that type "B" also had an option link ("File Attachment" in my case), which had also become disabled. When I completely removed the "File Attachment" option from type "B" and tried it again, then all the option links in type "A" became enabled again.

Anyways I'm not sure of the issue, but it might have to do with using Addnode List types that have option fields? I'm sorry for this confusing post, I just started using Drupal 2 weeks ago and I'm still trying to get the hang of all the lingo!

astra’s picture

Title: Bug, Addnode » Bugs between Addnode and Upload modules?

I had a test and got the same problem from and ONLY from the "File attachment" option link.

For my reference node there are 3 extra option links:
"File attachment" from the module Upload;
"Attached Images" from the module Image_attach;
"Theme" from the module Taxonomy_theme.

Only when the "File attachment" option has been activated from the reference node type, all the option links in the parent node and the reference node become disable. But for the other two extra options ("Attached Images" and "Theme") no matter they are activated or not, the addnode list works well without problems about the option links.

I think the module Addnode should support any option links in the addnode list of a reference node.

Is there a bug between Addnode and Upload modules?

Lionfish’s picture

Causes of the Problem

Generally it's caused by a java script error that's causing the browser to give up dealing with the java script.
What's causing the error?

Trace through the javascript

  • "button has no properties" in drupal.js's function redirectFormButton.
  • This is called (and passed 'button') from jsUpload in upload.js
  • This is called (and passed 'button') from uploadAutoAttach in upload.js

Here's the function:

Drupal.uploadAutoAttach = function() {
  $('input.upload').each(function () {
    var uri = this.value;
    // Extract the base name from the id (edit-attach-url -> attach).
    var base = this.id.substring(5, this.id.length - 4);
    alert(base);
    var button = base + '-button';
    var wrapper = base + '-wrapper';
    var hide = base + '-hide';
    var upload = new Drupal.jsUpload(uri, button, wrapper, hide);
  });
}

There's two causes:

Buttons are removed

The current actual cause is that my module (rather brutally) removes all buttons:

function _add_subform(&$form, $subform, $fieldname, $type, $subprefix, $subsuffix, $weight)
  foreach ($subform as $field => $fieldarray)
  {
    if (is_array($fieldarray))
    {
      if (($fieldarray['#type']=='button') || ($fieldarray['#type']=='submit'))
      {
        unset($subform[$field]);
      }
    }
  }
....

Obviously if there's no buttons then the jquery can't find them. Not very pretty. I can obviously improve this, but the more general problem is what happens when the Upload button is pressed. Even on 'normal' pages I find I get given validation errors, when all I want to do is add a file - even if I've not finished filling in the form.

Names aren't changed correctly

Even if I do add the buttons back, there's problems with names:
In the example I'm testing, the subform is of type 'page' and is in the field 'pages-associated'. This means I add on the prefix "field_pages_associated" to lots of the names and ids. It seems that the uploadAutoAttach function uses button with class='upload' to get the base name:

$('input.upload').each(function () {
    var base = this.id.substring(5, this.id.length - 4);

It then uses it to get the id of the button:

var button = base + '-button';

But for some reason the id of the upload button is set to: edit-field-pages-associated-page-attachments-wrapper-attach-url
So base is set to: field-pages-associated-page-attachments-wrapper-attach
but the button has is: field_pages_associated_attach-button
The "-page-attachments-wrapper-" is added becuase of the way drupal makes the form. It is to do with the value of #tree. http://drupal.org/node/48643 explains it in more detail.

How to fix it

Okay, I'll ignore the problem of what to do about submitting the form from the subform by clicking on the 'upload' button for the moment, and concentrate on the name conflict. With a bit more work, I think I can get it sorted out. I had a look at fago's new subform element module to see how he handles it. Unfortunately he's not dealt with the problem either.

Notes, Problems
---------------
Currently I'm aware of one possible problem with subforms. The values of each
form will be transmitted as usual in the $_POST array. So if both forms use a field with
the same name, e.g. 'title' both will end up in $_POST['edit']['title'], so obviously the
latter title will overwrite the first one.
So for now you have to care yourself, that there are no overlapping form names.

from API.txt (from 5.x-1.x-dev 2007-Mar-30)

Summary

I'll fix this bug, but I think this name-space problem is going to rear its head again.

Thanks everyone for testing and helping with this module!

Lionfish’s picture

I currently have #tree enabled for each subform, so there's a handy array tree structure I just pluck the subform from. Having a tree structure however breaks bits of the subform that need names to not change (hence the bug above). So I disabled #tree. And have fixed the code that renames the fields. Oddly though, chunks of the form array (http://drupal.pastebin.co.uk/12432) don't seem to come out in the form values array (http://drupal.pastebin.co.uk/12434). (I maybe need to check to see what page comes out with...)
Update: It seems node_forms are 'spechul' and do something weird with their form_values... need to figure that too.

I also need to write code that extracts the subform using the names, and renames them back to their real names (maybe), before sending them to drupal_execute.

Lionfish’s picture

Version: 5.x-1.0 » 5.x-1.1
Status: Active » Fixed

Fixed in version 1.1.
I've roughly tested this and it seems to work, but I've not tried uploading anything in Internet Explorer (if anyone wants to test)...

Anonymous’s picture

Status: Fixed » Closed (fixed)