Fieldgroup Missing argument 1 and call_user_func_array()

I have the same problem too guys. Let me know what information I can offer to help resolve this.

I'm raising this to critical, since it is making it unusable, and therefore shouldn't be used on a live site.

I have absolutely no clue about what might be causing this.

@ifoundthetao : 'I have the same problem' is not enough. Provide exact symptoms. Also, sentinelcz writes
"I created 7 groups without problem.
I cant create 8 th group in CCK."
Did you experience something similar ?

What are the other modules enabled on your site ?
Try disabling all of them (except cck modules) and see if the problem persists?

I have disabled all other modules and the problem persists.

Here are the modules I have installed:
Front Page

CCK
--Email
--Content Copy
--Content Permissions
--Fieldgroup
--Link
--Number
--Option Widgets
--Text

Core Optional
--Color
--Comment
--Database Logging
--Help
--Menu
--Path
--PHP Filter
--Profile
--Search
--Statistics
--Taxonomy
--Update Status

Date/Time
--Date
--Date API
--Date Copy
--Date Timezone

Quota By Role
Taxonomy Access Control

As far as the problem goes, I have a content type with four (4) fieldgroups and sixty-eight (68) fields, and I cannot add any new fieldgroups.

I don't know when this happened, I think it was after I upgraded from 6.3 to 6.4 and updated CCK. I first noticed this on 8/18/08.

I can create new content types with new fieldgroups. I have created 11 in one group without any errors.

Let me know what else I can do to test further.

Marked #300009: error in creating groups more than 10? as duplicate.

I had my original post here http://drupal.org/node/300009 I created another content type, first added all groups (about 20) and then fields. Unfortunately i didnt order the fields, now when i save after reordering, it remains same!. Now i cannot add any more groups. Could it be a php memory problem? i got many fatal error message on memory allocation while adding fields.

Well unfortunately this is a real bug. :(

I believe it's related to the size of the page arguments that are being saved for the fieldgroup menu items.

The second item in the page arguments is $content_type, which can be a *very* large array for a complex content type, and is saved with each menu item in {menu_router} to be un-serialized later. Thus the problem isn't tied to a certain # of fieldgroups, but rather the complexity of the content type. (Which usually means more fieldgroups :) )

That said, I've traced it back a bit and found were things diverge in core's menu.inc:

in menu_get_item() there is a section:

        $router_item['page_arguments'] = array_merge(menu_unserialize($router_item['page_arguments'], $map), array_slice($map, $router_item['number_parts']));

where this part of the merge:

menu_unserialize($router_item['page_arguments'], $map)

comes back empty for large content types.

Really, after looking at it, it's also adding some serious bloat to the menu router system. :/

So I guess the first question is, can't we just look up the necessary content type information during callback after the menu system as already done it's job? That would certainly keep it out of harms way and let the menu system breath easier.

Doh. Indeed, that's not right.
I committed a fix to store only the type name in the menu definition. (this was already the case in content_menu() for field paths)
Can you guys check this fixes it ? (You'll need to rebuild the menus, obviously - can be done just by visiting admin/build/modules, no need to submit the form)

Moonshine, many thanks for the investigation !

@Sentinelcz

Basically you'll need to either download the latest CCK via CVS, or wait for the dev tarball to update itself here at:

http://drupal.org/node/266142

It shouldn't be too long, but the one at "September 1, 2008 - 06:01" is before Yched's updates. After you have it in place you'll need to make sure Drupal's menus are rebuild, either via Yched's method above, or clearing your entire cache in Admin/Performance.

@Yched

Thanks for the quick turn around :) Will test here later this morning.

Good fix!

I forgot to update content_copy with the new form arguments, this broke group exports.
Fixed now.