What I ended up doing was creating a new “Page Defaults” custom post type. If a the template can’t find a value on it’s own page then it checks for a slug which matches it’s post type and get’s the ID. Then checks to see if the field exists on that page.
So in functions.php:
function the_slug_exists($post_name, $post_type = "page") {
global $wpdb;
if($slug_id = $wpdb->get_var("SELECT ID FROM wp_posts WHERE post_name = '" . $post_name . "' AND post_type = '" . $post_type . "'")) {
return $slug_id;
} else {
return false;
}
}
Then in my template:
$pt = get_post_type();
$default_id = the_slug_exists($pt, 'default_layouts');
if ( have_rows('body_content') ) {
$body_id = null;
} else {
$body_id = $default_id;
}
if( have_rows('body_content', $body_id ) ) {
while ( have_rows('body_content', $body_id ) ) {
//As normal...
It’s working, but it’s less than graceful. I’ve effectively made an options page with sub pages that works how I needed it.
Elliot… can something like this be built in?
Thanks for the quick reply.
The problem is, I will need to be updating and changing the one field group on a regular basis and it will soon get messy if I have to replicate the same changes 6 times (one for each custom post type). I put a sub option page in the custom post type’s menu in order to provide a place to set the options as a fall back if the same settings weren’t set on the custom post itself.
Why can’t it save to the wp_options table using my slug i’m sending it. That is unique…?@!
Is there a way to extend the core functionality do get what I need?
