normadize

Thanks. I’ll do some testing to see. At first glance, it appears to work. At least it stops altering the meta field and also no longer parses when fetching it.

I know what you’re saying regarding multiple values. I also mentioned it a few messages back. I’m still puzzled why you are modifying that db entry given you are actually using another entry (the _pods_{field_name}) and a separate db table. At this point I want to keep some compatibility between Pods and CCTM as I’m switching between them while testing, but if I decide on Pods only then I may allow it to mess with the native WP calls.

Are you also looking at the alpha/beta releases of WP to prepare for changes in the WP API?

Also, check your email.

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

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

Cheers.

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.

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 ]

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

(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!

Yes, just replace _() with __() — note the double underscore.

Interesting how this one escaped the developer – unless he doesn’t have display errors enabled? but that would be against the principles of developing 🙂

I’m sure he’ll fix it soon.

But that doesn’t help the problem, which is that the posts are seen as NOT being in “home”, i.e. is_home() returns false. The fact that “cat=8” is used triggers the query to have is_home = false, instead of true.