New answers tagged

0

I think it is always better to use the API, the functions of WP in this context. The function wp_load_alloptions() is under maintain and a custom select must always tested and maintain. Also the function use the Cache, if the installation support this. A good point for performance. The function supports also the Multisite installation, maybe this also a ...


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

To do what you want you are going to have to add_rewrite_rule for each rule you have. I am storing new rules that users add to an options array. If the user wants to delete the rule, then once selected, I unset it from the array. function remove_rule($user_input){ foreach($rules as $key => $rule){ if($rule === $user_input){ unset(...



Top 50 recent answers are included