WordPress.org

Support

Support » Alpha/Beta » [Resolved] 3.1 RC3: Uppercase custom post type problems

[Resolved] 3.1 RC3: Uppercase custom post type problems

  • Hi All,

    In a theme I have created several months ago I have created a custom post type called “Portfolio” and now I am having problems with this with the 3.1 RC3.

    Now on some places within the theme this post type is not recognized as a valid post type, for example when adding new meta boxes to the post:

    add_meta_box( 'new-meta-post-boxes', 'Additional Settings', 'new_meta_post_boxes', 'Portfolio', 'normal', 'high' );

    the code above works fine with the previous versions, but with this version I have to insert ‘portfolio’ instead of ‘Portfolio’.

    I realize now that partly this might be my mistake, maybe because I got a bit confused of the documentation:

    $post_type
    (string) (required) Post type. (max. 20 characters)
    Default: None

    saying that the default post type is “None” with an uppercase letter.

    However the theme I have created is already used by lots of users and an update to the version 3.1 will break some of the theme functionality.
    Therefore I will be happy if this problem doesn’t exist in the 3.1 version or maybe if someone suggest a code change that can be done on one place only, rather having to edit the theme on all the places “Portfolio” is used.

    Thank you

Viewing 15 replies - 1 through 15 (of 21 total)
  • Use a slug, ie. lowercase and no spaces, the label and labels array are for dealing with display of the post type name(in capitalised and plural/non-plural forms), you shouldn’t be relying on the registered name for display purposes.

    http://codex.wordpress.org/Function_Reference/register_post_type

    See the label and labels parameter.

    In short, the name should be all lowercase and contain a hypen or underscore in place of spaces(if applicable to the given name).

    Thank you very much for the reply!

    I am aware of the slug usage and I have left this setting to default, and as the documentation says:

    ‘slug’ – prepend posts with this slug – defaults to post type’s name – use array(‘slug’=>$slug) to customize permastruct

    So I guess this means that the slug here is “Portfolio” (the same as the post type).

    To be more clear, here is the code used for registering the custom post type:

    register_post_type( 'Portfolio',
    		array( 'labels' => $labels,
    	         'public' => true,
    	         'capability_type' => 'post',
    	         'hierarchical' => false,
    	         'supports' => array('title', 'editor', 'thumbnail', 'comments', 'page-attributes') ) );

    I think that if I set the post type to be “Portfolio”, this should work everywhere I try to use it (and it did prior to 3.1 RC3).
    For example, with version 3.0.4, in the “Add post” page when using:

    $current_screen->id

    it returned “Portfolio”, but with 3.1 RC3 it returns “portfolio”.

    If I change now the slug to “portfolio”, there still will be lots of changes that I will have to do on the theme and even if I do it and release an update, I think people might experience some problems.

    So far, what best works for me is to check if the post exists with the uppercase or lowercase, before referring to it:

    if(post_type_exists(‘Portfolio’)){
    $portfolio=’Portfolio’;
    }else{
    $portfolio=’portfolio’;
    }

    And the most interesting part is that on some places I still can use “Portfolio” (for example with the query_posts function) and on other using “Portfolio” just doesn’t work.

    Thanks again

    I think you’ve missed the point i was making before, the post type must be registered with a slug, eg. all lowercase, without spaces.

    Wrong.

    register_post_type( 'Portfolio',

    Correct.

    register_post_type( 'portfolio',

    Hope that helps to clarify.

    Actually, I understand it now, but obviously when creating the theme I got mislead by the default value for $post_type set to “None” in the function reference.

    Changing this to a working site with existing Portfolio posts messes some parts, so I can’t do it now, but I will have to think of a way to do it compatible for both WordPress versions.

    Anyway, thank you for your time, your help is much appreciated 🙂

    dennis_f – You SHOULD be able to go through the database and rename the posttype that way to fix it.

    Hi Ipstenu,

    The problem is not with my own installation, but the installations of other people using the theme (they are not few). They already have set their sites with Portfolio posts created and some of their portfolio functionality will break with the new update, but I can’t tell them to update the database, as lots of them don’t have the knowledge to do it.

    So I can’t neither register the portfolio post type with a lowercase slug, nor update the database. The only thing that is left for me now is to check whether the “Portfolio” post type exists (as posted above), and if not, to refer to it as “portfolio”.

    Thank you very much for your help 🙂

    I know there are plugins to change CPTs. Perhaps you could steal a function from them. IF there are post types with the capital P, rename them to lower case p.

    http://wordpress.org/extend/plugins/post-type-switcher/

    Thanks for the idea – it seems that it will do what I need, I will give it a try 🙂

    By the way, I have been thinking about adding a function that checks whether “Portfolio” posts exist and if yes, just creates a query to the database that updates all the “Portfolio” types to “portfolio”. After that I should be able to refer to the posts as “portfolio”.

    Thanks again 🙂

    For anyone interested, calling the following code:

    if(!get_option('custom_type_updated')){
    global $wpdb;
    $wpdb->query("UPDATE $wpdb->posts SET post_type = 'portfolio' WHERE post_type = 'Portfolio'");
    update_option('custom_type_updated','true');
    }

    before the register_post_type function works. I have just set an option setting that the conversion from “Portfolio” to “portfolio” has been executed, so that this query doesn’t have to be executed every time.

    However, this still doesn’t work completely, as there might be problems with the permalink settings. For example, if the user has default permalink settings and somewhere within the site has inserted manually a link to a portfolio post, for example:

    http://site.com/?Portfolio=123

    this link will be broken (this doesn’t apply to the other custom permalink options). I think this also may cause problems with search engine saved results…so for now, still the post type existence check is left for me.

    Hrm. I wonder if you can force an .htaccess rule (or maybe pop up a warning?)

    I hesitate at suggesting you run a DB search for ?Portfolio= and replace THAT since the amount of DB mucking you should be doing on behalf of users is minimal. An .htaccess rule to redirect P to p would be smarter, IMO, but I don’t know how to force that via the backend. I know it CAN be done! There are plugins to handle redirects from the backend, after all!

    I agree with you – I would also hesitate about doing a ?Portfolio= replacement, but at this point there aren’t many other options available.
    I have been thinking about .htaccess rules as well, but I’m not sure if this is going to work on all the installations regarding the permissions settings. However, I will have a look at these plugins as you suggest, to see how they accomplish this.

    Thanks again for the help 🙂

    Yeah, the .htaccess would only help *nix/Apache users.

    @dennis_f – Thanks for the share on the SQL to update the post types. Saved me a little time. Funny, I was just hit by this today on my “WEBphysiology Portfolio” plugin. In addition to lowercasing the custom post type, Portfolio, I decided to change it a bit to try and avoid contentions with other plugins that might use the same post type. Fortunately, I didn’t allow for rewrites.

    Ian

    @ianaleksander

    thank you so much. I was having a similar problem (never even realized it WAS A problem until I updated to 3.1) from similar misunderstanding about the cap letters.

    the code

    if(!get_option(‘custom_type_updated’)){
    global $wpdb;
    $wpdb->query(“UPDATE $wpdb->posts SET post_type = ‘portfolio’ WHERE post_type = ‘Portfolio'”);
    update_option(‘custom_type_updated’,’true’);
    }

    worked for me and got my site up and running again. I wasn’t able to access anything after the update until this was fixed! Thank you thank you thank you!

    @jeff, @ianaleksander

    You are welcome, I’m happy this was helpful 🙂

Viewing 15 replies - 1 through 15 (of 21 total)
  • The topic ‘[Resolved] 3.1 RC3: Uppercase custom post type problems’ is closed to new replies.
Skip to toolbar