Custom Content Type Manager
equally good taxonomy manager plugin? (35 posts)

  1. normadize
    Posted 3 years ago #

    This may seem off-topic but given that I think CCTM is a great plugin and I've been using it for a while, I'd appreciate if any of the CCTM users know of an equally good plugin to manage taxonomies.

    I've tried a few but they are not great. For instance, the Ultimate Taxonomy Manager or Ultimate CMS have bugs/gaps (e.g. the list of roles allows to edit/add taxonomies only includes the native roles, not any of the roles I defined).

    Any input will be appreciated!


  2. fireproofsocks
    Plugin Contributor

    Posted 3 years ago #

    I've looked at a handful of them, and many of them did some pretty bad things in their code. Until I incorporate managing taxonomies into the CCTM, I continue to recommend the Simple Taxonomy plugin -- it was the only one I looked at that followed good architectural principles.

  3. normadize
    Posted 3 years ago #

    (see a recommendation for CCTM at the end)

    I did see that you recommend it, but Simple Taxonomy uses custom mysql tables, i.e. different than wp_terms, wp_term_relationships, etc. I'm not sure why this was done -- perhaps the plugin is older than WP 3.0 when WP introduced custom taxonomies -- but I don't like it as it makes things non-standard. I'd rather use the native WP tables and API for custom taxonomies. Simple Taxonomy also makes it a pain wrt to labels ... you have to type them all in by hand, rather than expanding the raw name.

    I had a look at Custom Post Type UI which has a manager for custom taxonomies as well ... hasn't been updated in a while but still works fine with WP 3.5.1. It's missing capability management

    Pods - Custom Content Types and Fields is a very powerful plugin, with a lot of functionality, which can also add custom fields for taxonomies -- this is actually quite neat (you can have a taxonomy for "institutions" let's say, each with fields for url, address, etc, and then assign them to posts). But it too uses custom tables and a custom API :( ... to its credit though, the author claims to provide some good documentation for it.

    I may end up writing my own for the time being. I'm not fond of the idea of adopting a plugin with a custom API and db schema because I never have a guarantee that the author will maintain it as WP evolves. Using the native WP API and DB schema at least makes it easier to fix/patch and maintain it myself.

    If you implement custom taxonomies in CCTM, it would be great if you added custom fields to them as well. You will have to use a custom db schema but only for taxonomy meta, using the native WP API and schema for everything else. Maybe have a look at Pods to get inspired.

    Cheers and keep up the good work!

  4. fireproofsocks
    Plugin Contributor

    Posted 3 years ago #

    Simple Taxonomy probably uses custom tables to store the taxonomy definitions since that's a more scalable way of storing the data..... CCTM stores some large data objects as WP settings... it is perhaps "more correct" to avoid relying on custom tables, but doing it that way means that your sites get clobbered during migration because serialized data gets corrupted when character counts change (some WP myopia here).

    I don't recommend Post Type UI: it incorrectly stores custom field data as taxonomical terms, which is awkward at best, but it also put hard limits on the size of the data (ie. no long textareas can survive the character limits of the varchar fields).

    PODs approach is to use custom tables for post-types, and that's means more efficient queries and reporting etc, it's just a tough row to hoe given that WP's core is hardly a framework, let alone stable enough to withstand that kind of thing, but hats off to them -- they've worked hard to do that. I generally don't recommend WP as a platform for anything other than a hobby-level site -- it's just difficult and painful to customize WP when it comes to reworking the architecture and the end result is nowhere near as fast/efficient/maintainable as when you'd built it right on a solid platform to begin with.

    You can update the feature request for custom taxonomies in the bug-tracker: https://code.google.com/p/wordpress-custom-content-type-manager/issues/detail?id=167

    I don't know if I'd try to incorporate custom fields into taxonomies... if you want to do that, I'd recommend leveraging a post-type as a taxonomy and using relation fields. If it looks like I can add custom-fields to taxonomies cleanly, then I'll give it a go once a project comes in that requires it.

  5. Scott Kingsley Clark
    Posted 3 years ago #

    Pods lets you create Custom Post Types, Custom Taxonomies, and Advanced Content Types (standalone). It lets you extend existing Post Types, Media, Taxonomies, Users, and Comments.

    All meta-capable content types default to meta-storage, so no custom table will be created or used. When you create a new custom taxonomy, you have the option to enable custom fields, but the default is off. Custom fields are added to their own table, but in the future if Taxonomies get a meta table of their own, we'll utilize that and work to offer a path for migration too.

    Pods is integrated tightly with WordPress core, which lets you use all existing core functions and methods like you would normally use (WP_Query, get_post_meta, update_post_meta, etc). We have a custom API, but that's only if you want to utilize it.

    We're not going anywhere either, we're backed by Automattic, and are working hard at making content type / field development more attainable for developers AND users. There are more features coming in Pods 2.3, like the ability to create Custom Settings Pages, new field types, new relationship objects, and more.

    Hopefully that sheds a little more light on Pods itself.

  6. Scott Kingsley Clark
    Posted 3 years ago #

    Also, for a comparison between the different plugin options out there, you can check out this, which includes Pods and CCM:


  7. normadize
    Posted 3 years ago #

    If it looks like I can add custom-fields to taxonomies cleanly, then I'll give it a go once a project comes in that requires it.

    I have a large project that requires it. Maybe we can discuss about it elsewhere?

    Maybe I am mistaking, but I seem to recall that Simple Taxonomy doesn't use the WP tables at all, i.e. the custom taxonomies do not appear in wp_terms along with the other native ones (tags, categories, etc), which then turns it into a hassle. There is no need for custom tables to store taxonomy definitions; that's why the wp_terms and wp_term_taxonomy tables are for ... I haven't dug further as it looked like the WP API couldn't be used for it (I need custom taxonomies in the code, not just in the GUI).

    There is an interesting plugin out there called CPT-onomies, which attempts at using custom post types as taxonomies. I'm a bit weary doing that as WP is already slow to begin with, but it would allow for some interesting flexibility.

    I'm interested not only in custom fields for taxonomies, but also in custom fields for taxonomy relations, i.e. when I assign two different taxonomies to a post, say "institution 1" and "person 1", then I'd like to have a custom field for that particular pair in relation to the post, e.g. a comment field.

    WP is abhorring and I get frustrated every single time I need to code using its so called API. It started as a script kiddie project, written using global functions with thousands of arguments and global variables everywhere, and now it can't escape that horrible mess they call a "code architecture" as they need backwards compatibility and it somehow makes it easier for other script kiddies to create plugins which look just like WP, i.e. tons of html code intertwined with PHP code using global functions and global vars. Makes me cringe.

  8. Scott Kingsley Clark
    Posted 3 years ago #

    Pods has a comprehensive relationship field, which has extensive functionality for relationships from any object to any other object of any other type. May be worth a go if you need that. There is no "right" way to implement custom fields for taxonomies, and they range from:

    • Custom table: wp_termmeta, mirrors wp_postmeta in structure
    • Custom table: wp_taxonomy_name, a custom column for every custom field
    • Reuse post meta: wp_postmeta
    • Store as options: wp_options
  9. fireproofsocks
    Plugin Contributor

    Posted 3 years ago #

    If you'd like to contact me re a project, I can be reached at http://fireproofsocks.com/contact/

    I am a few weeks out at the moment, however.

  10. normadize
    Posted 3 years ago #

    @Scott, are you monitoring the WP forums for all occurrences of Pods? :)

    Many thanks for that spreadsheet! Very, very useful!

    Regarding the relationship field. CCTM has a really awesome relationship field which I have been using. It seems hard to top that but I guess not impossible. However, what i was describing above is something a bit different.

    Suppose I have two custom taxonomy names, "Companies" and "Persons". Suppose I have Company X and Person Y as taxonomies belonging to those. I'm assigning these two to a post P. I would like to have a comment field to use to describes the relationship between the pair XY and the post P, e.g. "at the time of this writing, Person Y was the director of Company X".

    I can have another taxonomy called "Positions" and have "Director" being a member and assign it to the post as well but that wouldn't work as intended since the post has multiple persons, multiple companies and multiple positions; it could be done with some extended relationship fields to link XY to P and Director. However, I am ultimately interested in a text field to write a short description of such a relationship, besides the relationship itself (then I could also do away with the Positions taxonomy in this particular case).

    This sort of thing then makes automation really efficient, and not only. Haven't dug enough in Pods to see how much of this it can do, but would certainly love to see custom fields for taxonomies in CCTM, extended with custom fields that can relate to taxonomies, not just to posts.

    p.s. Regarding Pods, I recall it created a new table as soon as I added a custom taxonomy and that I couldn't query it using the WP API. Are you sure custom taxonomies created by Pods are inserted in the wp_term* mysql tables and that I should be able to use the WP API for terms e.g. get_the_term_list(), wp_set_object_terms() etc?

    Thanks once again for the info.

  11. Scott Kingsley Clark
    Posted 3 years ago #

    I support my project by watching for references to it across WP.org and social streams, so I can address questions, concerns, and bugs where users feel most comfortable to discuss them. This one came up and I just felt like I should clarify Pods functionality since it was referenced here.

    Pods has one optional table by default, and that's for relationships: wp_podsrel. For taxonomies created with fields disabled, there is no table added and that's been made the recommendation / default.

    All Pods WP objects (Post Types, Media, Taxonomies, Users, Comments) are 100% compatible with the WP API. In an upcoming version of Pods, Table-based objects will have WP_Query / WP_User_Query / WP_Comment_Query integration for their custom field (meta_query) lookups, since those fields are not stored in the default meta tables of their corresponding objects.

    I'd be interested to see how CCTM relationship fields compare to Pods relationship fields. I'm not familiar with CCTM enough to say whether it's relationship field covers all of the use-cases that Pods does or not.

  12. Scott Kingsley Clark
    Posted 3 years ago #

    To clarify, Pods offers the option to store custom fields in meta (default) or a custom table. My reference to WP_Query / etc was regarding those Pods setup with custom fields stored in tables (again, optionally enabled).

  13. fireproofsocks
    Plugin Contributor

    Posted 3 years ago #

    The CCTM's relation fields are very flexible. I wrote a whole separate database accessor class (GetPostsQuery) that is the power behind them because the built-in WP classes (WP_Query et al) drove me insane with their limitations and caveats.

  14. Scott Kingsley Clark
    Posted 3 years ago #

    We did the same with Pods, we have a very cool traversal method that interacts with normal pieces of a query (using SQL syntax) and automatically joins related tables as many levels deep as you need (i.e. parent.friends.parent.child = "This child's parent is friends with my parent"), so it really cuts down on the complexities and mess of normal WP_Query posts_where lookups.

    Here's some of the settings available for individual relationship fields:








    Pods offers a lot of built-in relationship objects (screenshots are from Pods 2.3, which includes even more), and various input options.

  15. normadize
    Posted 3 years ago #

    @Scott, that sounds and looks quite interesting. Are those relationship objects available as custom fields for Taxonomies as well? For instance, would I be able to define, say, a relationship custom field for a taxonomy member pointing to a custom defined list (similar to your 1st screenshot)?

    What about my usage case above (the Company/Person/Position + text field issue)? I'd love an answer about it and whether I can have a custom field (e.g. description) for a combination of relationships.

    @Everett, I like your CCTM implementation of relationships and the fact that you store them in the wp_postmeta table -- it allows using the WP API to write and read it, even though you need a custom API to actually do stuff with it afterwards. I have to admit, I was in such a rush with my project, I parsed them in the code without knowing there is an accessor class for them (I just preg_split() the IDs into an array and used my own code from there).

  16. Scott Kingsley Clark
    Posted 3 years ago #

    Relationship fields, like all other fields, can be added to any object Pods creates or extends. We do not have contextual relationships (additional custom text per relationship) yet, but that will roll in as a use-case with our new Loop Fields that we're continuing to develop for Pods 2.4 (loop group would contain a text field and a relationship for that use).

    Pods also stores all relationships from Post Types in wp_postmeta, so they can be referenced in normal WP_Query meta_query calls, we utilize wp_podsrel for optimal traversal in our own API, but we store the IDs in custom fields.

  17. normadize
    Posted 3 years ago #

    Thanks Scott. It seems I need to do some hacking to add a text field/description for a combination of assigned taxonomies.

    I take it that you store Relationships for custom taxonomies in a custom DB table. I could implement a description field for any assigned taxonomy pairings or relationship fields of a post by using a normal text custom field whose meta value would be stored respecting a specific format, e.g.

    t1234,t2351,f345 At this time Person Y was the director of Company X

    where t1234, t2351 and f345 are the IDs of two taxonomy members assigned and custom field assigned to the post. Basically, any number of IDs separated by a comma, terminated by a space would indicate the combination of taxonomies and/or custom fields that the text following the space is a description of. The letter signal the type (table in the db).

    Some jQuery and javascript would solve the above, e.g. display a list of the taxonomies and fields detected as assigned in the edit screen, allowing the user to click and select multiple of them then write a description and build the meta value upon post submission.

    CCTM already has a few Ajax snippets that do that for relationship fields (and I suppose Pods does too), but in this case Ajax is not needed as we don't need to query the db; the info is on screen.

    I can implement the above as an add-on to CCTM or Pods, without touching their code. It'll be another widget in the edit screen.

    I need this sort of thing to generate an automatic HTML table based on the assigned taxonomies and relationships, so just a static description of a relationship field (filled in when the field was created, like WP does for categories) wouldn't work.

    If you guys have a better idea of how to implement this other than the above approach, then by all means, I'm all ears (well, eyes). If yes, and if the CCTM API or Pods API already provide some features to speed up the above implementation, then please do tell which and point me to the API docs for it or some code entry points where it is used.

    [ the above is also for my own reference, sorry for the slight off-topic ]

  18. Scott Kingsley Clark
    Posted 3 years ago #

    Oops, sorry, hopefully I don't seem like I'm trying to sell Pods over CCTM for you, I was just providing information regarding it's features and capabilities when I saw some info about it that wasn't 100% correct.

    I suggest you stick to CCTM when you build this out. You're more familiar with it and it's likely easier to work with since your project is aligned with it already. I'm unable to consult further on how to accomplish the functionality you're seeking, but good luck with it, it sounds interesting!

  19. fireproofsocks
    Plugin Contributor

    Posted 3 years ago #

    I think you could do what you need by adding your own class of custom field: https://code.google.com/p/wordpress-custom-content-type-manager/wiki/CustomCustomFields -- you can do that without touching the CCTM core. That would get you the dynamic bits you need.

    Related here would be "field groups", which sorta act as a join table (see feature request here: https://code.google.com/p/wordpress-custom-content-type-manager/issues/detail?id=392)

    There are probably lots of ways you could achieve this functionality. If there's a budget, there's a way...

  20. normadize
    Posted 3 years ago #

    @Scoot, I wasn't implying that at all. I was actually interested to hear your take on this and how all that might be achieved either using Pods, or if the Pods API can make it easier in any way. I appreciated all your input so far. Many thanks.

    @Everett, Thanks for the tips!

  21. normadize
    Posted 3 years ago #

    @Scott, I tried out Pods just now and defined the same post types and custom fields that I previously defined with CCTM. I notice that Pods hooks a filter into get_most_meta() by default namely PodsMeta::get_post_meta().

    This was unexpected, and undesired, because a call to get_post_meta() on a custom relationship field that was previously defined with CCTM, which holds a string like ["263","264","268"] as the meta_value, now returns an array of WP_Post objects, rather than just the actual string value.

    Also, when saving the post which holds this custom field, the meta_value which was previously one row in the DB holding the above string as meta_value, was suddenly split into 3 rows, each holding one ID as meta_value. This must be the result of another action hook from Pods. What class method is actually doing this DB change?

    I'm puzzled about this behavior too, since Pods is using a different table wp_podsrel for relationships, and I can see the 3 rows defined there, so why alter the native wp_postmeta table and change the output structure of wp_get_meta()?

    That would prompt me to change my plugin code. I didn't want to use the CCTM API to parse the content of relationship fields as I'm trying to have my code as independent as possible from other plugins. I guess I can just remove the filter before calling get_post_meta() but now I also have to revert the wp_postmeta DB entries back to the old version.

    Are other hooks added by default by Pods regarding fetching or updating/inserting custom field values or custom post type content? Would save me some time digging into the Pods docs or code, as my Plugin is almost entirely based on the native WP API for those operations, and I'm assuming that there are no additional action or filter hooks.

    It may be down to preference but I think it's best not to hook filters into these native functions by default given that you're already providing a pretty full blown separate API. That way, people who want to use and depend on your API can still do so, but those who don't would at least not end up with broken code when activating or deactivating your plugin.


    p.s. Also, there is a bug in Pods too (I'll report it properly): for a relationship field that uses a dropdown list to choose, the title shown in the dropdown is not applying the the_title filters; it shows the raw title which in my case contains 3 versions for 3 different languages (qTranslate plugin). It however does apply the the_title filters if it's a multiple select using checkboxes.

  22. fireproofsocks
    Plugin Contributor

    Posted 3 years ago #

    If you're using the CCTM to store values, you should use its API: you're no longer independent. Re storing multiple values in a single row: that's an architectural decision, and you can read more about it here: https://code.google.com/p/wordpress-custom-content-type-manager/wiki/CustomFieldsDataStructure

    As noted, this solves some problems and creates others: I chose what I felt was the lesser of 2 evils. Keeping a 1-to-1 relationship between rows and values allowed me much cleaner and more efficient MySQL queries, but you'll notice that repeatable fields can be painful because you're storing an array instead of a scalar value.

    E.g. if you've stored 3 references, the CCTM stores this as a JSON array of the 3 foreign keys. What you want to do with those keys is left to you, but the CCTM's output filters are there to help (https://code.google.com/p/wordpress-custom-content-type-manager/wiki/OutputFilters). If you want to handle these your own way, use the json_decode() function and have at it.

    What ever you do, I would strongly discourage you from mixing CMS plugins on WP: since this stuff is not in the core, chances are good that using 2 such plugins will cause something (possibly your head) to explode. See https://code.google.com/p/wordpress-custom-content-type-manager/wiki/IncompatiblePlugins

    Again, I think you're headed into territory that might be better traversed by an application other than WP (imo).

  23. Scott Kingsley Clark
    Posted 3 years ago #

    Pods hooks into get_post_meta so that it can traverse relationships, i.e.:

    $friend_ids = get_post_meta( get_the_ID(), 'parents.friends.ID' ); // Parent's Friend IDs
    $friends = get_post_meta( get_the_ID(), 'parents.friends.ID' ); // Parent's Friends data array
    $parent_ids = get_post_meta( get_the_ID(), 'parents.ID' ); // Parent IDs
    $parents = get_post_meta( get_the_ID(), 'parents' ); // Parents data array

    We'll make it optional for what the default return should be for get_post_meta relationship/file fields when using just the name.

  24. normadize
    Posted 3 years ago #

    @Scott, thanks. I think you mean 'parents.friends' in the 2nd example. I was was interested in which class method is modifying the wp_postmeta table as I described above. Currently, a relationship field that was previously a string of N IDs is turned into N different rows. Which class method and which filter/action hook is doing that in Pods? I'd like to disable that (it's unnecessary).

    @Everett, I'm not mixing Pods with CCTM. I am now only testing each in turns, keeping only one active at at time. Since both these plugins claim that they are using the native WP DB schema for custom fields and post types, then I'd like to use them for their GUI to create and insert stuff, but parse (mostly read) the data from the DB myself using the native WP API. I understand that relationship fields are an exception and some custom way of storing them is needed (although I would have still opted for keeping the native WP storage format of multiple rows rather than json array string or a different table -- and I'm aware of the headaches of having an array of values as multiple rows in wp_postmeta).

    I could have a small class method of my own for retrieving relationship fields, checking for a few known return types of get_post_meta() in case I have either CCTM or Pods enabled, or none at all. Any other custom field type should be unaffected -- although Pods does affect it, which is why I'm looking to disable its filters/actions in my own plugin code (I can use the Pods/CCTM API separately if I so wish, but I want my plugin to be independent).

    You both have written really great plugins, with good code and docs.


    p.s. CCTM could implement custom list for relationships (Pods has this) while Pods could consider implementing custom fields types that are standalone and can be assigned to multiple post types rather than having to define custom fields for each post type (CCTM has this).

  25. Scott Kingsley Clark
    Posted 3 years ago #

    Run a function on init, then run this code within it, to disable get_post_meta integration:

    remove_filter( 'get_post_metadata', array( $GLOBALS[ 'pods_init' ]->meta, 'get_post_meta' ), 10, 4 );

  26. fireproofsocks
    Plugin Contributor

    Posted 3 years ago #

    I'm not mixing Pods with CCTM.


    Re JSON: yeah, it's the lesser of 2 evils (imo), and I've arrived at that DB pattern in a couple isolated dev projects where I needed to paginate a set of results with complex filters including filters on custom fields in a related table. Using multiple rows to store custom field data fails that test, ergo the current implementation, which performs reasonably fast, even on large data sets.

    Re "custom list for relationships": can you explain more? The filters for relation fields is extremely flexible. They're not all visible on the search forms without customization/configuration (see https://code.google.com/p/wordpress-custom-content-type-manager/wiki/Config_post_selector_relation or https://code.google.com/p/wordpress-custom-content-type-manager/wiki/DefaultSearchParameters), but there aren't many types of queries that it can't support. You could also use the dropdown/multi-select files and supply your own DB query -- probably that's something I should add to the relation fields.

  27. normadize
    Posted 3 years ago #

    @Scott, thanks but I had already disabled that. I was asking about the class method and filter/action hooked into saving a post. In short, I have a custom field in wp_postmeta called person_ids. This has a string meta_value of ["123","234","345"] (a json array string). This was previously created by CCTM as a relationship field. I also have the same custom field name defined in Pods (CCTM is disabled) also as a relationship field. Pods is using a different table so should normally ignore this field. It also inserts a custom field called "_pods_person_ids" in the wp_postmeta which has a serialized version of the same array as meta_value.

    When saving the post to which this is assigned, Pods is altering the person_ids meta, and not only that, it wipes it and creates 3 different rows in the DB, each having the meta_value equal to 123, 234, 345. I'd like to disable that (is it actually necessary given you have your own meta in wp_postmeta and a different table?)

    @Everett, I think I was mistaking .. it is actually covered by the select and multi-select fields. For relationship fields it's true CCTM is pretty flexible. It requires configuration through php code though which can put users off a bit. Pods allows some of that in the gui (direct SQL WHERE/ORDER/GROUP code).

    One feature I'd like to see in CCTM is autocomplete as an alternative/additional way for adding values from a list - in addition to dropdown, mulit-select or your ajax selector. Typing a few letters to get a list of matching values is many times so much more efficient and faster than scrolling and selecting from a very long list.

  28. Scott Kingsley Clark
    Posted 3 years ago #

    To completely disable Pods get/save/delete handling for a Post Type, try running pods_no_conflict_on( 'pods' ); on init.

    Pods saves _pods_{field_name} meta key to save the order in which the fields are saved. It saves all fields it controls, based on the values saved when using the Pods fields in the Post editor form.

  29. normadize
    Posted 3 years ago #

    I think you mean 'post' instead of 'pods' by looking at the code. I don't mind the _pods_{field_name} meta. What I do mind is Pods altering the existing {field_name} -- it turns it from a 1 row holding a string into 3 rows in wp_postmeta. It doesn't look like that's needed since you're using _pods_{field_name} which hold the same information, and a separate table with the relations.

    But if I run pods_no_conflict_on( 'post' ); on init, will the Pods GUI still work normally? That would be great.

  30. Scott Kingsley Clark
    Posted 3 years ago #

    It should continue working. I haven't thoroughly tested this (disabling all of the hooks) so I can't be 100% sure though. Sorry about the last few typos, I've been pretty distracted the past few weeks with everything I've got going on.

Topic Closed

This topic has been closed to new replies.

About this Plugin

About this Topic