[Plugin: Custom Content Type Manager] Trouble with the latest version

Sorry you’re having trouble!

Yeah, I got one other report like that — editing and re-saving the content type definition fixed the problem. I tested upgrading from 0.9.3.3 before releasing 0.9.4, but I must have missed something.

Is everything working for you now that your re-saved your content type definition?

It is working. I would guess the problem was with having two custom types that were nearly identical. I would guess that it has something to do with how identical field names are normalized. In my case, I have all identical fields, but rather than the fields being renamed as the upgrade guide would suggest, the second content type seemed to become a copy of the first.
When I first encountered the problem, my second custom type did not work. I would to pages that aggregated my first type, and they would work correctly. However, the second content type didn’t work at all. I went in to the second content type in admin and saved it without looking at it, figuring that would fix it. However, the second custom type kind of replaced the first. The pages that aggregated my first content type displayed the posts of my second content type, while the pages that aggregated the second content type still didn’t work.
I basically just had to recreate the second content type, and then everything worked.
Thanks for the plugin, by the way. Let me know if I can help you track the bug down.

Hmm… the post-type names were already normalized (i.e. it’s impossible to have 2 post-types use the same name). But prior to 0.9.4, the custom field names were NOT normalized, so if you had “myfield” attached to “page” and “myfield” attached to “post”, the plugin considered those 2 separate field definitions. I’ve already caught a couple little bugs with 0.9.4 (mostly just little things I forgot to comment out), so I’ll release a patch here soon.

I think I know why there is the “re-save to fix it” problem, and it had to do with how I implemented WP’s register_post_type() function and its “public” argument. But that doesn’t explain how or why one content type replaced the other in your setup. Hmmm… I love a good puzzle.

How are you aggregating the posts? Are you using some built in WP function or some other plugin to summarize the posts? That might have something to do with it.

Thanks for taking the time to share your information. I want the plugin to be good… the last thing I want to unleash on the world is buggy code.

I am using the “Redirection” plugin to add the post_type=<post_type> to the url and passthrough. Thus, you go to https://example.com/my-custom-type/ and see https://example.com/?post_type=my-custom-type by passthrough.
So instead of saying aggregated page, I should say more specifically that https://example.com/?post_type=first-type was displaying https://example.com/?post_type=second-type while https://example.com/?post_type=second-type was displaying 0 posts.

Weird. I’m pretty frustrated with WP’s implementation of URLs and permalinks. I’d bet that it has to do with both plugins trying to manipulate them.

One of the things that I changed in order to make the CCTM plugin compatible with another the WordPress SEO plugin was to change when the permalink rules were flushed. In 0.9.3 and before, the CCTM fired first. In 0.9.4, I bumped that back by adjusting the $priority parameter. See this issue:

https://code.google.com/p/wordpress-custom-content-type-manager/issues/detail?id=189

Maybe adjusting that number higher or lower will make the 2 plugins play together more nicely.