fireproofsocks

It’s in the FAQ, all comes down to “how do I convert a post ID into the data represented by that post?”

https://code.google.com/p/wordpress-custom-content-type-manager/wiki/FAQ#My_Image/Relation/Media_Field_Only_Shows_Numbers._WTF?!?

https://code.google.com/p/wordpress-custom-content-type-manager/wiki/to_link_OutputFilter

E.g.

<strong><?php print_custom_field('department:to_link'); ?></strong>

Or for heavy artillery:

https://code.google.com/p/wordpress-custom-content-type-manager/wiki/get_post_OutputFilter

Links to the end result are generally not useful in diagnosing PHP: it’s more helpful to see the PHP code that was used to generate the HTML.

Output filters are available only as a convenience, and there’s no requirement that you use them. I’m not sure how your SQL query looks, but the most “correct” solution (from a data-normalization standpoint), is to select the name as the visible option and the post ID as the stored value (because the ID never changes). Then the task is to convert the stored ID to whatever data it is you wish to display (e.g. the post_title, the permalink, the thumbnail etc). Once you’re sure you’re storing the post ID, then the crux of the problem is “how do I convert a post ID into the data represented by that post?” Variations on that question come up so often that I’ve devoted several of the FAQ’s to them: https://code.google.com/p/wordpress-custom-content-type-manager/wiki/FAQ

Relatedly, a custom SQL query may not be necessary if you define your field as a relation field: it provides a GUI for you to specify criteria for searching the posts table specifically.

Hope that helps.

Setting limit=1 means that you only want 1 result. Is that what you really want? Pagination usually occurs when you have lots of results on one page, e.g. 10 on this page, 10 on the next page etc.

The docs on the shortcode are here: https://code.google.com/p/wordpress-custom-content-type-manager/wiki/summarize_posts_shortcode

but the rules for pagination are unfortunately complicated.

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

This is an issue that comes up repeatedly because WP’s integration of this bit of functionality is so myopic it hurts. The CCTM attempts to workaround this, but I can’t give you any useful information without knowing exactly how your fields are defined and exactly how you tried to upload the image (there are several options of each). See https://code.google.com/p/wordpress-custom-content-type-manager/wiki/ReportingBugs

I would recommend downloading and using the the development version of the plugin — I’ve done some work on this functionality recently so there’s a good chance the issue is resolved in the development code.

I keep thinking about this one — I think probably the most “correct” and flexible behavior here would be to implement your own callback function (specified in the _callback argument). You can still have the CCTM to all of its normal stuff, e.g.

[cctm_post_form post_type="something" _callback="my_custom_handler"]

Then in your theme’s functions.php (or in any included path):

/**
 * Custom callback function
 *
 * @param	array $args: parameters from the shortcode and posted data
 * @return string (printed)
 */
function my_custom_handler($args) {
    // First, do the default behavior
    $out = CCTM::post_form_handler($args);
    // Generate the slug, modify the post-status, display a comment form
   // do something else
   return $out;
}

That would work even if the other parts of the function were changed in the CCTM core. I have done some improvements in this function for the next release.

See https://code.google.com/p/wordpress-custom-content-type-manager/wiki/cctm_post_form

One of the problems with WP’s default implementation of custom fields is that they are not standardized, so one post might have custom fields named A, B, C, and another post might have D, E, F, G, H, etc. and that makes it nearly impossible to have a sensible template for formatting those posts because one post might contain completely different data than another post. From an architectural standpoint, that’s a big problem.

Enter the CCTM: it can create custom post types, but for the built-in post types (e.g. posts and pages), it can standardize their custom fields. Go to the “Custom Content Types” menu and click on the “Standardize Custom Fields” link for either posts or pages (whichever you’re dealing with), then all the custom fields defined and associated with that post-type (see the “Manage Custom Fields” link) will be shown on every post or page.

See https://code.google.com/p/wordpress-custom-content-type-manager/wiki/FAQ