WordPress.org

Ready to get started?Download WordPress

Forums

[resolved] 3.1 RC3: Uppercase custom post type problems (22 posts)

  1. Dennis
    Member
    Posted 3 years ago #

    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

  2. Mark / t31os
    Moderator
    Posted 3 years ago #

    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).

  3. Dennis
    Member
    Posted 3 years ago #

    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

  4. Mark / t31os
    Moderator
    Posted 3 years ago #

    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.

  5. Dennis
    Member
    Posted 3 years ago #

    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 :)

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

  7. Dennis
    Member
    Posted 3 years ago #

    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 :)

  8. 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/

  9. Dennis
    Member
    Posted 3 years ago #

    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 :)

  10. Dennis
    Member
    Posted 3 years ago #

    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.

  11. 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!

  12. Dennis
    Member
    Posted 3 years ago #

    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 :)

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

  14. Jeff Lambert
    Member
    Posted 3 years ago #

    @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.

  15. Ian
    Member
    Posted 3 years ago #

    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!

  16. Dennis
    Member
    Posted 3 years ago #

    @Jeff, @ianaleksander

    You are welcome, I'm happy this was helpful :)

  17. adamnorwood
    Member
    Posted 3 years ago #

    Thanks so much for this post! I just upgraded to 3.1 and was scratching my head about why get_permalink() was returning the wrong permalinks for my custom post type posts and custom posts were 404'ing even with pretty permalinks disabled. A secondary symptom was that only the View link was available in the dashboard for those posts, no Edit links. It turned out to be the single uppercase letter I had in the $post_type name. I'd never noticed this requirement before, as everything had been working perfectly fine in WP 3.0.5 and below.

    Changing $post_type to lowercase and running the SQL cited above by @dennis_f fixed all of the issues I was having.

    Looks like the Codex was updated just yesterday to make note about the lowercase requirement for $post_type: http://codex.wordpress.org/Function_Reference/register_post_type

  18. nessachu
    Member
    Posted 3 years ago #

    This is partially related to this thread. I used @Dennis_f's code above and it did help me fix the uppercase problem. Thanks Dennis!

    But I ran into an additional problem with permalinks afterwards where all my custom post type single views would return 404 errors.

    I realized afterwards that I had named a page and a post-type the same name, and the permalinks were getting confused as to which was which. So all my custom post type single views were broken. I had to rename my custom post type name in order to get them to work with custom permalinks.

    Ideally, it would be nice to be able to have a page and a custom post type of the same name so that the permalinks would be consistent. For example, I want to make a "Services" page and query custom post type "services" within it. That would allow a seamless slug between my page and my custom post type single views. It used to work, but now, it confuses the permalinks.

  19. nessachu
    Member
    Posted 3 years ago #

    I also came across this thread, "Permalinks 404 with custom post type." that might be useful for some.

    It's important to note that you CANNOT have a page and post type of the same name. The above thread talks about this and some other solutions. Hope that is helpful as well.

  20. dotnature
    Member
    Posted 3 years ago #

    This just gave me a heart attack.

    dennis_f THANKS!

    Just a note your above code for the DB does not work if there is more than one registered post type since it's a conditional, I had to go into the DB and change it manually.

    Also custom permalinks are now broken, only the default works, anyone know a possible solution?

  21. hoyer801
    Member
    Posted 3 years ago #

    I also had the same situation (multiple custom post types). To fix this, I modified it like so:

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

    You could make that option whatever you wanted, that just seemed to me the quickest way to change it for the second type.

    Thanks to those of you who made finding this solution relatively painless.

  22. astrotim
    Member
    Posted 3 years ago #

    I had a site with custom post types turn into a mess following an upgrade to WordPress 3.1. I have written a post about how I fixed the invalid post type issues I was having.

    astronautdesigns.com/2011/03/wordpress-3-1-upgrade-invalid-post-type-error/

Topic Closed

This topic has been closed to new replies.

About this Topic