New answers tagged

-3

I think something may be misunderstood here, or as another responder considers, maybe cache. The first thing I notice is the odd code within the file snippet you show. Both === style.css === and the function one will or should break the site. Both style and function should be their own files and they surely should not contain such a label. Id suggest ...


0

Your post type (member_post) doesn't match your template slug (memberPost). Whichever you choose, it must be all lower case.


2

File should be single-member_post.php instead of single-memberPost.php. In single-{posttype} , {post_type} is the $post_type argument of the register_post_type() function. Never use flush_rewrite_rules(); in init use it only on theme/plugin deactivate or activate. Since this is a theme you can use it on after_switch_theme hook. add_action( 'init', '...


0

Personally I think keeping your mods in an array is a nice solution, but transferring them shouldn't be too difficult. Just loop through the array like this: $all_mods = get_theme_mod('thefunk_theme_options'); // retrieve array foreach ($all_mods as $key -> $value) { if (!empty($value)) set_theme_mod ($key,$value); // set array element as separate ...


0

Note what happens when you provide sanitize callback in register_setting(). It register a filter to sanitize your options add_filter( "sanitize_option_{$option_name}", $sanitize_callback ); Now when you do update_option() then trigger your own function to prevent saving :D Because update_option() calls $value = sanitize_option( $option, $value ); ...


0

This is just a hunch, but it seems to me that this problem has something to do with the order in which the operations are called. If you have defined your hooks wp_ajax_remove_installing_data and wp_ajax_nopriv_remove_installing_data in your plugin and hooked that plugin in the usual way into WP with the init hook, it means this code is executed before ...



Top 50 recent answers are included