fireproofsocks

This is a question all about how to model your data. In a blank-slate ground-up application, you’d establish object-models for “stores” and “services”, and then you’d have a join table to indicate which stores had which services. And that setup would achieve the core tenant of data normalization, namely that data exists in one place so you don’t have to update things in multiple locations.

This is WP, so the interface and model is simplified, and you don’t actually have a join table to store the mapping. Instead you have a custom field that stores the mapping between stores and services. So you have to decide how you want this to work: either the “stores” or the “services” custom content type needs to include the reference to the other content-type. E.g. creating a store would let you do a multi-select on its available services, or creating a service would let you select available stores. You cannot do it both ways. Just set it up one way or the other and remove one of the relations.

What that means for your users is that they would go to the ONE content type deemed “master” to edit the join data. E.g. if you set “stores” as the master (i.e. the definition of the Store content type included a relation field pointing to the services content type), then your users would edit the Store record if new services were added to a store. If you set it up the other way around where the services content type included a Relation field mapping to the stores, then the users would go into the relevant service to edit its list of stores. You cannot map it both ways due to the limitations of the architecture. It’s WP… you don’t really have a join table, so you have to choose which content type will hold the info about the relations. Hope that makes sense.

Also, I don’t recommend using the raw SQL queries unless you’re really comfortable with them. The “Relation” field type (see https://code.google.com/p/wordpress-custom-content-type-manager/wiki/Relation) exist precisely for this type of scenario: they allow one post to reference another, and by extension, that other post’s data.

Although there may be some workarounds to WP’s troublesome URL routing, the real fix is in development and can be tracked at this issue: https://code.google.com/p/wordpress-custom-content-type-manager/issues/detail?id=534

If it’s a bug, please file a bug report.

If your solution works for the problem, that’s great: that’s the most important thing. The immediate problem was solved.

WP isn’t really developer friendly in my opinion: it deserves massive recognition for bringing PHP to the masses, but the quality and structure of its code is sometimes painfully bad, and although I get flamed for saying things like that I think it’s good for users to know the limitations of the software they are using. In this case, the habit of WP of relying on global variables makes it difficult to see what’s going on with its code, and it can sometimes make the code less secure, and it usually makes the code less testable. So those can be real concerns in the longterm, but again, the immediate problem was solved, so you can take my reservations with a grain of salt.

Those characters should work (in theory), however, the translations between json and serial data and printing into a form can make non alpha-numeric characters more likely to be converted to an entity that’s not recognizable and that (I think) is the root of the error. In general I recommend using simple alpha-numeric characters as the stored value for things like this and display whatever makes sense to see as the values. The important thing is to simplify the values that are stored — fewer moving parts.

If you’d like to discuss related work, then please send me an email. Thanks.