CCK modules can't save data!!!

I've learned a little more about this.

It would seem that the cck hook_widget is not firing for the submit case, which of course explains why nothing is saved.

Any ideas why hook_widget isn't firing from the pageroute version of the content type?

Might not having a body have anything to do with it? I wouldn't think so.

Nevermind about the lack of a body being a possibility. Doesn't look like that is it. Not sure what made me think so. Silly.

Perhaps subform elements is the problem? I'm having trouble following all of the interactions.

One more clue: CCK's own content_nodeapi function is not firing for the submit case. The 'prepare' and 'validate' cases fire, but that's it. Is one of your module intercepting this? At present, I don't have a debugger that will allow me to step through functions and see what is coming after the validation call and preventing the submit call.

Help!!!

It seems the same problem exists for the cck phone field; it is unable to save the data though it validates and gets through the widget function's 'process form values' stage. The widget function's 'submit' stage is never firing.

I have two phone fields on the nodeprofile page, but not as 'multiple' values of one field.

If I didn't mention this elsewhere, the saving problem only occurs when editing the node directly, outside of the pageroute.

An example URL would be:
user/7/edit/139 -- BROKEN
somepageroute/139/7 -- WORKS

some related comments: http://drupal.org/node/181887

As mentioned on the other issue, this is for my module which allows multiple membership types, each with its own pageroute. Each pageroute can have both unique pages and pages shared with other routes. For this reason, I was unable to use your nodeprofile integration in the user edit area of the user account as all nodeprofiles get listed, not just those of the pageroute that belongs to the user's membership type.

So instead, I basically copied your functions into my module and modified them. But since the links to the nodes are the same, and I'm not doing anything on nodes themselves, I figured that the problem would be universal - i.e. whether one used my module or not, but tried to edit the node directly outside of a pageroute, the content wouldn't save. But perhaps that's not the case.

As mentioned above, I first thought it was only a problem with one field not saving, but that's because I was working on a node type that only had one field. I later thought that newly filled in fields weren't being saved, but changing content or deleting it from fields also would not save.

So perhaps I didn't implement my tabs the same way you did and there is something wrong in them alone. Originally, my tabs on the user edit page looked like this:

 if (arg(0) == 'user' && arg(2) == 'edit') {
      $edit_user = user_load(array('uid' => arg(1)));
      $membership_type = $edit_user->mem_choice;
      $mem_pageroutes = _nf_registration_mod_get_added();
      $all_routes = _nf_registration_mod_get_pageroutes();
      $all_pages = _nf_registration_mod_get_pageroute_pages();
      $user_route = $all_routes[$mem_pageroutes[$membership_type]];
      $user_pages = $all_pages[$mem_pageroutes[$membership_type]];
      $sql = "SELECT nid FROM {node} WHERE uid = %d AND type = '%s'";
      $weight = -10;
      foreach ($user_pages as $name => $type) {
        if ($result = db_fetch_object(db_query($sql, arg(1), $type))) {
          $path = $user_route .'/'. $result->nid .'/'. arg(1);
        }
        else {
          $path = $user_route .'/0/'. arg(1);
        }
        $items[] = array(
        'path' => 'user/'. arg(1) .'/edit/'. $type,
        'title' => t($name),
        'callback' => 'drupal_goto',
        'callback arguments' => array($path, 'destination=user/'. arg(1) .'/edit'),
        'access' => user_access('edit own '. $type .' content'),
        'type' => MENU_LOCAL_TASK,
        'weight' => $weight,
        );
        $weight++;
      }
    } 

You can see that this finds out the user's membership type, the associated pageroute, the pages that go with that pageroute, and then creates a menu tab for each which links directly to the nodes. I don't recall what your module does for its tabs on the user edit page. I would imagine that I tried to copy yours and only change the lookup of the pages.

My new menu items look like this:

 if (arg(0) == 'user' && arg(2) == 'edit') {
      $edit_user = user_load(array('uid' => arg(1)));
      $membership_type = $edit_user->mem_choice;
      $mem_pageroutes = _nf_registration_mod_get_added();
      $all_routes = _nf_registration_mod_get_pageroutes();
      $all_pages = _nf_registration_mod_get_pageroute_pages();
      $user_route = $all_routes[$mem_pageroutes[$membership_type]];
      $user_pages = $all_pages[$mem_pageroutes[$membership_type]];
      $sql = "SELECT nid FROM {node} WHERE uid = %d AND type = '%s'";
      $weight = -10;
      $path = $user_route .'/0/'. arg(1);
      $items[] = array(
        'path' => 'user/'. arg(1) .'/edit/pageroute',
        'title' => t('Personal data'),
        'callback' => 'drupal_goto',
        'callback arguments' => array($path, 'destination=user/'. arg(1) .'/edit'),
        'access' => $admin_access || $user_access,
        'type' => MENU_LOCAL_TASK,
        'weight' => $weight,
        );
      $items[] = array(
        'path' => 'user/'. arg(1) .'/edit/settings',
        'title' => t('General settings'),
        'access' => $admin_access || $user_access,
        'type' => MENU_DEFAULT_LOCAL_TASK,
        'weight' => -20,
        );
    }

Essentially, since linking to the nodes directly wasn't allowing the nodes to be edited (note comment #5 above - my module fires after, so mine shouldn't be getting in the way), I got rid of the page links in favor of a single link to the pageroute and another one as a default link to user's main edit page [for some reason, simply adding the user/arg(1)/edit/pageroute menu item wouldn't get the default "account settings" tab to show up]. The other issue I cited as a link above is how users get out of the pageroute and back to their user account's edit page.

SO - although I have this all working now, it is very inelegant. I am wondering if you might be interested in working together toward tighter integration of our respective modules and in solving some of the issues I've had lately. I think multiple user membership types is a valuable feature to have and pageroutes are a good way of collecting varied information from members of each type. Perhaps if you looked at my module's code, you'd have some novel insights that both your modules and mine could benefit from.