New answers tagged

6

It depends on how you are going to use the stored data. If you want to run complex queries against the values, use a custom table with indexes optimized for those queries. If you will always just fetch all the values for a given object, create a non-public custom post type, and store the data as post meta. Do not store the data in a serialized string, ...


4

Where to store plugin settings fields? Options table FTW. It's cached and easy to do CRUD. Settings API or Options API? Basically, you can use Options API without Settings API but you cannot use Settings API without Options API. Even when you just need to add some fields to a existing WordPress page, you still need get_option() to retrieve data for ...


1

Yes this is actually the same as point 1, just without the helpers Now this depends on how you want to use your setting. The instinct is that at 99% of the cases this will just add unneeded complexity to your code and hurt performance. As long as we are talking about setting and not content or widgets, the settings API is what you should use. It takes ...


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