3.1 RC3: Uppercase custom post type problems

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.

https://codex.www.ads-software.com/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.

https://www.ads-software.com/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:

https://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.

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 ??