Support » Plugins » [Plugin: Custom Post Type UI] Version 0.4.1 partially working with WP3 Beta 1

  • Matt Hill


    Latest version of Custom Post Type UI is partially working work with my fresh install of WordPress 3 Beta 1.

    Although I can use the “Add New” option, if I try to edit a Post Type using “Manage Post Types”, I receive this error:

    Warning: call_user_func_array() []: First argument is expected to be a valid callback, 'cpt_manage_cpt' was given in F:\Projects\wp3beta\wp-includes\plugin.php on line 395

    Any ideas?

Viewing 15 replies - 16 through 30 (of 37 total)
  • gambit37,
    If you just put your cursor on “Manage Post Types”, you should be seeing the following at the bottom of your page:

    “/** your path **/wp-admin/admin.php?page=custom-post-type-ui/custom-post-type-ui.php_cpt_manage_cpt “

    Is that what you are seeing?

    The error is saying that it cannot find “cpt_manage_cpt” which is the function it needs.

    If you are not seeing the path that I typed, then try entering it yourself and see what you get. Type in your path and then you can paste or type the rest.

    Also, you said that you could use the “Add New” for custom types. If that worked then you should be seeing your metaboxes in the left side of the admin screen, i.e. movies, or whatever the name of your custom type was. If you don’t see the metabox for your custom post type, then it was never created and “Add New” is not working.


    Hi Ron, the link you asked for is:


    Doesn’t matter if I paste this manually into the browser bar, same error is generated.

    I do indeed have new Metaboxes in my left hand menu and can create and edit new posts under that category (‘Portfolio’ in this case).

    Hi gambit37, I’ve got a couple of questions.

    Have you tried just setting your permalinks to the default? That might
    help if there is a problem with the path.

    Have you looked at your site path in phpMyAdmin? Browse wp_options. The Option Name should say “siteurl” and the value should be “http://local/wp3beta”. There should be no trailing slash. Is that what you get?
    BTW, why aren’t you using “localhost” instead of “local”?

    My next suggestion, (if those don’t work), would be to include some code at certain points to see how far you get before it fails. (And to give a backtrace to track down the problem.)

    You’re not the only one having this problem, so there must be something that you all have in common.


    Hi Ron

    Using default permalinks actually creates a browser error screen, not even a themed 404.

    The site path is stored in wp_options correctly.

    I use “local.nameofproject” as my own convention for domains on my local machine. Always works fine.

    Your last suggestion is a bit beyond me — I’m a designer/front-end guy — where would I insert this code? I think you mean I should edit the CPT UI plugin code? I’d be happy to work with the author (williamsba1) to troubleshoot this but he can’t replicate this problem, so I guess we’re stuck?


    Hi gambit37,

    The code is:

    if ( is_wp_error($the_['function'] ) ) {
      var_dump( debug_backtrace() );

    I would put it on the line right after the point where you are having the error, i.e. line 396 in wp-includes\plugin.php.

    Naturally, if there is an error there, the code will stop executing and y9ou should have a backtrace. I would copy this out somewhere so it can be examined, and so you can paste it in the forum.

    I can’t reproduce the error myself. But somehow I have no problem getting constant errors in the new menu system. (Which is not ready for primetime in my opinion.)

    BTW, I noticed in the WordPress trac that they are working on some tickets that could pertain to your problem. (And also several tickets on the menu system, which could solve my problem.)

    Let me know what you find out.


    I tried your suggestion but no extra info is output. Do you know where I find this ‘backtrace’? Should it be output in the HTML?

    Did you get the warning when you clicked on “Manage Post Types”?

    Yes, it would have been output in the HTML.

    Yes, the original PHP error warning is still output, but no extra backtrace info is output.


    Ok. Try this. Just list the following line right after the
    call_user_func_array line. That will probably be around line 396:

    var_dump( debug_backtrace() );

    This will definitely dump a lot of output.

    Click on “Manage Post Types” just as you did before and then I would save the whole screen of output to a text file so that you can refer to it later.

    BTW, this is not going to be in html format. (I think I misunderstood what you were asking before.) These are the instructions generated starting from call_user_func_array and working backwards, but it will give us the info we need to see where the problem is. (Hopefully!)

    We’re actually looking for the call which has “cpt_manage_cpt” as part of the path.


    I’ll have to come back to you on this as I’ve ditched the plugin for now and have hand coded my custom posts stuff. Gotta get this project out the door! 🙂

    I’ve also been getting similar errors using another plugin, Verve Meta Boxes. When I reported it to the author, he fixed it: “Modified code to work in environments that utilize PHP strict.”

    So I wonder if Custom Post Types GUI also needs to be modified to work with PHP strict?

    So I wonder if Custom Post Types GUI also needs to be modified to work with PHP strict?

    Good question! I just read where some major changes have been made to custom post types and taxonomies. They are advising plugin authors to recheck their code.

    I think Brad will probably be checking the Custom Post Types UI plugin to see what changes are needed. Maybe he can check for the PHP strict at that time.


    Warning: call_user_func_array() expects parameter 1 to be a valid callback, function ‘cpt_manage_cpt’ not found or invalid function name in C:\wamp\www\wp-includes\plugin.php on line 395

    Im getting the same problem, is there a fix coming any time soon??

    I’m getting the same problem.
    on php 5.3.2

    I soloved this problem ,
    when I change the position of function “cpt_manage_cpt” and “cpt_manage_taxonomies” after “function curPageURL”.

    Melodian are you saying you physically moved the function curPageURL above cpt_manage_cpt and cpt_manage_taxonomies and that solved the issue? I’m working on resolving this bug for v0.6.1

Viewing 15 replies - 16 through 30 (of 37 total)
  • The topic ‘[Plugin: Custom Post Type UI] Version 0.4.1 partially working with WP3 Beta 1’ is closed to new replies.