Hi @dineshsunny9,
Sorry to hear you’re having trouble.
Can you confirm that you’re using the latest version of Wicked Folders?
How are you registering the custom post types? Did you write code to register them or are you using a plugin? Are there any plugins that are installed on the server that aren’t installed in your local environment?
Thanks for the prompt reply.
I am using 2.9.0 version of WF.
View post on imgur.com
and Using PODS to create the Custom post types in both local and staging environment.
Are you using the same version of Pods in both environments?
Yes, using the same version on both.
View post on imgur.com
Thanks for the additional info.
Can you try going to Pods Admin > Settings in your server environment and clicking the “Clear Pods Cache” button to see if that makes a difference?
If not, are there any obvious differences you can think of between the local and server environments? Are the same exact post types registered in both environments or are there some differences? Are you using the name post, user, comment, taxonomy, settings or term for any of your post types?
Thanks for the Reply.
Cleared the Cache, but no luck!
Post Types are having different names, please have a look.
View post on imgur.com
Thanks @dineshsunny9.
I’ve looked into this and I believe the issue has to do with how the Pods plugin registers the custom post types. From looking at the code, it appears that the custom post types are sometimes registered during the WordPress init action but, in other instances, the post types can be registered later in the process.
The Wicked Folders plugin registers the folder taxonomies during the init action. It appears that for whatever reason the Pods plugin may be behaving differently on your server instance and registering the post types after the init action. This prevents our plugin from attaching the folders to the post types (because the code to create the folder taxonomies has already run). This causes the “Invalid taxonomy” error that you are getting.
Unfortunately, the Pods plugin does not appear to expose an action that can be used to register the folders later in the process after Pods has registered the post types.
I will post a message on the Pods support forum to see what they recommend.
Are there any obvious differences you can think of between your local and server environments? E.g. different plugins, different theme, different plugin configuration/settings, etc.?
Pods registers post types and taxonomies during the standard init action. We also have filters/actions that can be hooked into for further customization and integration (if needed). What action priority does your plugin register taxonomies to?
Hi @sc0ttkclark,
Thanks for the input.
We register the taxonomies via the init action at priority 15. This seems to work in most circumstances with the Pods plugin.
From looking at the run() function in the PodsInit class, it looks like setup_content_types() is hooked to the init action at priority 11; however, there is also a condition that checks if the init action has already run and, if so, executes setup_content_types() directly. So it seems like maybe there are scenarios where Pods calls setup_content_types() after the init action has executed.
I could be wrong but, based on the issue @dineshsunny9 is describing, it seems that the post types are being registered after the init action which is causing the “invalid taxonomy” error (since the taxonomies were registered before the post types).
Thoughts?
The setup_content_types handling should always run during the init action, the only cases where it might not run is in our unit tests I believe which may run code differently and require post types to be registered adhoc through the function.
I can’t find a case in Pods itself where the setup_content_types() via run() would get called outside of init. I’ll dig some more, but perhaps we can help you find the real culprit here.
OP @dineshsunny9, would you be available on our Pods Slack to help me find the exact problem by walking you through a few more debugging steps?
Thank you, @sc0ttkclark
I am at slack #support now.
Thanks for the help @sc0ttkclark! Let me know if I can help with anything.
Confirmed as a bug with Wicked Folders.
Taxonomy name has a max length of 32 characters.
The problem post type: abcdef_math_question (abcdef replaces a potentially client-identifiable string in this case)
The length of that is 20 characters.
Wicked Folders creates taxonomy names like this:
$tax_name = 'wicked_' . $post_type->name . '_folders';
Which ends up creating a taxonomy like: wicked_abcdef_math_question_folders
The length of that taxonomy from Wicked Folders is 35 characters.
I believe Wicked Folders could be developed with a workaround for potential taxonomies that go beyond the restricted length of 32 characters by abstracting all calls for the taxonomy name (passing in the post type name) and ensuring the returned result always takes any post types with a length of 18-20 characters (post types themselves are limited to a max 20 characters) somehow get shortened.
I’m not sure how you want to shorten them or avoid potential collisions there, perhaps you take something that would have been like wicked_abcdef_math_question_folders and return it as wicked_abcdef_math_question_folde which would never conflict since it’s your own taxonomy and does not shorten the post type used itself.
Thanks so much @sc0ttkclark for tracking this down and identifying that bug; sorry we didn’t catch it on our end earlier.
@dineshsunny9, we’ll get this resolved and let you know when there is an update available that fixes the issue.
Thanks, both @sc0ttkclark, and @wickedplugins.
Sure, will wait for the update.
